Video Screencast Help

Accelerating Sysprep Mass-storage Testing with Windows XP

Created: 15 Jun 2012 • Updated: 26 Jul 2012 | 13 comments
Language Translations
ianatkin's picture
+18 18 Votes
Login to vote

For those that still have to maintain XP images, today's article shows my trick for testing the validity of new mass-storage drivers. This enables me to confirm mass-storage support in sysprep in minutes rather than hours.

Introduction

The standard process for introducing  additional mass-storage support into your images is to use Microsoft's Sysprep. The general best-practice method for this process is as follows,

  1. Open up VM containing 'golden' image
  2. Add to sysprep.inf the device line for your new controller
  3. Add to c:\sysprep\massstorage you new driver
  4. Run Sysprep
  5. Upload image
  6. Deploy image on target hardware
  7. Hope you don't go in a STOP 7B loop

One of the problems with this process is that sysprep does not flag if it fails to add a mass-storage driver referenced in sysprep.inf. Further, as most of us know, the above process takes at least 4 hours to see through end-to-end.  So to find on deployment that the mass-storage driver has not taken and you're in a STOP 7B reboot loop can be frustrating.

Having suffered this pain many times over my years with XP I developed tools and working practices to streamline the process. For example, to upgrade mass storage support I now just update my images offline and then backfill the support into the sysprep file. Driver identification is also pretty simple when using my driver profiler.  

When it comes to adding new mass-storage support however, there are no good shortcuts.  The process can be made smarter however. I add a step between 4 & 5 above to confirm that the mass-storage driver has taken. This enables me to determine that the driver is valid before proceeding to the image upload stages. This additional step saves hours (if not days); I only upload and test images which I am already confident that the mass-storage support has been successfully loaded into.

This is what I do.

Step 1 - Prepare VM with Golden Image

I have in my VMs various golden images which have been snapshotted before sysprep has been executed. So, I fire up the golden VM, and revert this back to the known clean state. If you do things this way, starting the process is painless and much less likely to make you groan when new hardware arrives...

Step 2 - Prepare C:\Sysprep Folder

For this phase, I copy my sysprep folder to the system drive. This contains the sysprep files, the mass-storage driver folders and a streamlined sysprep.inf file which contains only two mass-storage support entries. The first entry corresponds to the new driver I want to test, and the second is a known working driver.

Below is an example from some recent testing with a troublesome AMD driver,

 

[SysprepMassStorage]

; Test Driver -AMD AHCI Compatible RAID Controller
PCI\VEN_1002&DEV_4391&CC_0106=C:\sysprep\massStorage\AMD\ahcix86.inf 


; Known working driver for Dell Optiplex 990 and Latitude E6420/E6320
PCI\VEN_8086&DEV_1C02&CC_0106=C:\sysprep\MassStorage\ICH\iaahci.inf

Note that this is the entire SysprepMassStorage section from my sysprep.inf -everything else has been removed to allow rapid testing

Step 3 -Delete CriticalDeviceDatabase registry key

This phase makes the detection of sysprep added mass-storage drivers a little easier. Open up regedit, and navigate to the key HKLM\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase. This key contains the mass-storage driver data which is used by Windows on boot. Right-click it and delete it with all it's  subkeys.

This delete gives us a clean slate and makes it easy to see when support is added.

Step 4 -Run Sysprep

Now execute sysprep with the command,

sysprep.exe -reseal -mini -noreboot

This should be now very quick to run -typically less than a minute. On completion, hit refresh in regedit (no need to reboot) and you should see that the CriticalDeviceDatabase key has been recreated. It should now contain two entries which directly relate to the two mass-storage entries in your sysprep.inf,

If it turns out that you've only a single entry here for your known good driver, then you've got a problem. Double check that you've got all your driver files in the correct locations as referenced in sysprep.inf. If that all looks OK, then it's time to seek another driver, dump this in your referenced mass-storage folder, delete the CriticalDeviceDatabase key and try sysprep again. No need to reboot. 

If however it turns out that the CriticalDeviceDatabase key is not present once you've hit refresh, then you've hit one of those odd situations where sysprep just hasn't executed properly. Normally, if we sysprep with the standard several hundred line mass-storage sysprep file, the process can take about 20 minutes. However with such a trimmed down sysprep, it exits pretty quickly. It's therefore that's hard to judge if we've hit that premature exit scenario. This is why we have that known 'good' line in the sysprep.inf; it is so we can confirm that sysprep has indeed run and rebuilt the critical device database.

Step 5 - Do It For Real

Assuming you've managed to find a driver which loads into the critical device database, you can now update your production sysprep.inf with the driver entry. Simply revert your snapshot and go through the full sysprep process.

