The Desktop FilesThe Power User's Guide to WIM and ImageX

Wes Miller

This column is based on a prerelease version of the Windows Automated Installation Kit (WAIK) and Windows Server 2008. All information herein is subject to change.

In several of my previous columns I've discussed ImageX and the Windows Imaging (WIM) format. At Tech•Ed a few months ago, I heard some of the comments and questions from IT pros beginning to use Windows Deployment Services (WDS), ImageX, and the Windows Automated Installation Kit (WAIK) and realized there

was need for more user guidance. So in this month's column I'd like to focus on ImageX and the WIM format, and how you can get the most out of them. Together, ImageX and WIM allow you to easily deploy not only Windows Vista® and Windows Server® 2008, but also Windows® XP, Windows Server 2003, and Windows 2000 as well.

Changes to WAIK

The upcoming release of Windows Server 2008 may have you wondering what this means for the WAIK. Microsoft plans to release an updated version of the WAIK in the timeframe of the Windows Server 2008 release. There are no significant changes to the WIM format (the ImageX tool and the format are unchanged); WDS for Windows Server 2003 does not change either. Contrary to rumor, multicast will not be available for Windows Server 2003 WDS—only WDS servers running Windows Server 2008 will feature the new multicast deployment capability for WDS.

Windows PE 2.0 and Windows Setup will be revised in order to support the following:

• Deployment of Windows Server 2008 and Windows Vista.
• Multicast deployment via WDS from a Windows Server 2008 WDS server.
• Deployment of x64 versions as well as x86 versions of Windows Vista and Windows Server 2008 from x86 Windows PE.

First, this means that Windows PE 2.0 will be able to deploy Windows Server 2008 just as readily as it can Windows Vista—the same tools and processes work as well for one as they do for the other. Second, you will be able to utilize multicast deployment via WDS once your WDS servers are running on Windows Server 2008. Finally, this means that you will have the ability to use an x86 Windows PE 2.0 disk and deploy either an x86 or x64 image of Windows from it.

I mentioned this latter point at Tech•Ed in my session on x64 Windows. Unfortunately, there has been some confusion around this in blogs and in the Windows technical community. This does not mean that Microsoft will be distributing x64 Windows and x86 Windows on every Windows Vista or Windows Server 2008 DVD. It also doesn't mean that you should combine Windows x64 and Windows x86 images into a single WIM file (although you can). Doing so causes no single-instance storage savings, though it does allow the WIM to travel as one file.

What this does mean is that enterprise customers and OEMs who have spent years developing x86-based deployment processes (and custom scripts and tools) will now be able to deploy either x86 or x64 Windows from within WIM using 32-bit setup—something that enterprise customers have been requesting since x64 Windows first arrived in 2005.

ImageX Day to Day

Using /mount, /mountrw, and /delete

Here are some important tips for using the /mount, /mountrw, and /delete switches with ImageX:

• Mount a volume with /mountrw if you intend to edit it.
• You should mount a WIM to an empty directory—just to eliminate confusion from any files you have stored there and to prevent ImageX from throwing an unneeded warning message.
• Don't forget to /unmount /commit your read/write image if you want to save the changes you've made. All too often I've made changes, only to forget to commit them (and thus losing them).
• Deleting files via /mountrw and deleting Volume Images via /delete doesn't recover any space—in fact it can actually use more space. See the section in this column on /export for more details.
• You can only mount a single WIM file once for read/write access. Two users can't edit the same WIM at once, and you can't edit two Volume Images at once.
• Even in read-only mode (/mount), you should limit the number of Volume Images you mount simultaneously, as the driver has a dependency on the amount of Windows non-paged pool memory available on your system for each image mounted. This results in a limit that may vary per-system (or per system architecture). I recommend not trying more than five images simultaneously.
• Making significant edits via /mountrw will take almost no time when you make the changes, but may cause /commit to take a considerable amount of time, since it needs to compress and store all of the new file data.
• Use /delete and /mountrw carefully—once the changes are committed, they cannot be undone.
• You cannot run /delete if there is only one Volume Image in a WIM file (delete the entire WIM file or append another Volume Image instead).
• To quickly get a directory tree of the contents of a Volume Image, use this command instead of /mount:

ImageX /dir <path_to_wim_file> <image index>

• If you are editing two WIM files at the same time, try not to /unmount them at the same time; sequence your mount/unmount events so one won't block the other.

ImageX was specifically designed to mirror the way OEM and enterprise customers say they use the tools. Figure 1 shows the process.

Figure 1** Using ImageX **

It's worth emphasizing that Step 5 is critical—the reality is that an image is constantly changing. Thus, capturing and modifying the image needed to be as fast and easy as possible.

To that end, you can append an additional image (using the /append switch) to one you already created. Initially the development team thought you'd want to add in an additional SKU (version of Windows) to your earlier image, but the more I worked with enterprise customers early in Windows Vista development, the more I heard it being used to quickly deploy X, then recapture X1 where you had made one of the modifications in step 2. Doing so allowed you to quickly recapture the image since you had only modified a constrained number of files.

