Offline Updating of Mass-Storage Controllers in XP
Mass-storage controllers and Windows Imaging. As a combination, they're kinda like Uranium and critical-mass. Once the two come together, you really wish you were somewhere else.
Today I'll show you how to avoid meltdown and emerge radiation free from those not-so-rare confrontations with next-generation mass-storage controller hardware. With this download, you'll be able update the mass-storage support in your images within seconds, giving legacy images a new lease of life. With luck, this will free up the valuable time needed for your NS7 and Windows7 upgrades ;-)
Feel free to ammend, update and post revisions of this script back to Connect!
A few months ago, new PC and laptop hardware started to arrive at the office. As I stepped through the hardware evaluation process, the problem I dreaded most surfaced -the models were blue screening in mini-setup with the STOP 7B error message. This is never good. Sysprep images can tolerate Plug'n'Play device variations in the mini-setup process, but foreign mass-storage controllers are quite simply a killer. If setup cannot see the disks, it just can't proceed with install.
Altiris have tried to address this problem natively with DeployAnywhere, but this technology is now only being matured on the DS7 branch so will remain a little stunted in our DS6.9 environment. It also of course relies on WinPE automation for the driver injection process, and our primary automation environment is (of course) Linux.
So, for me it was a return to the Microsoft text-book process for extending mass-storage support in my sysprep images,
- Downloaded and unpacked the XP Mass-storage Drivers
- Collected the device IDs for the new model
- Added the device IDs to sysprep.inf to build driver support into the image
- Rebuilt image, sysprep'd and uploaded to server
- Tested image
And this has to be done for each image. I should add here that I'd previously completed a round of mass-storage updates for Linux automation in both the 220.127.116.11 and 18.104.22.168 kernel flavours. This meant that automation could see the disks just fine, so this allowed me to focus purely on adding similar support into our Windows XP sysprep process.
Within a couple of days I'd finished re-creating and syspreping the images, so it was time to hand off them off for further testing. This is actually the real resource hog -to be sure I hadn't broken anything, the images had to be tested against every model in our test lab. After a few days I got the all-clear, so the job was a good'un and I could once again get back to the day job.
Imagine my joy then when two weeks later I was informed our main desktop model was about to go end-of-life. The replacement was also not going to be one of the model's I'd just ratified. The new PC arrived the next week and while testing, lo and behold, the blue screens were back. This PC had a different flavour of the Intel5 series controller, one whose support I had not added into the image. I cursed myself at length for not adding all the device IDs from the latest Intel Matrix controller into the sysprep.inf file, and then promptly went off to the pub -I simply couldn't face rebuilding the images again.
Whilst reflecting over a pint of Guinness, I realised my expectation of our hardware procurement cycle bearing any resemblance to our image-rebuild cycle was just naive. It was time to get a bit smarter on this one. So, instead of spending the next few days re-building images, I spent the time instead looking at how I could script the injection of updated mass-storage controller drivers into our images.
The result was the attached little script which in about 5 seconds does the following,
- Mounts the XP image file
- Injects the mass-storage device support into the Windows registry
- Injects the updated mass-storage driver
- Unmounts the image
I've tried to make this script robust, but there are as always improvements to be made -so feel free to tweak. For example, in its current form this script only copes with updated mass-storage controllers -not entirely new ones. This isn't a huge problem for us (where every Dell and HP model we have seems to use an Intel controller) but it's worth flagging. I'm working on a proper INF parser to automate driver injection, but I don't exepect this to be ready for some weeks.
Let's crack on then and see how this script can be used.
Using The Mass-Storage Injection Script
Attached to this article you'll find the batch file UpdateImage_Lite_v1.1.bat. The top section of the batch file is the user-editable section, and looks as follows,
:: -------------- Start of user-editable Section -------------- SET Img_Path=S:\Images\Windows\test SET Img_File=XPSP3.img SET Volume_Name= SET Image_Explorer="C:\Program Files\Altiris\Express\Deployment Server\ImgExpl.exe" SET Driver=C:\MassStorage\ICH\iaStor.sys SET Vendor=8086 SET Device=2929 SET Service=iaStor : -------------- End of user-editable Section --------------
- Image Location Data
- Image Explorer Location
- Driver Data
Let's take a look at how to configure these now.
Image Location Data
In this section, we have the following variables,
This variable holds the absolute path to image file, and excludes the filename. In this case, my image is on the S:\ mapped network drive. UNC paths cannot be used.
This variable stores the filename for the image
Normally this is blank (at least it is in all of my images). However if you specifically configure a volume name in your images, you'll need to declare it here. You can use ImageExplorer to check if a volume name has been set.
Image Explorer Location
This is the absolute path to Image Explorer. I generally expect admins to execute this from the Deployment Server, so I've here configured the location Image Explorer to be on the express share (assumed on the C:\ Drive). This must again be an absolute path -UNC paths are not acceptable.
Full path to the updated driver which needs to be injected into the image. Here i've used the classic example of a revised iaStor.sys
This is the vendor ID. Most of us will indeed only be using Intel (8086) but a few out there might indeed be using ATI/AMD chipsets (1002)
This is the device ID for the controller in question. This can be scavenged from a new PC by opening up Device Manager, and viewing devices by connection. This allows you to navigate down the PCI bus, to the mass-storage controller and finally to your disk is hanging off it,
To get the device ID for the controller, all you need to do now is take a look at the controller's properties,
The Details tab reveals all as above. In the above example of the Intel ICH9M SATA AHCI controller, the device ID is 2929 as highlighted. This Device ID should of course match up with an entry in the driver INF file you've downloaded for the injection process. In this case, the iaAHCI.inf file has the following matching entry,
%PCI\VEN_8086&DEV_2929&CC_0106.DeviceDesc% = iaStor_mobl_Inst, PCI\VEN_8086&DEV_2929&CC_0106
Which you can find by scanning the inf file for the Device ID string "2929". This agreement between Device ID string revealed by Device Manager and your driver INF file provides the confidence that the driver you've downloaded for the mass-storage controller will work nicely once injected into the image.
Running the Driver Injection Script
Auditing the Injection
What Does the Injection Script Do?
- Check Variable Sanity
In order for the script to have a chance at executing successfully, the user-defined section of the script must be sane. This means for example, that image file must be present, and ImageExplorer available.
- Create Log Folder Structure
As the script is going to be making registry changes in your image, we need to find a place to log all the changes we're going to make and store the unmodified registry hive. Using mkdir magic with time stamps variables, this stage ensures we create a suitable folder structure.
- Extract System Hive
Did you know that ImageExplorer can be executed in batch mode? Well it can! This stage extracts from the image the system hive (C:\Windows\System32\Config\system) in silent mode and saves as backup copy as system.original
- Load the System Hive
Using the windows reg load command, the system hive from the image is then loaded under HKLM\TempHive
- Add Critical Device Database Entry
If a deviceID and VendorID have been entered, we can populate the critical device database section in the Windows registry (HKLM\TempHive\ControlSet001\Control\CriticalDeviceDatabase).
- Unmount the System Hive
Using the Windows reg unload command, the system hive is unloaded from the windows registry
- Inject the modified System Hive back into the Image
Using Image Explorer in batch mode once again, the modfied system hive is added back into the image
- Inject the Updated Mass-Storage Controller Driver
If a driver is specified, this in injected using Image Explorer in batch mode.
And that's it. Future versions may be a bit more intelligent... am working on it!