Best Practices for Image Deployment
Published: October 22, 2009
Updated: July 8, 2010
Applies To: Windows 7, Windows Server 2008 R2
|This content applies to Windows 7. For Windows 8 content, see Windows Deployment with the Windows ADK.|
The following sections describe best practices for deploying Windows® images.
|If you intend to transfer a Windows image to a different computer, you must run the sysprep /generalize command, even if the computer has the same hardware configuration. The sysprep/generalize command removes unique information from your Windows installation, which enables you to reuse that image on different computers. The next time you boot the Windows image, the specialize configuration pass runs. During this configuration pass, many components have actions that must be processed when you boot a Windows image on a new computer. Any method of moving a Windows image to a new computer, either through imaging, hard disk duplication, or other method, must be prepared with the sysprep /generalize command. Moving or copying a Windows image to a different computer without running the sysprep /generalize command is not supported.|
The walkthrough section provides specific instructions for each method listed. For more information about the different deployment methods, see Preinstallation Methods.
Deploying Windows Using Windows Setup
You can deploy your custom image by using Windows Setup. This method provides more flexibility and other benefits over using ImageX to deploy Windows. Using Windows Setup during deployment, you can apply a second customized answer file (Unattend.xml) to your custom image. For example, you can apply different disk configurations or add additional drivers and applications. This method is similar to build-to-order (BTO) methods.
|You can use the default image file (Install.wim) included with the Windows product DVD only with Windows Setup (Setup.exe). Do not deploy this default image directly using ImageX.|
For more information about using Windows Setup, see Deploy Windows by Using Windows Setup.
Deploying Windows Using ImageX
You can deploy your custom image by using ImageX. Using this method, you start by creating a reference computer. You can then make customizations to this reference computer. When you are satisfied with your image, you can capture it, and then deploy identical copies of it your destination computers.
This basic process is sometimes called build-to-plan (BTP). You can modify this process to automate various steps. For example, you can write a script that instructs the Windows Preinstallation Environment (Windows PE) to automatically connect to a network and copy an image to the destination computer.
For more information about using ImageX, see Capture and Apply Windows Images.
Deploying Windows Using Windows Deployment Services
Windows Deployment Services (WDS) provides a complete server-based deployment solution. To make production more efficient, OEMs and corporations can start destination computers remotely with Windows PE by using WDS. WDS is a server component in Windows Server® operating systems that replaces Remote Installation Services (RIS). By starting Windows PE remotely, you do not have to start the destination computers manually.
Using WDS, you start by creating a reference computer. Then you can use WDS to deploy your custom image to your destination computers.
For information about using WDS, see Deploy Windows Using Windows Deployment Services.
Selecting the Windows Image to Install During Windows Setup
In most installations, the product key specified in the Microsoft-Windows-Setup component is used to select a Windows image during Windows Setup. However, there may be instances when you have multiple Windows images of the same edition, particularly if you maintain a single Windows image (.wim) file that includes Windows images for multiple architecture types and languages.
To select the Windows image to install, do the following:
DISM /Get-WimInfocommand to determine which images and editions are included in your Windows product DVD or .wim file. For example:
DISM /Get-WimInfo /WimFile:D:\sources\install.wim
Deployment Image Servicing and Management tool Version: 6.1.7108.0 Details for image : D:\sources\install.wim Index : 1 Name : Windows 7 STARTER Description : Windows 7 STARTER Size : 7,936,340,784 bytes Index : 2 Name : Windows 7 HOMEBASIC Description : Windows 7 HOMEBASIC Size : 7,992,394,907 bytes Index : 3 Name : Windows 7 HOMEPREMIUM Description : Windows 7 HOMEPREMIUM Size : 8,432,859,356 bytes
Use the Unattend setting: Microsoft-Windows-Setup\ImageInstall\OSImage\InstallFrom\
MetaDatato specify the desired image. You can use either the image number, the image name, or the image description to choose the image. For example:
<ImageInstall> <OSImage> <InstallFrom> <MetaData wcm:action="add"> <Key>/IMAGE/NAME</Key> <Value>Windows 7 HOMEPREMIUM</Value> </MetaData> </InstallFrom> <InstallTo> <DiskID>0</DiskID> <PartitionID>2</PartitionID> </InstallTo> <WillShowUI>OnError</WillShowUI> </OSImage>
For information about using the product key to specify a Windows image, see Work with Product Keys and Activation.
For more information about using DISM, see the Deployment Image Servicing and Management Technical Reference.
For more information about the setting: Microsoft-Windows-Setup\ImageInstall\OSImage\
MetaData, see the Windows® Unattended Setup Reference.
Creating Architecture-Specific Sections for Each Configuration Pass in an Answer File
If you are performing cross-platform deployments, do not duplicate components for different architecture types in an answer file. If there are multiple components that apply to different architecture types in an answer file, there may be instances when the settings in the components are applied more than once, or are incorrectly applied.
For cross-platform deployments, you should create architecture-specific settings for each configuration pass in an answer file. For example, for a 32-bit preinstallation environment and a 64-bit destination computer, you should specify only x86-based components in the windowsPE configuration pass, and x64-based components in all other configuration passes.