So, my friend and colleague Andrew Buford (winception) and I have been trying to tackle Windows XP Universal Imaging with SCCM. Why? Because we have a lot of old lab equipment computers which need the occasional refresh, and the software’s too old to run on Vista\7. XP Mode? That would be great if there were Win7 drivers for the capture cards. For some reason professors don’t like to buy new $15k controller cards (if available) for an operating system update. If you know of a workaround, let me know!
In any case, I’ve managed universal XP images in a few departments over the years, and the following are decisions which must be made when attempting this with SCCM.
Heavy vs Light, Pre vs Post Capture
First, you need to decide whether to inject a bunch of drivers on the system and hope for the best (heavy), or whether to attempt driver injection of the specific make\model needed (light). There are some pro’s and con’s to both methods. Heavy images are bigger, and sometimes driver conflicts cause trouble. However, the initial configuration is easier if you’re deploying to a wide range of SATA\RAID platforms. Light images are smaller, but it can take some work to find the exact driver needed and get it mapped correctly. The second decision is if driver injection will take place pre-capture or post-capture, and using what tools. In the end, I choose to use light images injected by SCCM (the only supported way). More on this in the next section.
These techniques aren’t all tried-and-true and they’re not complete solutions. They are the leads which Andrew and I pursued before choosing our imaging option.
Driverpacks.net MassStorage Driverpack
This is a heavy-image solution. Driverpacks.net offers a free “MassStorage Driverpack” with almost every Mass Storage .inf file available. It’s possible to extract this driverpack, reference it in sysprep.inf using a special EXE to make [sysprepmassstorage] section entries, then capture the image. This works really well, but doesn’t play nice with a SCCM ‘Build and Capture’ Task Sequence. If you attempt to automate the sysprep section by using SCCM’s “Prepare OS” task sequence action and a custom sysprep file, sysprep will not actually import the drivers from the [sysprepmassstorage] section into the registry’s critical device driver list, because they’re mostly unsigned.
“But wait!” you say, “you must have forgotten to include the correct driver signing policy lines in your [unattended] section of sysprep.inf!”. That’s what we thought, but it’s only true on deployment. During the sysprep reseal process (pre-capture), Windows File Protection pops up warnings which must be manually clicked for each driver in the driverpack. Since SCCM’s “Prepare OS” action hides all dialog boxes, you never see the warnings and sysprep times out. However, you can manually create the universal heavy image the first time by splitting the build and capture task sequence in to separate parts, and running the capture part from within the guest OS. You can then use the captured WIM as the base image for future build-and-captures.
Unfollowed leads \ possible workarounds:
- Disabling windows file protection by hacking sfc_os.dll with a hex editor, then restoring it after the ‘Apply Operating System’ action in the deploy task sequence.
- Running a build-and-capture in MDT instead of SCCM, which might show the WFP dialog boxes, allowing you to write an Auto-It script to accept them automatically.
- Using an offline sysprep tool
This is a light-image, closed-source, 3rd-party solution. If you currently own the proper versions of Symantec Ghost, you may have access to DeployAnywhere, which is a command-line utility run from Windows PE after the image is deployed. It scans the system for NIC and SATA drivers, references a driver database, copies the appropriate drivers to the windows volume, and then injects the driver paths into the registry. This method is elegant, and probably the best if you have the required software. Unfortunately, it means you have to keep a ghost console server around for driver database updates.
SCCM’s Apply Driver Package
In the end, we decided to go this route since it’s supported and the images will be smaller. We’re thinking that this will be good for XP Mode and MED-V. This method is similar to DeployAnywhere, and it’s all managed from inside SCCM Console. However, there’s a catch! You need a separate ‘Apply Driver Package’ task sequence action for each and every mass storage driver that you’d like to support. Wowza.
In a future post, we’ll share the end results of this project and a step-by-step guide.