Jeremy Chapman who has contributed many pieces to this blog starts a multipart series on the benefits of using package based imaging tools.

Welcome to blog number one in the series of imaging and image composition. Last week, Stephen kicked off the series in the Springboard Series Insider Newsletter and I’ll try to get through this in three or four blog posts, but the nature of this discussion can almost be constituted as a religion. In that sense, there is never a perfectly correct answer. Like any good IT pro, when someone asks a question like what is the best way to do imaging, manage drivers, etc. – you’ll typically want to respond with “it depends.”

Before we get started, we need to define a few terms again around imaging before we go too far:

• Core image – This is the core of what you are building, sysprepping and capturing to clone onto other computers. In Windows and ImageX terms, this is only the WIM file and doesn’t include the unattend file or related commands, scripted installs outside of the WIM, etc.
• Build – This is a somewhat new idea and it consumes the core image. A build includes all automation before, during and after image creation or image application. The build includes components external to the WIM file (drivers, applications, and packages), scripts, task sequence logic and anything else it takes to automate an end-to-end scenario. 

• Thick Image – a core image capture of a fully-configured reference computer with lots of applications, packages, updates and other customizations
• Thin Image – a core image with very few customizations and additional applications. Sometimes this is exactly the image file as Microsoft ships it in-box or the image with only approved Windows updates applied. Customizations will be layered on at install-time for applications, packages and drivers.
• Hybrid Image – a core image with a balance of core applications (typically things needed by 80% or more users) + updates and small size. Many custom configurations are still layered on at install time.
• Hardware Abstraction Layer (HAL) – these are the files in between the hardware and Windows kernel that determine how Windows interacts with the hardware. This is important because Windows XP and earlier operating system images were HAL-dependent and HALs could not be switched in a supported way.
• File-based Image – this image type copies the reference computer’s file system at the file-level and is therefore non-destructive when applying to image to a volume with files present. That means, you can apply a file-based image to a volume that has files on it and expect those files to still be there after the image is applied.
• Sector-based Image – this image type copies the reference computer’s file system at the disk sector level and is destructive to existing files on the volume it is applied to. In this case, once you begin to apply the image to a volume with files, those pre-existing files will be lost.
• Windows Image Format (WIM) file – this is the file-based image format from Microsoft, which incorporates compression, appending of multiple images to a single WIM file, and single-instancing of files when multiple WIM files are appended.
• System Preparation Tool (Sysprep) – this tool is used in imaging to generalize an installed computer and prepare the volume for cloning. This tool is run from a non-domain joined PC and deletes user profiles, resets the activation state and the hardware profile for reinstallation on other systems.

If you’ve been using sector-based images for a while, the first and sometimes most difficult concept to get used to is that you can apply an image to a volume with files already present without harming or deleting those files. This really comes into play when you want to migrate user files from an old operating system version or corrupted copy of Windows to the new image. We can leave the files in place on the volume and apply the operating system image around them. For a computer refresh (where we rebuild a machine and keep user data local on the drive), we can save a ton of time by not having to transfer user data off the machine or volume before the image application and avoid spending even more time bringing user data back afterwards.

The other thing to get used to is that the WIM file is basically a compressed file container. Imagex is a free utility included in the Windows Automated Installation Kit and allows you to create, append, mount and unmount WIM files. When Imagex is used to capture an image, think of it being similar to using Robocopy to copy files from the drive you are capturing into a container – like a cabinet (CAB), VHD or ZIP file. WIM then goes further by letting you merge multiple containers into one and a database then maps the files across multiple merged containers to ensure that each file within is single-instanced whenever possible. If you ever wondered why a Windows Server 2008 R2 DVD can install up to eight different operating system types, it is because seven of them have been appended to the original image capture and because the files within are so similar and each is single-instanced whenever possible, that image can stay around 3GB – even though it represents eight unique operating system images appended into one WIM file.

Sysprep is the last tool I’ll cover in this initial post. Sysprep in Windows XP and earlier was delivered as an INF file and in Windows Vista and newer (including Windows Server) as an in-box executable file. In both cases Sysprep can generalize the image and prepare the system for cloning. It can also prepare a system for Out-of-Box Experience (OOBE), which essentially resets Windows to the state it would be when purchasing a Windows PC from a retailer – all necessary drivers are still in-place and the user is prompted to input account, locale, time zone and related information. When using Sysprep, you should not join the machine to a domain and rather opt for a Workgroup.

Sysprep is now located in the %windir%\system32\sysprep folder. There you will find a couple of things, the language folder – which determines the UI language for Sysprep – and the “Panther” folder – which includes the logs from the Windows Setup engine.

You would typically run Sysprep in the command line and use either the /generalize or the /oobe switch, depending on what you are doing. For imaging, this is most likely be the /generalize switch with the /shutdown switch and possibly point to an unattend file via /unattend:unattendpath. The User Interface for Sysprep lets you run the general commands (except for the /unattend and /quiet switches). 

Of note here as well is the /audit switch – accessed also from the upper drop-down menu in the UI above. With Audit Mode, you can Sysprep the Windows installation and then re-enter the machine in a “Sysprepped” state and configure the system further prior to capturing the system image for cloning.

Now we’ve covered the main terms and the Windows utilities. I wanted to highlight a couple of related videos we’ve created on TechNet.

• Preparing an Image using Sysprep and ImageX
• Capture the Customized Windows Installation
• Deployment Image and Servicing Management

In the next blog, I’ll go into the pros and cons of different image and build types. Stay tuned and thanks for reading,

Jeremy Chapman
Windows Deployment