Understanding image life-cycle management
The goal of image life-cycle management is to facilitate the process of building and maintaining reference images of Windows operating systems that can be used for deploying Windows to target systems. Depending on the version of Windows being deployed and the needs of your organization, such target systems might be
- Client PCs or tablet devices
- Physical server systems
- Virtual machines on Hyper-V hosts in the data center
- Virtual machines running in an Infrastructure as a Service (IaaS) private cloud
A reference image is a standardized Windows operating system image (.wim file) that might include some or all of the following:
- Device drivers
- Software updates or hotfixes
- Per-user customizations
- Per-machine customizations
Per-user vs. per-machine customizations
Per-user customizations of reference images generally involve making changes to the default user profile. These changes will then be applied to each new user who logs on to the system. Per-machine customizations involve modifications that apply to all users who log on to the system. An example of a per-machine customization is configuring the image so that Remote Desktop will be enabled on systems on which the image is deployed.
Per-user customizations are commonly implemented when engineering reference images of Windows client operating systems such as Windows 8. Per-user customizations are not commonly implemented when engineering reference images of server versions of Windows.
Build vs. production environment
The process and tools used for building reference images should be kept separate and isolated from the process and tools used for deploying images, as illustrated in Figure 1. The build lab should contain only systems, tools, and other software needed to create and test reference images you will be deploying in your production environment.
Setting up your build lab
The build lab is used for building and testing reference images that will later be deployed in your production environment. The components of a build lab can vary, but they should generally include the following:
- Hyper-V host Most of the image engineering process can be performed within a virtual environment. For building reference images of Windows Server 2012, you need a physical host system that supports hardware virtualization and is running Windows Server 2008 R2 or later with the Hyper-V role installed.
- Technical computer The technician computer has the necessary tools installed for building reference images of Windows Server 2012. In the example of a build lab shown in Figure 2, the technician computer is a virtual machine running on your Hyper-V host, but it could also be a physical system if Hyper-V is not being used in the build lab.
- Reference computer The reference computer is the system from which the reference image is created by sysprepping and capturing the installation of Windows on the computer. This reference computer must be a bare-metal system—that is, it should have no operating system installed on it. In the build lab shown in the figure, the reference computer is another virtual machine running on your Hyper-V host, but it could also be a physical system if Hyper-V is not being used in the build lab.
- Physical systems These are samples of the different types of system hardware used in your production environment and on which you will later be deploying your reference image. After you build your reference image, you should test it by deploying it to these sample physical systems to make sure no issues will arise when you deploy the image in your production environment. These sample systems can be virtual machines in your build lab if you will be deploying your reference image only onto virtual machines in your production environment—for example, when deploying some type of private-cloud solution.
- DHCP server Network connectivity must be established between the technician and reference computers before the technician computer can be used to deploy Windows onto the reference computer, so a DHCP server can be used to dynamically assign an IP address to the reference computer. However, a static IP address can also be manually assigned to the reference computer at the start of the deployment process. The DHCP server is therefore optional, but it is recommended to simplify the automation of the reference-image build process.
- Windows Deployment Services This is a server running Windows Server 2008 R2 or later that has the Windows Deployment Services role installed. This server can be either physical, as shown in the figure, or virtual (running as a virtual machine on the Hyper-V host). The Windows Deployment Services server simplifies the task of deploying the reference image onto the sample physical systems by eliminating the need to burn your boot images onto DVD media to kick-start the reference-image testing process. This server is optional if you will be deploying your reference image only onto virtual machines, because you can easily manually mount your boot images in Hyper-V for deploying your reference image to virtual machines in your build environment.
Understanding the reference-image build process
After you set up your build lab, you can begin building and testing the reference images you will be deploying on systems in your production environment. As Figure 3 shows, the general steps in the process of building a reference image are as follows:
- Customize the deployment process The technician computer is used to customize the process of deploying Windows by choosing whether to include applications, software updates, hotfixes, language packs, out-of-box device drivers, and various per-user or per-machine customizations when the operating system is deployed.
- Deploy the image to a reference computer Windows is then deployed onto your reference computer along with any additional software or customizations you configured.
- Sysprep the deployed image The System Preparation Tool (Sysprep) then executes on your reference computer to prepare the installation for cloning by removing machine-specific information, such as the computer’s security identifier (SID).
- Capture the deployed image The sysprepped installation is then captured in the form of a Windows Image (.wim) file and copied to the technician computer. The captured and sysprepped image is now referred to as the reference image.
- Deploy the reference image to the test systems The technician computer is then used to deploy the reference to sample systems in your build lab. These sample systems can be either samples of physical systems taken from your production environment or virtual machines running on the Hyper-V host in your build lab.
- Verify the result You now log on to the sample systems on which you deployed your reference image. Perform any tests needed to ensure that the deployed image works properly and has all the software and customizations required by your production environment.
REAL WORLD Maintaining reference images
Reference images might need to be updated as time progresses. For example, you might decide you need to add additional software to your image or make some other customizations because of changing business requirements. The best way of maintaining your reference images is to periodically rebuild them when needed. But rebuilding an image does not mean taking your existing captured and sysprepped reference image, deploying it to your reference computer again, adding new applications or other software to it and making any other customizations needed, and then sysprepping and capturing your image again. Running sysprep multiple times like this on a Windows installation is unsupported and can cause unpredictable results when you deploy your image into your production environment.
Instead, when you decide you need to update your reference image in some way, you should go back to the beginning and customize the process used to build your reference image and then run this process again to create your updated reference image.
Setting up the technician computer
To set up a technician computer for building reference images to deploy Windows Server 2012, the following tools are needed:
- Microsoft Deployment Toolkit (MDT) 2012 Update 1 MDT is a free Solution Accelerator from Microsoft that includes comprehensive tools and guidance for automating and customizing operating-system and application deployment. MDT is available in both x64 and x86 versions, and it can be used to deploy Windows 8, Windows Server 2012, Windows 7, Windows Server 2008 R2, and Office 2010.
- Windows Assessment and Deployment Kit (ADK) for Windows 8 The ADK is a collection of tools you can use to customize, assess, and deploy Windows operating systems to new computers. The ADK supersedes the Windows Automated Installation Kit (Windows AIK) used by earlier versions of MDT, and it includes additional tools that previously had to be downloaded separately.
In addition to the preceding tools, you also need the following:
- Windows Server 2012 installation media (.iso file or DVD)
- Any applications, language packs, software updates, hotfixes, or out-of-box device drivers that you want to include in your reference image