« Automated BartPE Ghost CD Installer | Main | Disable MSN Messenger Auto Run via Group Policy »

September 22, 2005

Imaging machines using different HALs w/sysprep

One of the biggest problems with ghosting dissimilar machines is when they require different Hardware Abstraction Layers (HALs). For instance, an older Pentium 4 machine will use the Uniprocessor HAL, while a newer Pentium 4 machine likely has a hyperthreading processor or even a Pentium D Dual-Core Processor, both of which qualify for the Multiprocessor HAL.

Switching between Uniprocessor/Multiprocessor HALs is only possible if BOTH machines will be using the ACPI version of the HAL, OR if they are BOTH using the non-ACPI version of the HAL. In my case, the hardware is new enough that everything will be using the ACPI HALs. If you have an older machine (P2-400 vintage) I found it possible to enable ACPI in the bios by downloading the latest BIOS updates from Dell. I actually haven't come across anything that hasn't been ACPI compliant. The method I chose was to install the base image on a machine using the Multiprocessor HAL, and then downgrading it to the Uniprocessor HAL if necessary.

To accomplish this, add the following entry to your sysprep.inf file:

[Unattended]
UpdateUPHAL = "ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf"

Essentially, this line sets the Uniprocessor HAL to be "ACPIAPIC_UP" *IF* the need for a Uniprocessor HAL is detected. If your computers are both NOT using ACPI, change the above "ACPIAPIC_UP" reference to be "MPS_UP". If the image is being put on a machine that can make use of a Multiprocessor HAL, the HAL won't be changed - it will stay Multiprocessor (since my base machine used the Multiprocessor HAL).

If you are going the other way, from Uniprocessor HAL base machine to Multiprocessor HAL clone, then use this line:

[Unattended]
UpdateHAL = "ACPIAPIC_MP,%WINDIR%\Inf\Hal.inf"

Notice that the command is now UpdateHAL (lacking the UP for Uniprocessor) and that the HAL selected ends in MP now (Multiprocessor). The problem with going Uniprocessor->Multiprocessor, is that the Multiprocessor HAL will *ALWAYS* be used, regardless of whether the Uniprocessor one is appropriate. Microsoft says there is a serious performance hit for using the Multiprocessor HAL on a machine that should use the Uniprocessor HAL - this is why I decided to start out with the Multiprocessor HAL base machine. For some reason when going the other way the proper HAL gets selected.

For more information read the "deploy.chm" file that comes with sysprep XP SP2.

Posted by djc6 at September 22, 2005 12:46 AM

Trackback Pings

TrackBack URL for this entry:
http://blog.case.edu/djc6/mt-tb.cgi/2783

Comments

I always had problems with doing this in the sysprep.inf file, so I use these commands in a batch file instead to update my hyperthreaded computers after imaging. I copied the compressed files to the hal folder and then expand them to overwrite the existing ones and update the hal.

expand C:\windows\hal\HALMACPI.DL_ C:\Windows\System32\HAL.DLL
expand C:\windows\hal\NTKRNLMP.EX_ C:\Windows\System32\NTOSKRNL.EXE

Posted by: Mike Redman at October 13, 2005 06:26 PM

Where do I get the hal.inf files so when I use the updateuphal command to change from multiprocessor to uniprocessor it can find them in my path.

Posted by: Mark at December 14, 2005 09:20 PM

The hal.inf file is in the folder listed above, %windir%\inf\hal.inf, where %windir% is c:\windows in XP, by default anyway.

Thanks for this post, just what I needed to use sysprep for all my Dell Optiplexes.

Posted by: Rob at January 12, 2006 04:11 PM

Very good post. I am interested in figuring out why mine didn't work. I built it on a dell gx620 which has multiprocessor support and I was trying to get it work backward combatible to a gx110. I managed to get it all the way back to gx240's and above, but for some reason the gx110's I get the Black Screen of death. (thats what I call it)

The only way I can get it to work on all machines is if I change the "computer" in device manager from ACPI multi-processor to standard ACPI.

Any ideas?

Posted by: josh at February 21, 2006 07:19 PM

In order to get my ghost images to work on GX110's [hell we still have GX1's :(] I have to update the machines to the latest BIOS, and then in the BIOS enable ACPI. On some machines of that era and later (GX400 comes to mind) I had to do the BIOS update and then enable something called IOAPIC in the BIOS, which seemed somehow related to ACPI.

Posted by: David Carlin at February 21, 2006 11:02 PM

Hi all,


Have the same problem, in fact at work I have made sysprepped ghosts for recent machines, without knowing about these HAL subtleties, and I just discovered that they run UP instead of MP, for CAD machines that's a pity :(

The only way I have found this far to correct the problem is to re-sysprep the machine with your UpdateHAL line in the INF file to force multiprocessor.

The problem is ... I've got nearly 150 machines to re-HAL... So is there a way to do this by a script and simple reboot, without need for re-sysprepping the machine ? The way described by Mike Redman doesn't seem to work for me, the computer freezes on reboot.

Thanks a lot for any hint, I think this'll bug my work days for some time if I don't find an easy and fast way to do the job ^-^


@+

Benoît 'Mutos' ROBIN

Posted by: Mutos at March 1, 2006 05:18 AM

Hi all,


Successfully tested multiprocessor conversion on two machines, I'll make further tests then deploy on all our machines that need it.

The principle of Mike Redman's solution was OK, the only thing was that 3 files, not 2, are needed to be replaced.

The three files are (regardless of original files folder) :

expand HALMACPI.DL_ C:\Windows\System32\HAL.DLL
expand NTKRNLMP.EX_ C:\Windows\System32\NTOSKRNL.EXE
expand NTKRPAMP.EX_ C:\Windows\System32\NTKRNLPA.EXE