When the team understood this, they realized that it might not make sense in all situations to keep the original image. Later in the column I'll discuss the /export switch that was added specifically due to this scenario and the one that follows next.

Change Is Constant

Early on, the development team decided that WIM files should be editable. Since they had already decided that a sector-based imaging format would not work (see the December 2006 column at technetmagazine.com/issues/2006/12/DesktopFiles for an explanation), they had to deliver a solution that would easily mount the files natively as a part of the Windows file system and make changes to the mounted Volume Images in the WIM file. This meant a few more "moving parts," as I like to refer to them. Mounting a sector-based image is relatively easy, but mounting a proprietary archival format such as WIM required some very specific tooling.

The format needed to have access from the command prompt—ruling out the commonly used Windows Shell Extensions used to handle ZIP and CAB files natively. Unfortunately, these handlers only allow Windows Explorer abstract access to an object.

As a result, the WIM solution involves a driver (wimfltr.sys) and ImageX, which serves as the method to actually load the driver and handles the interface for mounting the WIM. The driver serves to add an abstraction to the Windows file system, as shown in Figure 2. When you run a command like one of these, you are telling ImageX to load the wimfltr.sys driver and to have the driver overlay the first Volume Image (the 1 in the commands used here) on the empty directory mount, as you can see here:

Figure 2** Mounting a WIM Volume Image **(Click the image for a larger view)

ImageX /mount iso\sources\boot.wim 1 mount 
ImageX /mountrw iso\sources\boot.wim 1 mount 

This is the default behavior in the WAIK. Thus, when you explore or generate a directory listing on the mount directory, you see the root of Volume Image 1 in boot.wim. Of course, whether you use /mountrw or /mount will determine whether this directory is read-only or read/write (see the sidebar "Using /mount, /mountrw, and /delete" for details).

The /mountrw capability was originally designed to easily add in drivers or other xcopy-able files or content, set up answer files, or to modify the offline registry of a mounted WIM file to change it as needed (see Figure 3). It was not designed to have entire applications added or removed (since MSI-installed applications cannot be installed offline).

Figure 3** Modifying a mounted WIM file **(Click the image for a larger view)

It's critical to understand that while you're making changes to the WIM file when it is mounted, you are not changing the actual WIM file directly (at least not immediately); rather, you are changing a cache of the WIM file that is effectively a merging of the overlay and the changes you've made. As I note in the sidebar, I've been bitten by this before. Make sure that when you are finished you use the /unmount and /commit switches as only then will your changes be committed to the WIM file. Otherwise, they are completely lost.

