The Realm of the Verbal Processor

XP Mass Storage Drivers – a Better Way

Anyone who has done Operating System Deployment with ConfigMgr will tell you that the toughest part of getting it working is mass storage drivers…simply getting XP to be able to talk to the hard disk after the image is laid down. The root of the issue is that the new hardware that we are deploying Windows XP onto didn’t exist when XP was released. In particular, the hard disk controllers are new, and XP doesn’t have drivers to be able to communicate with the newer hardware…it needs a driver. In particular, most corporate computers have an Intel chipset, but XP has no native support for the AHCI/RAID chipsets. XP needs the Intel Matrix Storage Manager driver for these chipsets.

This typically comes out during a deployment as a Blue Screen of Death with a Stop Code of 0x0000007b (0x7b). If you ever see that stop code…most likely it is a mass storage driver issue.

Now…I’ve battled these for a while. ConfigMgr includes the ability to dynamically inject the driver during the deployment which is great. It works well as long as you know specifically which driver goes with a given computer (see my previous post). However it is cumbersome. If you don’t know the driver, you can waste a good bit of time figuring out which driver to inject. There’s got to be a better way…and there is. At the last Minnesota System Center User Group, Joey Gleason mentioned a really helpful portion of a session from MMS related to that. In it Ben Rampe talks about this very problem and does a good job of outlining a better way of handling this. I reviewed the session and found it to be very helpful. The rest of this blog post is a combination of knowledge I had previously and info from that session. The outline of the rest of this post looks a lot like Ben’s slidedeck…which is to be expected in a technical post…there are only so many ways to outline the same process. :-)

First, in the MMS session (Session ID BA21), Ben makes note that there are eight different versions of the Intel Matrix Storage Manager drivers that have been released by Intel…with even more versions that come directly from the OEMs. On top of that…new versions do not necessarily replace or supersede the previous versions. Looking at the INF files that are part of the driver you will see the plug and play IDs that are supported by that particular driver. The PnP ID will look like: PCI\VEN_8086&DEV_3A02&CC_0106.

Now…of the numerous versions of the drivers…and the numerous hardware devices that are supported, there is a significant amount of overlap. So how many of those drivers are actually needed? According to Ben, only four are needed to cover nearly all Intel storage devices. Those four versions are:

• 5.5.0.1035
• 7.0.0.1020
• 7.8.0.1012
• 9.6.0.1014

So…with that info in hand…how do we make it work? First…get a copy of each of those versions of the driver. Create a folder for each one, and unpack the following files into the folders:

• iaAHCI.cat
• iaAHCI.inf
• iaStor.cat
• iaStor.inf
• iaStor.sys
• TXTSETUP.OEM

What you should end up with is a folder structure that looks something like the following. The top level folder is the source of a ConfigMgr SW Package. In each of the “Intel…” folders would be the six files listed above for each of the drivers. If you have a computer that doesn’t use one of these drivers (SCSI drivers for example), then just add another folder underneath Drivers, and copy the required files into the folder.

• ConfigMgr_Package_Source_Folder
  • Drivers
    • Intel_5_5_0_1035
    • Intel_7_0_0_1020
    • Intel_7_8_0_1012
    • Intel_9_6_0_1014
  • CopyDrivers.bat

Note the “CopyDrivers.bat” file at the same level as the “Drivers” folder. This will be used to copy these folders to the root of the hard drive when you build your base image…a custom task sequence step. This could be a bat/cmd/vbs. The simplest method of copying the files is a simple bat/cmd file with a single line such as:

XCOPY “%~dp0Drivers\”*.* C:\Drivers /E /I /Y /Z

This package would be used in a “run command line” task sequence step that runs just before the system is sysprepped and the image is captured. Sysprep is executed during the “Prepare OS” step in a Build and Capture task sequence, so it will need to occur before that step.

Additionally, in the “Prepare OS” step, be sure to check the checkbox for “Automatically build mass storage driver list”.

So…we have the drivers copied to the drive, and we have told sysprep to build the list…now we have to tell it which driver to use for a given PnP ID. We do that in the sysprep.inf file. There are a couple of key sections in this file that we have to set. First we need to Ensure that the folders we have copied are listed in the OEMPnPDriversPath in the [Unattended] section. Second, we need to specify each PnP ID and it’s corresponding driver. What you end up with is a Sysprep.inf file that looks similar to the following. (The full sysprep.inf file is downloadable at the bottom of this post.) If you added support for other controllers, you will need to modify both the OEMPnPDriversPath and add an entry into the SysprepMassStorage section.

[Sysprep]

[Unattended]
OemPnPDriversPath=”Drivers\Intel_32_v5_5_0_1035;Drivers\Intel_32_9_6_0_1014
UpdateInstalledDrivers=Yes

[SysprepCleanUp]

[SysprepMassStorage]
PCI\VEN_8086&DEV_24DF&CC_0104=C:\Drivers\Intel_32_v5_5_0_1035\iastor.inf
PCI\VEN_8086&DEV_282A&CC_0104=C:\Drivers\Intel_32_9_6_0_1014\iastor.inf

When the image is built, those settings will ensure that the system will be able to boot because it now knows which driver to use for each of the Intel storage controllers. However…if we leave it at this point, we will have performance problems. Because we have added storage drivers to the critical device driver database for devices that don’t exist, we need to remove these nonexistent devices. These extra devices in the critical device database can slow down boot times, so we want to make sure we get rid of them. That is done using the “sysprep.exe –clean” command. But…before we can do that, we need a different sysprep file…one that has the [SysprepCleanUp] section populated. Now…to get that populated, you can get this info in a couple of ways.

• Deploy the image to a system. Open c:\windows\system32\$WinNT$.inf in a text editor and copy the SysprepCleanUp section from it.
• On your image build computer…once you have all of the drivers staged…run “sysprep.exe –BMSD”. Then copy that section from the Sysprep.inf file.
• Or…do it the easy way…copy the file at the end of this blog post. :-) It contains the [SysprepCleanUp] section that Joey grabbed by using one of the previous methods.

During the image deployment is when you will run the command to clean out the critical device database. I will typically throw this towards the end of the task sequence. It is another “run command line” step that uses the Sysprep package as its source. This one uses another vbs/bat/cmd file to copy the files locally, then execute a command to clean up the nonexistent devices. Lastly it cleans up after itself by deleting the Sysprep folder. This file will need to be part of the sysprep package in ConfigMgr (in the same folder as sysprep.exe). Again…the simplest method is a batch file similar to this:

xcopy “%~dp0″*.* C:\Sysprep /E /I /Y
“C:\Sysprep\Sysprep.exe” -Clean
RD /Q /S “C:\Sysprep”

Following this process, you should be able to build a single XP image that will work on the vast majority of your hardware.

Download the full sysprep.inf file. Note: this file is a Word Document…this is because of a limitation of my hosting provider. You will need to copy/paste it into a text file (being careful that it pastes straight quotes instead of smart quotes). Standard disclaimer…I make no guarantees about the file…use at your own risk!

September 8, 2010 - Posted by Jarvis | ConfigMgr