In “Creating Bootable VHDs with Disk2VHD” (InstantDoc ID 125422), I started covering the many steps involved in implementing the capability—new to Windows 7 and Windows Server 2008 R2—of “booting from VHD." In short, it's a new way to deploy Windows images by installing an OS image into a VHD-format file, copying that file to a target system, and telling the target system to (as you might guess) boot from that VHD.

To create that VHD-format image, you first have to build a prototype PC—a "reference computer"—that contains all your desired applications; configure those applications as you like them; use the Sysprep tool to make the system generic enough to be distributed to dozens, hundreds, or thousands of other computers; use the ImageX tool to create an image of that system; and finally copy that image to a VHD file (again by using ImageX).

If you’re reading this column, you probably know how to install an OS and applications and configure them the way you want, so let's skip that part and pick up the story with Sysprep. The notion behind Sysprep is that Windows systems (or, rather, Windows systems in the Windows NT family, such as Windows XP and later) are secure by nature, and so every Windows box needs some sort of unique identifier—its security ID (SID). Thus, if you were to build a reference computer, image it, and deploy that image to lots of other computers, you’d end up with a building full of computers all sharing the same "name," in effect.

What might go wrong in that situation? It's fair to ask, “Is the Sysprep process really necessary?” Common wisdom might suggest that the above administrator's network of clones would lead to “rivers and seas boiling, the dead rising from the grave, human sacrifice, dogs and cats living together, mass hysteria!”—to quote a famous team of apocalyptic theoreticians. But if you've ever tried networking a bunch of identical-SID systems, you know that nothing seems to go wrong. In fact, in his 2009 blog posting "The Machine SID Duplication Myth" (, Mark Russinovich points out that an all-identical-SID network of workstations will experience few, if any, negative side effects. (He cites Windows Server Update Services—WSUS—as an example.) So, you might choose to skip Sysprep.

But I'll assume that you want to play it safe—Microsoft-support-wise—and see how to use Sysprep. In Windows Vista and later, Microsoft provides Sysprep right in the box. You'll find sysprep.exe at \windows\system32\sysprep. Before you can use it, you'll need to open an elevated command prompt and type

cd \windows\system32\sysprep

to navigate to its folder. The simplest syntax you'll probably ever use for Sysprep looks like

sysprep /generalize /oobe /shutdown

By generalize, Microsoft means to clear out the SID, reset the plug-and-play stuff, and so on. (By contrast, specializing means configuring.) The /oobe switch is odd: You have to include it, or Sysprep won't work. It instructs the system, on next boot, to show the user the initial-use wizard— which Microsoft internally calls the out-of-box experience (OOBE—get it?) After Sysprep runs and shuts the system down, don't turn the computer back on! If you do, the computer will try to reconfigure itself, with the result that it's no longer in a state that can be cloned. (Instead, you'll boot it from an alternate OS, as you'll see next month.)

One caution about Sysprep and Windows 7 or Vista: You can't use Sysprep more than three times on a computer without a bit of registry fiddling. In other words, if you use Sysprep three times to image a computer, turn it back on, and let it reconfigure itself with the OOBE wizard, and then try to use Sysprep one more time, you'll get a cryptic and scary Fatal Error. This new and annoying Sysprep feature first appeared in Vista and has something to do with product activation.

The problem stems not from Sysprep itself but from a Sysprep side effect called an activation re-arm. You can avoid this side effect by navigating to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform subkey and setting the SkipRearm entry (of REG_DWORD type) to 1. You can do that with one command (which you must run from an elevated command prompt):

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform" /v SkipRearm /d 1 /t REG_DWORD /f

I've shown you the Reg tool before, but if you've forgotten its syntax, the first value is the registry key that contains the entry to modify, /v specifies the entry's name, /d offers the data to insert in that key, /t specifies the type of data proffered, and /f instructs the system to overwrite the current value if necessary.

With a properly Sysprep-prepared system, you're ready to create an image of the reference system. We'll do that next month!