Image creation on Google Cloud, part 1: Windows Setup

Google Cloud provides public images for a range of Windows Server versions, and using one of these images is typically the fastest way to deploy a Windows VM. There are situations however where it’s necessary to build your own image – for example, if you want to bring your own license.

I recently published an article Creating custom Windows BYOL images on the Google Cloud site that describes how you can use daisy to build BYOL-compatible images from scratch. In this two-part blog post, I am going to dive a little deeper into how the process works under the hood. And to do that, let’s start with a high-level review of how Windows Setup works.

Image-based installations

Since Windows Vista, the Windows Setup process has been image-based. That means that the installation media (DVD or ISO file, typically) contains an image and the primary purpose of Setup is to apply this image to the installation disk.

The image format that Windows Setup uses is the Windows Imaging Format (WIM). WIM images are file-based and therefore more akin to a Zip file than to a VHD or VMDK image. In the context of Windows Setup, there are three features that make WIM files interesting:

• You can mount a WIM file as a file system and modify its contents.
• You can configure the Windows boot loader to boot from a WIM file.
• A single WIM file can contain multiple images.

A typical Windows installation media or DVD contains not one, but two WIM files:

• Install.wim contains one or more Windows images (one per supported edition). One of these images is applied to the installation disk.
• Boot.wim contains a Windows Preinstallation Environment (WinPE) image.

In addition to these 2 WIM files, the media contains a number of (somewhat less interesting) ancillary files, including Setup.exe.

Windows Setup can be customized and run in many different ways, and it’s easy to get lost in the details. But at a high level, the process typically looks as follows:

1. Starting with an empty hard disk, the system boots from the DVD. The DVD is set up to boot from boot.wim, causing WinPE to load.
2. Once WinPE is loaded, it enters Windows Setup. Setup now collects some user input, including the disk to install Windows on and the edition of Windows to install. Then it extracts the install.wim image to the hard disk and configures the boot loader. Once completed, the installation disk is bootable, but still in a generalized state.
3. The system now boots from the hard disk for the first time. Because Windows is still in a generalized state, Setup kicks in again and enters the specialize configuration pass in which machine-specific configuration is applied.
4. Optionally, you could now boot into audit mode. During the auditSystem and auditUser configuration passes, you can manually apply additional customizations.
5. Setup now enters the oobeSystem configuration pass, collects preferences from the end user and applies them to the system.
6. Setup triggers a final reboot.
7. Setup performs final customization, then the system is ready for use.

After completing this process, Windows is in a specialized state and fully usable.

Automating the Setup process

To deploy Windows at scale, we typically need to customize and automate the process.

The primary mechanism to automate the Windows Setup is to use an unattend.xml file. As indicated by the diagram above, the unattend.xml file drives the specialization phase and can be used to tweak relevant Windows Settings.

A second, somewhat less common way to customize the Setup is to supply SetupComplete.cmd and/or ErrorHandler.cmd file – these files are run at the tail end of the Windows Setup and can be used to perform final customizations.

Customizing the image

While automating the Setup process by using unattend.xml file is useful, it’s often not sufficient: We might also need to install extra drivers or packages, and we might want to slipstream the latest Windows Updates.

There are two major ways to customize or update a Windows image. The first is that you deploy a Windows machine, customize it, and then put it back into a generalized state by running sysprep /generalize /oobe. Afterwards, you clone the disk and use it to deploy the remaining machines:

The second approach typically involves the use of the Microsoft Deployment Toolkit (MDT). With the MDT, you don’t clone disks, but you customize the installation media itself. And once again, there are two common ways to do this:

1. You can take the install.wim from the DVD or ISO and customize it, for example by adding additional drivers and slipstreaming updates. This process is called offline servicing.
2. You deploy a Windows machine, customize it, and then capture a new install.wim WIM file from the machine.

In both cases, you’d typically make the install.wim, along with boot.wim, and any other relevant drivers and packages available on a deployment share. You can then use that share to perform network-based installations.

Now that we’ve reviewed how Windows Setup works in general, let’s see how Windows Setup is used to build base images for Compute Engine.

• Share this article: