Skip navigation

Preferred server tools

Posted by jan.buelens Jan 21, 2010

This used to be buried deep in some thread to do with provisioning. But quite a few people seem to have found it there. In response to several requests, I am publishing a new version here that will work with both LDMS 8.8 and LDMS 9.0.

 

Preferred Server Tools came about as a workaround for the lack of preferred server support in OSD and provisioning. LDMS 9.0 fills that gap, but only for OSD.

The essence of the tools is perhaps prefmap.exe, which will map a drive to the preferred server as in the following example:

 

prefmap /drv=I: /shr=images /usr=<username> /pwd=%pwd%

 

This command will map the I: drive to a share called images on the site's preferred server, using the specified credentials.

Rev 9.0 of the HII package was published in December 2008. Since then, a number of the tools have been updated for a number of reasons - bug fixes, enhancements, clarifications... Rev 9.1 consolidates all of these updates.

 

The most important change is perhaps HalConfig. As explained in two earlier articles in this blog, the "classic" process of achieving HAL independence, based on downgrading the HAL to a "lowest common denominator", has effectively broken down with the advent of the intel Montevina chipset.

 

Other changes include a progress bar in CopyDrivers, wildcard matching in CopyDrivers and more consistent logging.

Attached to this article is a set of tools - which I will collectively refer to as "the driverpack tool" - that allow you to apply a comprehensive driver pack to your 8.7 or 8.8 WinPE image. The tool will not work with LDMS 9. The driver pack itself is not provided. Instead, a script is provided that will collect it from the intel and broadcom web sites.

 

The process could hardly be simpler:

  1. Unpack the attached file to a folder on your core server.
  2. Run one of the tools (wpedownload) to download the driver pack
  3. Run another tool (wpedrivers) to apply the driver pack

 

More complete instructions are provided in the attachment.

 

Why would you use this tool rather than the "Manage Drivers in WinPE image" button in the console?

 

The advantage of this tool is that, rather than import individual drivers on an as-needed basis, it lets you import a whole driver pack, comprehensive enough to support most of today's desktop and laptop machines. This is possible because of the large number of PCs using intel SATA controllers and intel or Broadcom NICs. Having applied a driver pack that includes the latest Broadcom NIC and intel NIC / SATA drivers, your WinPE image will probably support all machines based on these controllers, no matter which PC manufacturer you bought them from.

 

If you are aware of DOC-1157, note that the procedure described in that document is not needed when you use the driverpack tool. Note also that the driverpack tool is a superset of the tool described in this article.

 

Need the AMD SATA driver?

 

The AMD SATA driver is not provided (i.e. not downloaded for you by wpedownload). This is for the simple reason that I can't find a place to download it from. But if you have a version of the driver from your PC manufacturer, you can easily add it. Just create a subfolder called amd.msd in the driver pack folder. Put the driver files in it (ahcix86.inf and ahcix86.sys). Wpedrivers.exe will find the driver (based on the folder's .msd extension) and import it.

 

Additional NIC drivers can be added in the same way (call the subfolder xxx.nic).

Updates:

  • The attached file was updated to V1.0.1 on 23 June 2009. The original version had a problem when launched from a path with an embedded space.
  • Updated 20 July 2009 (V1.2). One of the intel URLs had changed.
  • Updated 4 August 2009 (V1.3). Intel released new drivers. The SATA driver is now V8.9, the NIC driver pack is V14.3. There was a subtle change to iaahci.inf (sata driver) that the old version could not handle.
  • Updated 1 September 2009 (V1.3.1). Previous versions didn't like the vmscsi driver.
  • Updated 6 October 2009 (V1.3.2). Previous versions didn't like AMD SATA driver.
  • Updated 10 March 2010 (V1.3.3). Intel released new NIC drivers. The download URL and filename had changed.
  • Updated 4 May 2010. The Broadcom URLs had changed.
  • Updated 22 July 2010. The intel NIC URL had changed. Intel NIC driver pack now V15.4.1.

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\sp3.cab (that's for a Windows XP SP3 system - for SP2, it would be sp2.cab). If you update a pre-SP3 system by applying SP3, you will have an sp3.cab. But if your master system was built from a Windows XP CD with SP3 slipstreamed in, there is no sp3.cab.

 

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 sp3.cab, 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 sp3.cab, 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 sp3.cab (or sp2.cab 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 sp2.cab / sp3.cab in c:\windows\driver cache\i386. If it's not there, take it from an expanded copy of SP2 / SP3.

    hal.dll
    halaacpi.dll
    halacpi.dll
    halapic.dll
    halmacpi.dll
    halmps.dll

    ntkrnlmp.exe
    ntkrnlpa.exe
    ntkrpamp.exe
    ntoskrnl.exe

  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 sp2.cab / sp3.cab 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.

 

Notes:

  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 sp2.cab / sp3.cab 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 (http://community.landesk.com/support/docs/DOC-2714). 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.

 

 

Disclaimer:

 

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].

 

Attachments:

 

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 http://community.landesk.com/support/docs/DOC-1157, 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"): http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=17412
  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.

Feedback