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!
Background
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 2.6.18.8 and 2.6.27.7 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 --------------
This script header contains all the variables the batch script requires to update your image, and i've pre-populated it with example entries for you. Broadly speaking, there are three sections,
- 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,
- Img_Path
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.
- Img_File
This variable stores the filename for the image
- Volume_Name
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 section has just the one variable,
- Image_Explorer
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.
Driver Data
This is where it get's tricky.
Running the Driver Injection Script
Now you've configured the script, let's run it. First, change the .txt extension to .bat. Next, ensure you have local admin rights on the machine your are running on (this is necessary to allow the script to mount a system hive), and you'll need full rights to the image file location.
On execution, you should see a window similar to that below,
Here you can see that the script found and successfully updated the image with the configured mass-storage driver entry. Should you now deploy this image, you should find to your amazement that those STOP 7B error messages have vanished!
Auditing the Injection
In order the keep track of the changes made to your images, the injector script creates a folder called Mass_Storage_Injection which lives with the amended image file. In this folder you'll find a date-stamp folder, and within that a log of the process with the original (and modified) system hive.
This not only enables you to keep track of exactly what was done to the image, but it also gives you the chance to restore the registry should you need to.
What Does the Injection Script Do?
If you've gotten this far, its because you want to know a bit more about how the script works. Here's the basic steps,
- 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!
Kind Regards,
Ian./