One goal of Hardware Independent Imaging (HII) is HAL independence, i.e. the ability to deploy a single image to target machines that require different HALs.


The strategy described in rev 9 of the HII document is based on the assumption that all "reasonably modern" machines are compatible with one of the HAL types known as the ACPI HAL. This might not be their native HAL, but it would at least allow the machine to boot into mini-setup, at which time a more appropriate HAL would be installed. The recommendation was to downgrade the master machine to the ACPI HAL. A program called halconfig, run during the post-imaging phase of the OSD/Provisioning task, would then insert lines in sysprep.inf to tell mini-setup which HAL to install.


A new strategy is needed because the underlying assumption is no longer true for machines based on the Montevina chipset. An image based on the ACPI HAL will not boot on Montevina based machines, such as Lenovo T500 and HP Elitebook 6930. The new strategy is based on a new version of HalConfig, which now injects appropriate HAL files into the system32 folder. The details are as follows:


  1. Collect all the HAL files for your target OS.  Below is the list of files needed. You can find them in SP2.CAB or SP3.CAB, depending on the WinXP service pack. Look for / in c:\windows\driver cache\i386. If it's not there, take it from an expanded copy of SP2 / SP3.



  2. Include actions in your OSD script / provisioning template to copy the files listed above to a local folder, e.g. c:\drivers\hal.
  3. Add this new command line parameter to HalConfig: /path=<path>. Example: halconfig /path=c:\drivers\hal
  4. Make sure your image has / at c:\windows\driver cache\i386. If the cab file is missing, mini-setup will prompt for the installation media. If the cab file is not in your image, copy it during the post-imaging phase.


The new version of halconfig (V2.1) is attached.



  1. Without the /path command line parameter, halconfig works as before, i.e. it only inserts an appropriate UpdateHal line in sysprep.inf.
  2. Even with the /path command line parameter, halconfig still generates an appropriate UpdateHal line in sysprep.inf. The reason will soon become clear.
  3. You no longer need to downgrade the master machine to the ACPI HAL. Any HAL should work.
  4. Although HalConfig has already copied the right HAL files to the right places with the right filenames, mini-setup will still be looking for them (which is why you need / at c:\windows\driver cache\i386). This is because it looks at the PnP info in the registry to see which HAL is installed, not at the files.
  5. Does this process violate Microsoft's support policy? The stated policy is that the only valid way to change the HAL is through UpdateHal lines in sysprep.inf. Think about note 4 above: true, HalConfig has replaced the HAL files. But that was only to get the target machine booted into mini-setup. Mini-setup takes no notice of whatever HAL files HalConfig has put in place. It does a proper install of the proper HAL. Therefore, members of the jury, the end result is not a wild replacement of the HAL files but a clean install by mini-setup.


HalConfig V2.1 also fixes the following problem: previous versions did not recognise the ACPI HAL. This is the HAL likely to be found on machines that are a few years old. The symptom would be HalConfig failing with an error message "Unknown HAL type: acpipic_up".


This article applies to HII rev 9. Rev 9.1 (see this article) incorporates the change described by this article.