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:
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.
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