Conclusion

Today's tip takes some of the uncertainty and pain away when adding mass-storage support into your sysprep.inf files. I find that although this adds an extra 10 minutes to my process, it adds confidence to my sysprep image uploads, and potentially saves many hours when encountering troublesome drivers.

The difficulty is now simply in finding the right driver in the first place. For that you can help yourself a little by checking that you've got a driver which has properly decorated with OS versions. For example below is an extract from an inf file which I'd consider to be good,

 

[Manufacturer] 
%ATI%=ATI,NTx86.5.1,NTx86.5.2


[ATI.NTx86.5.2]
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4392&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4393&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1022&DEV_7802&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1022&DEV_7803&CC_0104


[ATI.NTx86.5.1]
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4391&CC_0106
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4392&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4393&CC_0104
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4394&CC_0106
 
Here we can see from the section tags that the driver is valid for 32-bit OS versions 5.2 (Windows 2003 Server) and 5.1 (Windows XP) respectively. This is fantastic and gives us confidence we've got the correct driver for our XP sysprep process.
 
Here is an extract of a driver inf which I'd be instantly suspicious of,
 
[Manufacturer] 
%ATI%=ATI

[ATI]
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4392
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4391
%NapaDesc%=Napa_Inst,PCI\VEN_1002&DEV_4393
 
As you can see there are no decorations to let us know what the target OS is which is not good. My confidence of loading this driver would therefore be pretty low.
 
Hope this helps those who still have to support XP over the next year or two.
 
Kind Regards,
Ian./
 

Comments 13 CommentsJump to latest comment

b3tts32's picture

A+ Ian! I spent days on this without much avail. Keep the tips, tricks, and articles coming. They're much appreciated!

+1
Login to vote
riva11's picture

Great and useful article. Voted, created a bookmark and shared to the rest of the world !

+1
Login to vote
ianatkin's picture

For anyone that thumbs down, it would be useful to know why. You can do this privately!

I am genuinely interested to know why you felt strongly enough to thumbs down rather than just ignore the tip.

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

+1
Login to vote
riva11's picture

@Ian, oh no... it was my fault!  The main problem is the error generated on mobile browsing , in fact on my iPad the first time generated an HTML error during thumb up vote. Maybe the thumb down was generated later..

P.S.  and of course , I confirm my positive evaluation about your article... smiley

 

0
Login to vote
ianatkin's picture

I can call off the dogs now... ;-)

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

+1
Login to vote
Eshwar's picture

keep posting...

Cheers,

Eshwar

0
Login to vote
BBC's picture

This is the main reason why I moved away from sysprep images a few years ago and so avoid that issue completely.

With this I put up a poll as I'm much interested in how many of the community do no longer use Sysprep imaging on the Microsoft front, same as me. Please visit and vote on the poll here.

-BBC

0
Login to vote
Gibson99's picture

I still use sysprep images even w/ our win7 build job, because there are customizations we do that i haven't figured out how to replicate when doing SOI.  

If a Connect post helped you out, be sure to click "Mark As Solution" or the "Thumbs Up" button to let other users know about it.

0
Login to vote
michael cole's picture

Nice spot Ian, going to spread the good news :)

Michael Cole

Principal Business Critical Engineer

Business Critical Services

+1
Login to vote
WHUK-Barb's picture

Wow, should I call it a pleasant coincidence or is it my search skills. We've had a client who's come up twice with ref. to sysprep images and I've had no clue with handling his queries which is when I found the info. here. I owe you ianatkin.

Thanks a ton.

Best Regards

Barb

0
Login to vote
ianatkin's picture

It's your amazing search skills I'm sure! If you are going to Vision in Barcelona, feel free to hunt me down and repay your debt in beer.... ;-)

Ian Atkin, IT Services, Oxford University, UK

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads

0
Login to vote
gerardsweeney's picture

I don't know if it's of any use, but I use an AutoIt script on my WinPE job.

 

After deploying the XP Sysprep'd image, the script looks for Mass Storage devices and interrogates the DP_MassStorage file from DriverPacks for an appropriate driver inf file. It then uses PEIMG to inject them into the newly restored Windows image.

It's not the quickest bit of code in the world - it maybe adds about 2-3 minutes to the deployment. Most likely because my crappy coding is VERY lazy :)

However, it does seem to work, and has saved us a lot of hassle when we got in new hardware this summer with 2 different types of SATA controller from our current XP images.

 

Cheers,

Gerard

0
Login to vote
xpigx's picture

Gerard, Do you have a link to that script or can you post it or send it over, it sounds interesting.

0
Login to vote