Skip navigation

Jan Buelens' Blog

May 2009 Previous month Next month

CaptureMsd is a tool that is part of the Hardware Independent Imaging package. In combination with another rool called InjectMsd, it allows a a new mass storage driver to be injected into an existing image. The most common use case is - take an existing image created on an IDE based machine and deploy it to a SATA based machine.


Attached is CaptureMsd.exe V1.1. It fixes a problem whereby you would get an error message "Devicepath is empty" if the DevicePath key in the registry (HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath) is "long" (more than 256 characters). The output files would not be quite complete.


This article applies to HII rev 9. Rev 9.1 (see this article) incorporates the new version.

I've seen this in the context of HAL replacement. But the same can happen in a number of different situations.


The general symptom is: even though your image already has all the right files on board, mini-setup halts and prompts you for the Windows XP installation media. When you browse to the system32 (or system32\drivers) folder, mini-setup is happy with the file that's already there and continues.


The problem seems to be caused by the absence of c:\windows\driver cache\i386\ (that's for a Windows XP SP3 system - for SP2, it would be If you update a pre-SP3 system by applying SP3, you will have an But if your master system was built from a Windows XP CD with SP3 slipstreamed in, there is no


Any time mini-setup (or more generally, the PnP system) discovers a new device for which Windows XP provides an out-of-the-box driver, the OS looks for the driver in, even if the driver is already installed. I suppose that even insignificant hardware differences between the source machine and the target machine, such as keyboard or mouse being in a different USB port, might cause mini-setup to look for, even though a perfectly up-to-date copy of the file it's looking for is already installed.


Solution: make sure your image has an (or in the case of sp2) in c:\windows\driver cache\i386. If it's not there, you can copy it from an expanded copy of SP3 and inject it during the post-imaging phase of your OSD script / provisioning template.

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.

This has been published elsewhere on this site ( But I thought I'd keep a pointer here because I intend to publish some short articles and updates in this blog - much quicker than reissuing the entire document.


As a starting point, let's go back to the current version of the document (rev 9). There are siginifcant changes in rev 9. The inventory scanner has been designed out of the process. VB scripts have been replaced with compiled autoit scripts (sources included). An experimental method is suggested to inject mass storage drivers. The document covers both OSD and provisioning. As before, rev 9 remains Windows XP centric. No attempt is made to cover Vista.





This is not a document approved by LANDesk Software. The utilities that come with this document are not supported by LANDesk Software customer support. The author welcomes comments and suggestions and will provide support on a best-effort basis. Direct any comments to [email protected].




The document has been superseded by Rev 9.1. See this article. I'll keep Rev 9 available here for a limited time "just in case".

You will have seen the button in the console: Manage the drivers in the Windows PE image. Using that button to add a network driver is entirely straightforward. Much less so in the case of a mass storage driver, however. As you can read in, if you just click your way through the wizard and do everything right, chances are things won't work for you. You need to edit one of the driver files (txtsetup.oem) to reflect the relevant hardware ID for your target machine. If you have multiple target machine types, you may need to import the same driver multiple times, each time with a different txtsetup.oem.


This article describes an alternative approach that avoids the need to customise any files, or to inject the driver multiple times.


But first, let's make an observation about SATA drivers. Most of today's desktop and laptop machines are using intel SATA chipsets. If the processor is intel, then usually the SATA controller is intel. In general (there may be a few older machines that break this rule), all these machines can use the same SATA driver. The PC manufacturers simply pass through the original intel driver with no customisations (except a new wrapper for licensing reasons). If there is a difference, it will be that the manufacturer's driver is an earlier version that doesn't support some of the newer hardware. If you want a WinPE image that runs on as many machines as possible, your best bet is to use the latest intel driver. Chances are it will work on all your SATA desktops and laptops. One driver fits all.


The recipe is as follows:

  1. download intel SATA driver (aka "matrix storage manager"):
  2. create folder on your core server, e.g. c:\intelsata
  3. unpack driver (without installing it): iata88enu.exe -a -p c:\intelsata
  4. wpeaddmsd /inf=c:\intelsata\winall\driver\iaahci.inf

The program used in step 4 (wpeaddmsd) is included in the attachment. It's a compiled autoit script (source included). Also in the attachment is a document that describes both the GUI method and the alternative method in detail.


Note: this article has effectively been superseded by this new article, which automates things further (downloads and unpacks the intel driver for you) and also imports a comprehensive NIC driver pack.