When you save your changes by committing them, you are telling the driver to make the changes in the WIM file itself. The driver adds in the additional file data. (Note that if you've made a lot of changes, this means /commit can take a considerable amount of time, since you are only then adding the file data to the WIM.)

Also, unlike a sector-based imaging format, you may have changed one or more files in the Volume Image. As a result, they are no longer single-instanced (unless this same file has already been stored once) and will result in the original file data becoming lost. WIM, unlike an NTFS or FAT volume, doesn't mark a file as deleted—it no longer references it, but doesn't clean up. As a result, if you make frequent edits via /mountrw or you /append numerous images or use /delete to delete a Volume Image, it only makes the WIM file forget about the references to the file data—it does not drop the related file data altogether.

Thus the dev team created the /export switch, also known in a way as the "WIM defragmenter."

Exportation

Important Notes for /export

When /export is being used to create a new WIM file, you can specify what type of compression is used rather than accepting the default compression type currently used. If you are changing from the current type of compression, exporting may take considerable time.

When used effectively as /append (by adding a Volume Image to an existing WIM file), /export does not allow you to modify the /compression attribute of the WIM file.

You can specify the /boot switch if you are exporting an entirely new Windows PE 2.0 Volume Image.

The /export switch was created in response to both of the previously mentioned scenarios and a couple of other more esoteric scenarios the team discovered. In a nutshell, /export allows you to take an existing Volume Image (or two, or three) and export them. This means rapidly taking the X and X1 WIM file above and either creating a new WIM just with X, just with X1, or with X1 and Y1, by exporting from yet another WIM file.

Imagine the scenario where you make modifications to X and /append the changes as X1. You decide that you want to delete X since you have replaced it as your new image for this quarter. You can use the /delete switch and ImageX will forget about the X image. However, to save space by eliminating all information related to X, you would run this command:

ImageX /export source.wim 2 destination.wim "New image for Q4CY07"

This will export the second Volume Image to a new WIM file with the new name, completely eliminating the earlier information from Volume Image 1. You can also export from spanned WIM images if you want to reassemble them into one WIM file (as I'll discuss later in this column). Spanned images can't be edited via /mountrw—one reason why you would want to reassemble them. It's important to note that there is no /import command for ImageX since /export can either create new WIM files or append to existing ones. See the sidebar "Important Notes for /export" for additional information on this topic.

This is also critical if you run peimg /prep: though this command prepares your Windows PE image to be used, it does not clean up anything in the WIM. Ideally, as a part of your Windows PE release process, you should prepare the image and then export it to a new boot.wim file. Note that the boot process only knows to look in \sources\boot.wim for the WIM file, so make sure it is named correctly and marked as a boot Volume Image.

I've mentioned that you will probably want to optimize your images by running /export against them when you're ready to decommission old Volume Images or combine multiples together. You also will want to do this if you have made numerous edits via /mountrw or /delete. Otherwise, your WIM file will continue to grow over time (in mysterious ways that you can't diagnose). If you are using /mountrw or /delete on a regular basis, consider adding /export into your workflow to ensure your images are fully optimized.

Spanning

Early on, another problem that cropped up was the probable need for WIM files to fit across multiple pieces of shiny media. We anticipated that Windows would ship on more than one CD (and potentially on DVD, as it did), and as a result built spanning support into WIM and ImageX.

As I mentioned, a spanned image created via /split is basically read-only—you can't /capture directly to a new spanned image, it can't be mounted via ImageX, and it can't be appended to via /append. As a result, I would recommend splitting your WIM file only after you are finished with your standard workflow and ready to release. That is, make all of your edits on the normal WIM file and consider splitting as part of the release process for your deployment scenario.

When it comes to applying the image, spanned images can be challenging. I would recommend using ImageX rather than setup when using spanned images. I would also recommend either applying the images over the network (for optimal performance without imaging the disk you are applying from), or copying them directly to the drive and then applying (noting that you will be disk-bound, since the disk is reading and writing to itself at apply time).

Looking for Validation

When you're using ImageX, you're moving lots of data—lots of very important data. A frequent question I heard at Tech•Ed this year was, "How can I ensure my images are valid?" Well, it's not terribly easy, but it really isn't that hard, either.

The main thing you have to understand about WIM is that, like most archival formats, it is susceptible to corruption. Most often this corruption occurs when a WIM file is transmitted over the network. Early on in Windows Vista, we saw specific problems with specific network cards—if they dropped packets, the WIM file was corrupted, and not always in ways that were easy to diagnose. This situation was one that actually mirrored what had happened years before when the driver.cab file grew in size—similar random corruption had occurred. Generally, if you get reports of bad images or of setup failing, you want to check what type of NICs are in use on the systems generating the reports. This is the case whether you are using ImageX by itself or running WDS.

So how can you see if an image is good or not? First, you can use the /check switch. This saves additional integrity checks in the WIM file and will verify, before application, that the WIM has not been corrupted. Be sure to run /check at apply time as well, which will validate the image (though it takes more time).

In addition, if you are having problems—or just want to be meticulous—you can run a hashing utility against the files before capturing and after application. You can verify after capturing as well by mounting the image and rehashing—not a bad way to ensure an image has captured correctly.

You'll want to make sure that your images are being captured correctly from the beginning. The /check switch and the format itself are designed as checkpoints, not as recovery tools to repair an incorrectly captured image.

Booting and Flags

I've mentioned before that you can use /boot to capture a WIM Volume Image of Windows PE and boot it. You should think of this as just a boot sector on a particular Volume Image. It can only exist on one Volume Image per WIM, and is only valid for Windows PE 2.0. Note that you cannot WIM boot Windows PE 1.x—it is simply not possible.

You may see references to flags in Windows Volume Images. Flags are used only by Windows Setup. A flag on a Volume Image of 2 means a Volume Image contains Windows PE and setup. A flag of 9 means it contains just Windows PE. Any other flag or the lack of a flag means that the image will not and cannot be used by setup. You should note that you can set flags on an image after it has been captured by using ImageX to modify them. I recommend using the WAIK (and optionally the Business Desktop Deployment Solution Accelerator) to create your Windows PE WIM boot image, as the flags will be properly set to begin with.

A Note to HTA Users

Recently I've heard several reports of issues with running HTA files on Windows PE 2.0. Unfortunately, there appears to be an issue with HTA files that contain any significant scripting. In Figure 4, take a look at the screenshot of the sample file I created, and note the scripting error (with no information) returned. This problem was reported by several customers, and I experienced it myself.

Figure 4** HTA scripting error **(Click the image for a larger view)

Thankfully, though, the fix is relatively easy. When preparing your image, add XML support as well as HTA support. The missing dependency in the HTA component appears to be included in the XML add-in module, thereby solving this problem.

I would like to thank Bruce Green, ImageX Developer, and Minxiao Zhou and Raja Ganjikunta on the Windows Deployment Test team for their assistance with this column.

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, Texas. Previously, he worked at Winternals Software in Austin and at Microsoft as a Program Manager and Product Manager for Windows. Wes can be reached at technet@getwired.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.