The first two are Mike's, the third is, according to M$ docs, something to manage 4GB+ memory.

You can just uncompress the files to your machine, then connect to the machine you want to update and copy the files in its System32 folder, they aren't locked or anything. Next reboot the updated machine will take the new kernel into account. Windows will say it discovered a new peripheral and ask to reboot. Even before you acknowledge and reboot, the machine will actually be MP, but of course it's always better to endure the second reboot.

Hope this helps and thanks you all for the hints without which I couldn't have searched further...


@+

Benoît 'Mutos' ROBIN

Posted by: Mutos at March 3, 2006 03:45 AM

I've had sysprep issues for some time regarding the machines hal, this addon to sysprep.inf worked like a charm going from uniprocessor to multiprocessor.

Posted by: Greg at May 30, 2006 03:06 PM

expand NTKRPAMP.EX_ C:\Windows\System32\NTKRNLPA.EXE <-- by Mutos

Where can I find that "NTKRPAMP.Ex_" file?
I can't seem to find it anywhere. :S

Posted by: Crono at June 6, 2006 05:10 PM

I need to change my HAL from Standard to Uniprocessor to enable it to shutdown automatically without displaying the message "It is now safe to turn off your pc". Any help ?

Posted by: sal at August 22, 2006 06:06 AM

Hi,

I tried the expand command in bat file but at reboot i get dll errors and windows cant boot..i got those files from windows XP CD ...is there anything i doing wrong??

thx

Posted by: sofiane at May 14, 2007 08:57 AM

Now it is really possible. You can make generic WDS image from XP. Please check my guide: http://koti.mbnet.fi/olljanat/guides/generic_wds_image_from_xp.php

Posted by: Olli Janatuinen at July 24, 2007 01:26 PM

i built an image on a uniprocessor machine, and when i image a HT machine, it picks it right up. when i image a dual core amd machine same thing gets it right away. but i couldnt do the new core 2 duos. they would image but only show a single graph in task manager and show as ACPI only. i found a fix though. right click on the ACPI line in the device manager, then propertires. go to the drivers tab, then click the roll back driver. it will ask you to reboot, then you will have to reboot again. then BAM multiprocessor. i just thought this might help some people.

basically if you can support multiproc and its showing only uni or acpi try "rolling back" the driver. it seems to pick it up.

Posted by: Unrealkid at August 3, 2007 02:27 PM

Ok in your original post you mention

"this line sets the Uniprocessor HAL to be "ACPIAPIC_UP" *IF* the need for a Uniprocessor HAL is detected"

my question is what exactly is detecting the need for a Uniprocessor HAL? I already use this line in my sysprep however I have a vbs script that runs in a BARTPE environment that detects the hal and places the correct Update statement in the sysprep.inf file prior to the system booting into mini setup.

The HAL I start with on the image is the strait APCI PC the one that windows shows in device manager as Advanced Power Configuration APCI PC or whatever then when the system boots after sysprep it boots up into a BartPE environment runs the vbs HAL detect script which plugs in the appropriate Update statement into the sysprep.inf file sets the boot.ini files back so that it boots up into windows and not BartPE and then reboots the system and runs the mini-setup.

How are you getting the system to detect the hal. I guess I am confused about putting the statement into the sysprep if its not a uniprocessor system and how sysprep knows the difference without some sort of outside detection script.

Posted by: Brandon Pearson at September 6, 2007 09:51 AM

So, this has worked beautifully for all of our machines except our Latitude D505's and D800's. These machines image, and then after imaging, they clear the BIOS screen and then sit at a black screen for eternity. So right now we have 2 images, one without the acpiapic_up line in our sysprep.inf for the d505 and d800 and another image with the new settings for MP's. Anyone else dealt with this or have a solution? The BIOS has been updated but couldn't find anything like IOAPIC that was mentioned by Josh above.

Posted by: Spidey24 at January 17, 2008 01:27 PM

I've had to do the exact same thing with our older Dell laptops. Anything pre Dell X300 does not want to boot using the above line in the Sysprep.ini file.

A simple change of the HAL to ACPI Uniprocessor and removal of that line in the sysprep file fixes the issue. Although this means you have 2 images :( In a perfect world one can dream :)

Posted by: at February 14, 2008 05:50 PM

From my experience, the real key to compatibility is using "Advanced Configuration and Power Interface (ACPI) PC", the PIC-based ACPI HAL, not the APIC-based ACPI HALs (UP and MP). The PIC-based ACPI HAL is used by default on all P2 and P3 ACPI systems (including Pentium-M machines like the Dell Latitude D500, D505, D600, D800, etc.). Machines that want the PIC-based ACPI HAL can not run the APIC-based ACPI HAL. Using an ACPI (PIC- or APIC- based) HAL (rather than Standard PC or an MPS HAL) allows the OS to turn off the computer reliably.

I've been working on creating a unified image set for my organization's PCs which range from Dell OptiPlex GX1 with P2-266 to OptiPlex 755. I've been using MySysprep for a few weeks now with success (although I have issues with conflict between being professional and being political against it... so I'm looking for alternatives). When I messed up the MySysprep.inf and HAL switching, I saw a GX150 (P3 and i830) hit the aforementioned black screen at which nothing worked, after it switched to the APIC-based ACPI HAL.

The most reliable way to test what HAL a system wants is to do a test install. Check for BIOS updates and check the BIOS configuration for ACPI and APIC based options to see if the Windows installer detects a better HAL. Second to that is using a list like http://wiki.williams.edu/display/docs/Sysprep to find your system (or, with risk, a system like yours by CPU and chipset).

Posted by: Gene Cumm at August 3, 2008 08:49 PM