In "ImageX Provides Disk Imaging on a Budget" (InstantDoc ID 125743), I introduced ImageX, a Microsoft tool that—similarly to Symantec's Ghost—lets you easily clone an entire drive from one system and distribute it to as many other PCs as you like. I explained where to find ImageX and how to use it to capture the C drive of a working Windows box (which you've already prepared with the Sysprep utility), by using the command
imagex /capture C: G:\baseimage.wim "Base Win 7 image for our organization"
In that example, I've captured the entirety of the computer's C drive onto a file on G (which might be a network share or an external hard drive) named baseimage.wim. Now that you have this image file, what can you do with it?
Clearly, your first use of baseimage.wim would be to deploy it to a PC. That process involves four steps: Boot the target PC with Windows Preinstallation Environment (WinPE), wipe any existing partitions, create and format a new partition, and use ImageX to apply baseimage.wim to the new partition. (Note that I'm assuming the system you created was formatted as one large partition—something I'll cover in greater detail in the near future.) I discussed WinPE in the previous article, and in the past year I've covered Diskpart—a command that lets you create, destroy, and format partitions—but in case you've forgotten, the following commands will get you ready to deploy on most systems:
diskpart
select disk 0
clean
create partition primary
format fs=ntfs quick
assign letter=C
exit
Now, your target system's hard drive is formatted as one large drive named C. (Any drive letter will do, because you're merely in WinPE, and once you've deployed the image and reboot, Windows will automatically re-letter the drive to C.) Next, you'll need to get connected to whatever storage contains baseimage.wim—whether it's on a USB stick, an external drive, or a network share. Let's assume that you've mapped the storage as drive P. To apply baseimage.wim to the new C drive, type
imagex /apply P:\baseimage.wim 1 C:
(The 1 indicates that you want to use the first image in the baseimage.wim file, and I'll cover that in more detail next month.) After ImageX does its work, just reboot the newly imaged system. Depending on how you prepared your prototype system with Sysprep, either you'll have to respond to the usual Name the computer, Create a user, and Set Windows Update settings prompts or—if you created an automated setup script for Sysprep—you'll see the system start up, ready for you to log on and get to work.
Now that you've met Imagex /capture and Imagex /apply, you can start creating and working with WIM files. But ImageX is capable of much more, so let's meet the /verify and /check options.
The /verify option works as you might imagine: It double-checks that either a capture or apply operation didn't accidentally drop any bits along the way. WIM files are pretty large, and although network and disk read/write operations already contain built-in checks, just one misplaced byte can render the image or system useless. The /verify option helps prevent that from happening. After either applying or capturing a windows image, ImageX compares the source data and its copy, searching for (and correcting) differences. ImageX enables the /verify option by default whenever applying or capturing over a network connection, but it doesn't do that when working with local external storage, so it's never a bad idea to add the /verify option. (It will, of course, slow things down a bit.)
The /check option has a similar purpose but a slightly different and perhaps more efficient approach. If you include /check when capturing an image, ImageX creates a hash of every 10MB chunk of ImageX data, then embeds those hashes in the resulting WIM. Including /check on an apply operation causes ImageX to check the applied image by re-computing hashes on that image, then comparing those computed hashes with the embedded ones. Thus, /check certifies not only that a WIM wasn't mis-copied during the apply operation but also that a WIM hasn't become corrupted while stored. Why use /verify, then? Why not just always use /check? The answer is that /check can't do its job on an apply operation if no one specified /check on the capture. If the WIM lacks embedded hashes, /check can't check the hashes. The /verify option, in contrast, doesn't need hashes, so it can always help.
In any case, Microsoft recommends using both options, so if you've got the time, don't hesitate to verify and check. Next month, I'll dig into more ImageX capabilities!
