You can cheat a bit by updating WIMs offline with Windows Updates. Here’s how.
You know I’m completely enamored of Windows Deployment Services (WDS). Right out of the box, this free tool delivers ridiculously powerful automation in deploying Windows OSes. Yet right out of the box is just the beginning.
Pair the deployment prowess of WDS with the automations found in the Windows System Image Manager (WSIM), and you’ll be amazed at how quickly you can deploy a fully configured Windows 7 OS. In this case, fully configured means a machine already on the domain, stocked with custom configurations, networked and ready for use. Click. Go.
For all its abilities in automating configurations during an OS build, there has always been one step I could never automate—until now. And that time-consuming but important step is installing Windows patches.
I’m not a very patient guy. The extra five or 10 minutes I’m forced to watch Windows download and apply patches has long been a source of irritation. I start with a perfectly good Windows Imaging Format (WIM) image right off the Windows 7 DVD media, and it’s already asking for its patches. Applying them manually seems ridiculous, as does the three-part process of building an image, patching it and capturing a replacement WIM into my WDS library.
I wanted something fully automated—something I could repeat with a simple command. With a little effort, the help of a Windows Server Update Services (WSUS) server, the Deployment Image Servicing and Management (DISM) and WDSUTIL commands, and a batch file, I discovered how to cheat with offline WIM updating with Windows patches. Turns out cheaters really can prosper.
I needed a way to automate the process of injecting Windows patches directly into my WIM images. What better place to start than with WSUS?
It’s easiest to start with a brand-new instance of WSUS, one that’s not yet crowded with a lifetime’s worth of ancient patches. Configure that server to download content locally. Make sure you’re only downloading the Windows updates you really need.
I wanted to automate only the updates a new OS requests immediately after install. So my automation grabs only Windows 7 and Windows Server 2008 R2 products for the four most-important classifications: Critical Updates, Definition Updates, Important Updates and Security Updates.
After a quick sync, my server found nearly 700 updates (see Figure 1) associated with the two products and four classifications. That’s still too many. I needed to trim that list down to just the ones Windows demands immediately after install. So, I cheated again.
Figure 1 The Windows Server Update Services quick sync found nearly 700 updates.
Use WDS to build yourself a Windows 7 machine. Then configure the two Local Group Policy settings connecting the machine to your single-purpose instance of WSUS. You can find these in Computer Configuration | Administrative Templates | Windows Components | Windows Update. Look for Configure Automatic Updates and Specify intranet Microsoft update service location.
Set the first to Notify for download and notify for install. Then point the second toward your instance of WSUS. Run the commands gpupdate /force and wuauclt /resetauthorization /detectnow to speed up the Windows Update scanning and reporting steps.
My out-of-the-box machine with Windows 7 SP1 found about 70 more updates than it actually needed. Your situation should be similar. Approve them all for install.
Here’s where the cheating gets thick. When you approve an update for install, WSUS sees this as its signal to download the update installation files. By default, it downloads those files into subfolders of the C:\WSUS\WsusContent folder (see Figure 2). Take a look through yours and you’ll find those 70-plus updates in a nearly equal number of subfolders.
Figure 2 The contents of C:\WSUS\WsusContent.
You can’t download the WSUS updates like traditional installation files, which can be a problem. They’re almost always downloaded as CAB files. That’s no good, because you can’t just double-click to install a CAB file.
However, they’re perfect for a command-line tool such as DISM, which is the tool you use for getting “scripty” with WDS and your WIM images.
In fact, using the command-line WDSUTIL tool for DISM and WDS, you can export and mount a bare-bones WIM image out of WDS. Once that’s mounted and you add a for loop, DISM will cycle through and install every update you just magically downloaded to C:\WSUS\WsusContent. Once that’s done, these two commands commit the changes, close the WIM, and import the file right back into your WDS infrastructure. Now that’s patching automation.
I put together a script to accomplish just that. It assumes your image is named W7SP1, that it’s in an image group of the same name and has an index number of 1. It needs two folders: an export folder called C:\DISM and a mount folder called C:\DISM\mount. Create these folders before running the script, which looks like this:
start /w wdsutil –Export-Image /image:W7SP1 /imageType:Install /imageGroup:W7SP1 /destinationImage /filePath:c:\dism\patchMe.wim /overwrite:yes start /w dism /mount-wim /wimfile:c:\dism\patchMe.wim /mountdir:c:\dism\mount /index:1 start /w for /R C:\WSUS\WsusContent %f in (*.cab) do dism /image:c:\dism\mount /add-package /packagepath:"%f" start /w dism /unmount-wim /mountdir:c:\dism\mount /commit start /w wdsutil –Replace-Image /image:W7SP1 /imageType:Install /imageGroup:W7SP1 /replacementImage /imageFile:c:\dism\patchMe.wim
Make the necessary changes and add these lines to a batch file. You’ll also note how each line starts with the “start /w” command. Each of these five commands takes time to run. By starting off each with “start /w,” you’ll ensure that each command is completed before invoking the next.
Even years into the lengthy lifespan of WSUS, this Microsoft tool still seems a little rough around the edges—if you’re using it “the right way.” Thankfully, WSUS was designed with the kind of surprisingly open architecture that makes it easy to hack and easy to cheat your way to offline WIM updating success.