Reducing Drive Images
Reducing our drive images (we use Ghost from Symantec) has been a goal of mine for a long time. If you have ever had to update multiple Ghost images because of a major or even minor update, you know what I mean. I have now updated the image to work on all our Desktop PCs; we will continue to use a dedicated laptop image, due to the fact it has a lot of different software and hardware installed on it.
The changes needed to support multiple images were mostly done at the sysprep
level.
For those of you unfamiliar with disk imaging or sysprep, here is the scenario. You build a machine by installing the OS, drivers, and applications that all staff will use (for example, Flash and Adobe Reader). Next, you copy sysprep and associated files to c:\sysprep, then run sysprep on the machine, and re-seal it. Then you boot the machine with a boot disk that includes Ghost or another imaging tool, and image the hard drive. That image can then be used to clone 100 or 1000 more machines just like the image master (the image master is the PC you built the image on). After you dump the image to the target PC and reboot it, mini-setup runs and you can change a few settings on the PC, like its name and Domain membership, and then it reboots once more, and is ready for use.
OK, great, you have an image you can use to deploy multiple computers of the same make and model, but what if you have five different types of computer you are supporting, and they have different hardware, and different hardware drivers? Well, that is the tricky part. This is where you change the sysprep.inf file to work with multiple computers.
When you sysprep a computer to seal it, by default, it only supports one type of HAL, it doesn’t add any new drivers for the PC, and it only supports one type of mass storage controller. If you add drivers, Windows setup files, and edit sysprep.inf to use these files; your image should support multiple computers. Here’s how I did it.
Take all the OEM drivers from your various platforms, and organize them into a single folder called Drivers, with a subfolder for each platform/version. For example, drivers/system/ and drivers/system/gx280. I already had this folder structure under I386\$oem$\$1, as Windows Setup uses these drivers for our various platforms. Windows Setup refers to these drivers through the unattended.txt file created by Setup Manager (another part of the deployment tools). Copy the drivers folder to the c: drive of your image master. Add the line OemPnPDriversPath=drivers\audio;drivers\audio\280 (and so on) to the [Unattended] section of your sysprep.inf file.
Copy all your sysprep files to a folder on the boot volume, for example, c:\sysprep (this procedure is the same for all sysprep installs).
Next, copy the whole i386 folder from your XP CD or administrative installation share, to c:\sysprep. I did this to guarantee my multi-image master works. During mini-setup, the folder c:\sysprep and all its subfolders are deleted, so the Windows install files are deleted, and won’t take up valuable hard drive space. To use the files, add this line to the [Unattended] section, InstallFilesPath=c:\Sysprep\i386.
The HAL may be different on your various computers. For us, we had two HALs, ACPI Uniprocessor and ACPI Muliprocessor. The Multiprocessor HAL was actually from PCs with Intel chips, where Hyperthreading was enabled. We build our master image on a multiprocessor HAL PC, then downgrade it if necessary via sysprep, with this entry in the [Unattended] section of the sysprep.inf file:
UpdateUPHAL=ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf
The last major change has to do with the hard drive controller, and the various drivers it uses. Mass storage drivers need to be loaded or the PC may not boot after mini-setup. You can add these lines to your sysprep.inf file:
[Sysprep]
BuildMassStorageSection=Yes
[SysprepMassStorage]
Yes, leave the SysprepMassStorage section blank, as when you run Sysprep it will build this section of the file. Yes, this adds time to the sysprep process, because it is adding an entry for every mass controller driver Windows Setup has access to. The alternative, is to build you own SysprepMassStorage section. I won’t go into detail on that here because that could be a whole article in itself. I use the easy method, and yes, when sealing the image master it takes longer, but running mini-setup on the client doesn’t seem to take much longer.
Finally, after creating my multi-computer master image, I tested it to verify it works. The major difference seems to be, that after imaging you have to re-install the plug and play monitor, and reset the resolution and color settings. This adds another 30-seconds of work for the tech that is deploying the PC. There is also the issue of applications for each platform. On a single-computer image, you can include OEM software that came with the PC, for example DVD playing software, CD burning software, or various manufacturer-supplied utilities. Obviously, you’ll want to leave these out of the master image and add them as needed. I’ll be working on that problem next.
Information Sources
The Windows Deployment Tools help files. If you aren’t already using sysprep, download it here, and read the ref.chm file. Also check out Microsoft’s Desktop Deployment page.
Thanks to John Savill for maintaining the FAQ for Windows, over at WindowsITPro.com. He explains what a Hal is and how to tell what kind you have. What is the HAL? http://www.windowsitpro.com/Articles/ArticleID/48583/48583.html. How to determine your HAL version: http://www.windowsitpro.com/Article/ArticleID/48585/48585.html.
Thanks to David Carlin, for his post Imaging machines using different HALs w/sysprep
From David Carlin’s blog, http://blog.case.edu/djc6/2005/09/22/imaging_machines_using_different_hals_wsysprep.
He provides the tip to build you image on a computer with a multiprocessor HAL, then downgrade it to uniprocessor if needed.
Thanks to Space Trout, http://www.spacetrout.com/2005/11/25/domain-ho-ho-frigging-ho/, for the post on the BuildMassStorageSection = Yes post. Although this is listed in the Ref.chm help file that comes with the Windows XP Deployment Tools, I didn’t associate that with the constant reboot after loading MUP.SYS. (If your PC is rebooting after imaging, and booting in safe mode shows the last file loaded was MUP.SYS, you are most likely having an issue with your mass storage controller driver.
Update 6/11: This article by Shelly Bird on TechNet Magazine is helpful, and explains a good method for setting up your OEM drivers folder for Sysprep. She recommends a simpler folder structure with very short folder names. For example, your drivers for video go in c:\drivers\v1, c:\drivers\v2, etc.
The changes needed to support multiple images were mostly done at the sysprep
level.
For those of you unfamiliar with disk imaging or sysprep, here is the scenario. You build a machine by installing the OS, drivers, and applications that all staff will use (for example, Flash and Adobe Reader). Next, you copy sysprep and associated files to c:\sysprep, then run sysprep on the machine, and re-seal it. Then you boot the machine with a boot disk that includes Ghost or another imaging tool, and image the hard drive. That image can then be used to clone 100 or 1000 more machines just like the image master (the image master is the PC you built the image on). After you dump the image to the target PC and reboot it, mini-setup runs and you can change a few settings on the PC, like its name and Domain membership, and then it reboots once more, and is ready for use.
OK, great, you have an image you can use to deploy multiple computers of the same make and model, but what if you have five different types of computer you are supporting, and they have different hardware, and different hardware drivers? Well, that is the tricky part. This is where you change the sysprep.inf file to work with multiple computers.
When you sysprep a computer to seal it, by default, it only supports one type of HAL, it doesn’t add any new drivers for the PC, and it only supports one type of mass storage controller. If you add drivers, Windows setup files, and edit sysprep.inf to use these files; your image should support multiple computers. Here’s how I did it.
Take all the OEM drivers from your various platforms, and organize them into a single folder called Drivers, with a subfolder for each platform/version. For example, drivers/system/ and drivers/system/gx280. I already had this folder structure under I386\$oem$\$1, as Windows Setup uses these drivers for our various platforms. Windows Setup refers to these drivers through the unattended.txt file created by Setup Manager (another part of the deployment tools). Copy the drivers folder to the c: drive of your image master. Add the line OemPnPDriversPath=drivers\audio;drivers\audio\280 (and so on) to the [Unattended] section of your sysprep.inf file.
Copy all your sysprep files to a folder on the boot volume, for example, c:\sysprep (this procedure is the same for all sysprep installs).
Next, copy the whole i386 folder from your XP CD or administrative installation share, to c:\sysprep. I did this to guarantee my multi-image master works. During mini-setup, the folder c:\sysprep and all its subfolders are deleted, so the Windows install files are deleted, and won’t take up valuable hard drive space. To use the files, add this line to the [Unattended] section, InstallFilesPath=c:\Sysprep\i386.
The HAL may be different on your various computers. For us, we had two HALs, ACPI Uniprocessor and ACPI Muliprocessor. The Multiprocessor HAL was actually from PCs with Intel chips, where Hyperthreading was enabled. We build our master image on a multiprocessor HAL PC, then downgrade it if necessary via sysprep, with this entry in the [Unattended] section of the sysprep.inf file:
UpdateUPHAL=ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf
The last major change has to do with the hard drive controller, and the various drivers it uses. Mass storage drivers need to be loaded or the PC may not boot after mini-setup. You can add these lines to your sysprep.inf file:
[Sysprep]
BuildMassStorageSection=Yes
[SysprepMassStorage]
Yes, leave the SysprepMassStorage section blank, as when you run Sysprep it will build this section of the file. Yes, this adds time to the sysprep process, because it is adding an entry for every mass controller driver Windows Setup has access to. The alternative, is to build you own SysprepMassStorage section. I won’t go into detail on that here because that could be a whole article in itself. I use the easy method, and yes, when sealing the image master it takes longer, but running mini-setup on the client doesn’t seem to take much longer.
Finally, after creating my multi-computer master image, I tested it to verify it works. The major difference seems to be, that after imaging you have to re-install the plug and play monitor, and reset the resolution and color settings. This adds another 30-seconds of work for the tech that is deploying the PC. There is also the issue of applications for each platform. On a single-computer image, you can include OEM software that came with the PC, for example DVD playing software, CD burning software, or various manufacturer-supplied utilities. Obviously, you’ll want to leave these out of the master image and add them as needed. I’ll be working on that problem next.
Information Sources
The Windows Deployment Tools help files. If you aren’t already using sysprep, download it here, and read the ref.chm file. Also check out Microsoft’s Desktop Deployment page.
Thanks to John Savill for maintaining the FAQ for Windows, over at WindowsITPro.com. He explains what a Hal is and how to tell what kind you have. What is the HAL? http://www.windowsitpro.com/Articles/ArticleID/48583/48583.html. How to determine your HAL version: http://www.windowsitpro.com/Article/ArticleID/48585/48585.html.
Thanks to David Carlin, for his post Imaging machines using different HALs w/sysprep
From David Carlin’s blog, http://blog.case.edu/djc6/2005/09/22/imaging_machines_using_different_hals_wsysprep.
He provides the tip to build you image on a computer with a multiprocessor HAL, then downgrade it to uniprocessor if needed.
Thanks to Space Trout, http://www.spacetrout.com/2005/11/25/domain-ho-ho-frigging-ho/, for the post on the BuildMassStorageSection = Yes post. Although this is listed in the Ref.chm help file that comes with the Windows XP Deployment Tools, I didn’t associate that with the constant reboot after loading MUP.SYS. (If your PC is rebooting after imaging, and booting in safe mode shows the last file loaded was MUP.SYS, you are most likely having an issue with your mass storage controller driver.
Update 6/11: This article by Shelly Bird on TechNet Magazine is helpful, and explains a good method for setting up your OEM drivers folder for Sysprep. She recommends a simpler folder structure with very short folder names. For example, your drivers for video go in c:\drivers\v1, c:\drivers\v2, etc.
15 comments:
I recently had to try to reduce the image size of a desktop build for a medium sized company.
I found a pitfall there that you are doing here to.
I would suggest that when you define your driver structure you don't base it on machine models. This is because quite often the same vendor utilises the same hardware in different models and suddenly you get driver duplication. I found this in particular with the Dell product suite.
Instead I broke the structure down into type (Sound, Video etc) and then used a 6-8 alpha-numeric folder name encompassing the hardware component (Broadcomm 57G became Broad57G etc).
I then tied the whole lot together with an Excel spreadsheet with two books.
The first book was just a straight list of Drivers, Folder Name, Version and Driver Date.
The second book then detailed each machine model, and the components identified within it.
It's more effort but ensured I knew exactly what driver/version/date was used in each machine and what machines shared components.
Once it was produced it wasn't much effort to maintain.
I used a great little tool called the Driver Toolkit to backup any drivers I couldn't locate online, and as a general driver identifying tool. It's available from http://www.driverguidetoolkit.com/
Cheers
Adam
That's good advice, Adam. I'll probably re-do the driver structure. Probably don't need the automated tool...yet, but maybe down the road.
Hi! My name is Chris and I work at Help.com. One of our members posted a question and after finding your blog which mentioned INF files, I thought you might have the expertise to respond either with an answer or at least a resource recommendation. This is the question that was posted.
"Hi there, I just bought a web cam, I got two computers, in one computer I installed the drivers I plug the camera and everything works fine, but in my ohter PC every time I plug the camera I get a Windows message that says something like: the section requiered is not in the INF file, why do I get this message? How can I make my web cam work? I got Windows XP SP 2 as my OS."
http://mabbond.blogs.help.com/post/3/the-section-requiered-is-not-in-the-inf-file
Thanks!
I'm setting out to do something similar, thanks for the helpful pointers.
Some other goals I've set for this project are:
- seperation of system and user data by using two partitions and keeping the user profiles on D:\ and the rest on C:\ (where C=10Gb and D=whatver space is left)... this should help when re-ghosting a wayward machine (no user data to save/restore)
- OS and program separation: most non-core programs should be in seperate packages with a nice post-ghost installer on first run. This should make it easier to update/change apps, also you could install specific apps based on machine type (ie. speedstep for notebooks etc)
- maybe some autoIT or similar scripting to automate domain joining (when on local LAN) and other post-install tasks
Ambitious, no? At any rate, thanks for giving me some ideas :)
Hello Michiel,
The partitioning you could do with Diskpart.exe, I use a script to do that, or you can even use Ghost to do it. For post-ghost software installations, I use Altiris software delivery. It is expensive, but many people think it is the best software deployment tool out there. I have another post you might find useful: http://hdsurvivor.blogspot.com/2006/01/wmi-script-determine-pc-model-run.html
I use this script post-ghost, to determine the model of PC, then install any particular software for that model. As for joining the Domain, I have my sysprep.inf file setup so that it does that automatically. What I did was create a user account, then remove that user from all user groups, then I used the delegation of authority wizard in group policy to give it the rights to add computers to the domain. Then in the sysyprep.inf file, use that account to add the PC to the domain. So when a tech is running mini-setup on the PC after ghosting, the only thing they have to enter is the PC name, which I have not figured out how to automate very well yet...as we are sometimes using new numbers, sometimes re-using old numbers. Maybe someday I'll figure out a method to use the MAC address to determine the PC name via a WMI script. Yeah, that sounds good.
If you want a copy of my sysprep.inf file, let me know.
Glad you liked the post,
-Rob
Hi
I am trying to use the same image on multiple type of PC's & although it has been working okay on most pc's I am having problems with a laptop at the moment.
Background-
With the way I have setup Sysprep, it renames & adds the workstation to the domain automatically, detects the PC model & then tries installing the drivers & applications.
Problem, when this runs on a laptop, the drivers installation halts as there is a 'add new harware wizard' which finds some device which it is unable to find the driver at this stage & I have to manually cancel the wizard for the install to work. I want try & disable this wizard temporariy if possible or get this to work in any other way possible.
Thanks in advance
Rohit
Rohit,
I add all the drivers to a folder on the c: drive named Drivers, then edit my sysprep.inf file to list each folder, as I said here, "Copy the drivers folder to the c: drive of your image master. Add the line OemPnPDriversPath=drivers\audio;drivers\audio\280 (and so on) to the [Unattended] section of your sysprep.inf file".
If that doesn't work for you, take a look at this article at TechNet Magazine, where author Shelly Bird does a great job of explaining how to add drivers to a sysprep image. She lists tips for troubleshooting plug and play hardware.
Hi Rob!
I tried your idea About:
Maybe someday I'll figure out a method to use the MAC address to determine the PC name via a WMI script. Yeah, that sounds good.
very good! So, let me know if you did it. If yes, it may interest me as much.
Thanks
Ben
If you setup your driver structure as \drivers\audio \drivers\video \drivers\network etc... for multiple machine types and you get a BOSD on the sysprep pnp detection, good luck in figuring out what is causing it!
The right way to do it is have the structure by machine type on the CD/DVD or network drive and then detect the machine, copy the drivers to the hard drive and then create a custom sysprep.inf to point to only the drivers for that machine type.
We are looking at a PE boot that will then image the machine and then based upon the machine type copy in the drivers files specific to that machine into a standard structure on the hard drive. The image sysprep driver path will default to this standard structure.
What is gained? Only the drivers needed for the machine are installed. We know exactly the driver version being installed and don't have to guess weather the version is from another machine type that "might" be compatible with that machine, or not... i.e. BSOD.
Also any post sysprep process will be on the CD/DVD/Network which would then be able to be updated WITHOUT touching the core image itself. These would also be copied onto the machine after the image has been restored (before first sysprep boot).
To secure the environment, we will attempt to force the PE boot into locked down shell which will limit the ability of the users to access the hard drive while the process is being completed (detecting the machine / image process / etc...).
Short story is COMMON driver folders are a BAD THING. I have felt the pain of this in the past... and it sucks when it happens. Also you have NO idea what driver version is truly being installed on the machine if you have 20 different ATI driver versions being added to the pnp detection path. You think MS is going to figure it out for you?
Hello Latest Anonymous Poster,
You have some good point points in your comment, however, I think you can use a common drivers folder without getting bluescreens. Read the article here at TechNet magazine that talks about device driver installation during plug and play detection. Any drivers installed are logged in the %systemroot%\setupapi.log file. You can see exactly what driver is being detected and installed, and from which folder. The article also explains what the entries in the setupapi.log file mean. So if your machine blue screens during sysprep boot, you can check this file to see what went wrong. WinXP will scan every folder in your common drivers folder, until it finds the driver that most closely matches you hardware. This is a simple explanation, I recommend that article for the full story, as well as a few utility scripts that you can use to help with this process.
I like your idea about copying files down to the machine right after imaging and before reboot and starting sysprep. I do something similar with a WMI script that detects the model of PC and then installs any additional software required, but I currently have that set to run post-mini-setup.
I need to update the corporate images to handle the new DUO and QUAD processors and was messing around with switching around HAL prior to imaging, but maybe this will work. I will give it a try. Anyway, I Just thought I would throw my 2 cents in about doing drivers for a sysprep'd machine.
I was using a large driver database found here: http://www.driverpacks.net/
They are user submitted and do find pretty much everything, but are fairly sizable and run into the issues described above where it is picking drivers that work but not optimal drivers. I am going back to using my own set and will be using Zen addon image to drop them down after the image is deployed.
Anyway, if you do a large number of drivers, after so many characters defined in the OEMDrivers section of the inf, it will choke making large driver databases not functional.
I found this site that described sysprep and that there is a tool that updates the registry so that the directories you define is in the search list for PNP. Nice thing is it's free and can be run with switches. The site is here:
http://www.vernalex.com/guides/sysprep/index.shtml
There should be a file found on there called SPDrvScn.
Have fun.
Thanks for the tip, I'll definitely check out that product. Right now I'm not having too much trouble, The length of the OEMPnPDrivers path is 1024 characters max, (I think) and we're well below that. We only have 3 models of desktops to support right now. I wish Ghost had an easy way of adding files post-imaging, but as it is, I would probably have to build a WinPE disk that supported WMI, then add my script that detects the PC model (from the BIOS), then copy the files down from there. Of course with Vista and WinPE 2.0 coming right around the corner, this will probably all have to change. There is only one HAL in vista, for starters. And all your drivers will have to be signed. Plus, vista willhave its own imagin tools built-in (as the Vista DVD is an image-based install), so there might be a real simple way of just adding the drivers to that image an re-compiling it.
For anyone that may want to simplify auto-swapping Hals depending on computer model, HT, dual core, etc. Check out http://jimtsay.googlepages.com/mysysprep . This guy has written a great utility to that. Best of all its free!
Anonymous,
Any luck updating your corporate images to handle the new DUO and QUAD Processors?
Yes, we are using Core 2 Duo machines, and I did a fresh install of Windows XP SP2, updated my $OEM$ folder with the new drivers, and I continue to use the UpdateUPHAL=ACPIAPIC_UP,%WINDIR%\Inf\Hal.inf line in our sysrep.inf files. Works very well.
Post a Comment