This documentation is archived and is not being maintained.

Automate and manage Windows operating system deployments

 

Updated: October 6, 2015

How can this guide help you? As a computer and mobile device administrator and enterprise IT Professional, you can use this solution guide to understand the Microsoft recommended processes for creating and deploying Windows operating systems. 

In this solution guide:

The following diagram illustrates the problem that this solution guide is addressing.

Common problems facing desktop administrators when deploying enterprise operating systems:

Unmanaged operating system deployment

This section describes the current problem and goals that you might have. Review the solution and then check whether it meets your needs or whether you need to adjust it for your business environment.

Scenario

The computing infrastructure for many large enterprise organizations is built around Microsoft technologies including Windows Server and the network services necessary to support daily operations such as AD DS, DHCP, and WDS. In addition, many enterprise IT Professionals are already familiar with System Center Configuration Manager and use it to support computer and device management requirements. However, in many cases, those administrators are not familiar with Microsoft best practices recommendations or the operating system deployment tools and capabilities available to them. Instead, they typically use manual methods that include combinations of answer files, scripts, the Windows Automated Installation Kit (Windows AIK), and so on to perform operating system deployments. Because of this, operating system deployment projects can be extremely challenging and costly to implement.

Problem statement

The overall problem to solve is:

Enterprise Windows operating system deployments are complicated, costly, and it is difficult to ensure consistent results.  

Without following Microsoft best practices and using the recommended tools and technologies, operating system deployment projects do not scale well, and are inefficient and expensive. Even if great care is taken to manually document the steps necessary for each step in the deployment, things can and will eventually go wrong when deploying operating systems in this manner. Without automating operating system image creation and deployment testing, computer and mobile device administrators face the following challenges:

  • Downloading and maintaining operating system, drivers, and application files necessary to perform operating system deployments on all enterprise hardware.

  • Creating bootable images and painstakingly installing standard, desktop applications one at a time after operating system deployment has completed.

  • Manually deploying operating systems in production environments with very little testing.

  • Manually supporting ongoing configuration changes and other changing operating system deployment requirements.

  • Consistently performing operating system deployments using repeatable and reliable processes.

  • Accurately reporting on operating system deployment progress and issues.

Organizational goals

Based on the scenario and problem statement, a solution for automating and managing Windows operating system deployment that meets the following goals is needed:

  • Manage operating system, driver, and application files in a centralized file system.

  • Easily create or update Windows operating system images and then properly test them before beginning production deployments.

  • Rapidly deploy operating systems, desktop software, and Windows updates to new hardware using reliable and consistent processes.

  • Utilize enterprise-level operating system deployment management and reporting software.

The following diagram illustrates how you Use Microsoft Deployment Toolkit (MDT) lite touch installation (LTI) to automate operating system image creation and testing and then use Configuration Manager zero touch installation (ZTI) to manage and report on enterprise client operating system deployments. Following this recommended approach, you can meet the previously stated goals and solve this business problem in your environment.

System_CAPS_noteNote

Although the principles and recommendations in this solution can be applied to previous versions, unless otherwise stated MDT refers to MDT 2013 and Configuration Manager refers to Microsoft System Center 2012 Configuration Manager R2.

Automate and manage enterprise client operating system deployments solution design:

MDT and Configuration Manager

The following table lists the elements that are part of this solution design and describes why they’re included in the design:

Solution element

Why is it included in this solution design?

1.

Operating system and applicable files

Operating system installation files, including applicable operating system drivers and updates, must be available to deploy to new, bare metal computer hardware.

2.

MDT automation

MDT provides a lightweight working infrastructure for automating and deploying operating system images without the need, costs, or overhead of setting up and maintaining a completely separate Configuration Manager infrastructure solely for operating system image creation.

MDT is used to create and validate deployment images in a clean, test environment to reduce deployment time, increase security, and improve ongoing configuration management.

3.

MDT deployment share

The MDT deployment share is the repository for operating system images, language packs, applications, device drivers, and other software that will be deployed to target computers.

System_CAPS_noteNote

Target computers need to connect to the deployment share to perform operating system deployments so a high-speed, persistent connection from them to the deployment share is recommended.

4.

Operating system boot image

Operating system boot images are used for starting target computers using a customized version of Windows PE created when you update the MDT deployment share. The following boot images are created by the deployment workbench and stored in the deployment_share\Boot folder (where deployment_share is the network shared folder used as the deployment to start computers over the network):

  • LiteTouchPE_x64.iso and LiteTouchPE_x64.wim files (for 64-bit target computers)

  • LiteTouchPE_x86.iso and LiteTouchPE_x86.wim files (for 32-bit target computers)

System_CAPS_noteNote

When deploying to legacy BIOS computers, you can use a 32-bit boot image to deploy both 32-bit and 64-bit operating systems; however, a 64-bit boot image can only be used to deploy 64-bit operating systems. In contrast, UEFI systems require the architecture to match so a 64-bit system to which you’re deploying a 64-bit operating system would require a 64-bit boot image.

5.

WDS deployment server

 Windows Deployment Services, and PXE-based operating system deployment methods, is useful in the test environment because it is relatively easy to set up and it also enables faster, more iterative testing without the need to mount and dismount ISOs or create operating system CDs.

You must add the MDT boot image WIM files from the boot folder of the deployment share to Windows Deployment Services for custom, network-based operating system deployments.

System_CAPS_tipTip

You will only need to add the MDT boot images to Windows Deployment Services. You do not need to add operating system images from the Deployment Workbench.

6.

Test virtual machine installation

This test virtual machine, or reference computer, is used to validate the installation of operating system images created by MDT in a test environment.

System_CAPS_tipTip

The reference computer is the template for deploying new operating system images to target computers in production so be sure to configure this computer exactly as you want the production computers to be configured.

7.

Captured operating system image

The operating system image (WIM file) that is captured from the reference computer will be deployed to your target computers.

8.

Captured operating system image and device drivers

These files are necessary to run Windows on new device hardware in your environment including the drivers necessary for network and storage communication.

9.

Configuration Manager primary site server

A Configuration Manager primary site server with necessary operating system deployment features installed is used to deploy captured operating system images in the production environment.

10.

PXE-enabled distribution point

In this method of deployment, the operating system image and a Windows PE boot image are sent to a distribution point that is configured to accept PXE boot requests.

11.

Operating system deployment

PXE-initiated operating system deployments let computers request an operating system deployment over the network.

12.

Windows devices with standard software installed

The end result of this solution—Windows devices with driver files and standard desktop applications necessary for users to be successful.

There are many ways to install operating systems to a new computer, or bare metal system, such as MDT standalone, Configuration Manager build and capture, or MDT integrated into Configuration Manager. These methods assume that there is no user data or profile to preserve and can be used for everything from using MDT to create a “thin” Windows operating system image with basic updates and applications to integrating MDT with Configuration Manager to create and deploy ”thick” images containing many applications and post-installation configurations and management.

The following table provides an overview of possible methods and Microsoft recommendations for when each should be used for optimal performance and scalability.

System_CAPS_noteNote

Operating system deployment methods are often interchangeable. Use the recommendations provided below as guidelines to select the method most applicable to your individual needs.

Operating system deployment method

Recommended when

Microsoft Deployment Toolkit (MDT) standalone

MDT is a freely downloadable toolkit that helps automate the deployment of Windows operating systems and applications to desktop, laptop, and server computers. At a high level, MDT automates the deployment process by configuring the unattended Setup files for Windows and packaging the necessary files into a consolidated image file that you then deploy to reference and target computers.

System_CAPS_tipTip

In very small, or disconnected, environments MDT standalone might be all that you need to use for operating system deployment. In those cases, the test environment steps detailed in this solution would satisfy the operating system deployment process requirements for those environments.

MDT performs deployments by using the Lite Touch Installation (LTI) method. While you can create reference images for operating system deployment using Configuration Manager, in general we recommend creating them in MDT LTI for the following reasons:

  • MDT Lite Touch does not require any infrastructure and can be quickly set up.

  • Due to its simplicity and low footprint, MDT is typically the fastest way to create a reference image.

  • You can use the same image for every type of operating system deployment—Microsoft Virtual Desktop Infrastructure (VDI), Microsoft System Center 2012 R2 Virtual Machine Manager (SCVMM), MDT, Configuration Manager, Windows Deployment Services (WDS), and more.

  • With MDT, you can follow your deployments in real time, and if you have access to Microsoft Diagnostics and Recovery Toolkit (DaRT), you can even remote into Windows Preinstallation Environment (Windows PE) during deployment. The real-time monitoring data can be viewed from within the MDT Deployment Workbench, via a web browser, Windows PowerShell, the Event Viewer, or Microsoft Excel 2013. In fact, any script or app that can read an Open Data (OData) feed can read the information.

  • Configuration Manager performs deployments in the LocalSystem account context. This means that you cannot configure the Administrator account with all of the settings that you would like to be included in the image. MDT runs in the context of the Local Administrator, which means you can configure the look and feel of the configuration and then use the CopyProfile functionality to copy these changes to the default user during deployment.

  • MDT LTI supports a Suspend action that allows for reboots, which is useful when you need to perform a manual installation or check the reference image before it’s automatically captured.

System_CAPS_tipTip

It is best to use MDT to create “thin” images that contain necessary software updates, runtimes, and few standard desktop applications.

MDT and Configuration Manager

System_CAPS_importantImportant

This is the recommended operating system deployment method described in this solution.

This option is recommended for large, enterprise businesses with thousands of computers and applications to support and maintain. It is our recommendation for this solution based on the following Microsoft best practices:

  • You should use MDT for building and testing operating system images.

  • You should use MDT standalone for small-scale testing before deploying to production environments.

  • You should use MDT with WDS to enable PXE deployment integration for small pilots or small-scale production operating system deployments with LTI.

  • You should use MDT operating system images with Configuration Manager for large-scale operating system deployments to take advantage of enterprise-level management features such as: replication, multicast DPs, bandwidth management, reporting, poor network connections to remote sites, and stronger security through encryption and password protection.

Configuration Manager standalone

Configuration Manager operating system deployment provides administrative users with a tool for creating operating system images that they can deploy to computers. The operating system image, in a Windows Imaging Format (WIM) format file, contains the required version of a Windows operating system and any line-of-business applications that have to be installed on the computer.

System_CAPS_tipTip

It is best to use Configuration Manager (or MDT integrated with Configuration Manager) to create “thick” images that contain many line of business (LOB) applications that must be installed during operating system deployment rather than duplicating the applications in MDT.

MDT integrated with Configuration Manager

While only MDT is used in LTI deployments, ZTI and User Driven Installation (UDI) deployments are performed using MDT integrated with Configuration Manager.

Integrating MDT with Configuration Manager enhances the Configuration Manager operating system deployment feature by making additional MDT commands available to Configuration Manager task sequences.

For example, MDT 2013 simplifies the creation and operation of dynamic deployments. When MDT is integrated with Configuration Manager, the task sequence takes additional instructions from the MDT rules. In its most simple form, these settings are stored in a text file, the CustomSettings.ini file, but you can store the settings in Microsoft SQL Server databases, or have Microsoft Visual Basic Scripting Edition (VBScripts) or web services provide the settings used.

MDT 2013 also adds an optional deployment wizard. For some deployment scenarios, you may need to prompt the user for information during deployment such as the computer name, the correct organizational unit (OU) for the computer, or which applications should be installed by the task sequence. With MDT integration, you can enable the User-Driven Installation (UDI) wizard to gather the required information, and customize the wizard using the UDI Wizard Designer.

To take advantage of these, and other, enhancements after integrating MDT with Configuration manager, simply click Create MDT task sequence in the Task Sequences group on the Home tab on the Operating Systems node in the Software Library workspace of the Configuration Manager console.

Use the steps in this section to implement the solution. Make sure to verify the success of each step before proceeding to the next step. These steps are divided into two sections, the test environment using MDT standalone and production environment using Configuration Manager.

System_CAPS_noteNote

If you want to print or export a customized set of solution topics, see Print/Export Multiple Topics – Help.

In the test environment you will use MDT to deploy Windows to a reference computer, capture an image of the reference computer, and then deploy the captured image to a target computer to validate the deployment image before moving it into production.

Follow these implementation steps to create and test operating system images using MDT LTI.

  1. Prepare the environment and workbench computer for MDT installation to ensure the required infrastructure and supporting files are configured and installed correctly. Before starting MDT setup, be sure you have considered the following:

    Review the hardware and software requirements for the version of MDT that you are installing to ensure the workbench computer operating system is supported.

    System_CAPS_tipTip

    The MDT 2013 workbench is designed to work with the Windows 8.1 operating system. However, if you are not using Windows 8.1 for your workbench computer, you will need to install the .NET Framework 3.5 and Windows PowerShell 2.0.

    Download the appropriate version of the Microsoft Deployment Toolkit (MDT) required for the version of Windows you want to deploy.

    System_CAPS_tipTip

    MDT 2013 supports deployment of Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2.

    Download the Windows Assessment and Deployment Kit (Windows ADK) required for the version of MDT you are using.

    Check that Windows Deployment Services (WDS) is running on the network to enable PXE-boot installations and that both the deployment server and transport server role services are installed.

    WDS requires AD DS, DHCP, DNS, and an NTFS file system partition to store images. Configure WDS to respond to client requests and create the deployment share directory, but it is not necessary to add boot or operating system images at this step. On the WDS Server Advanced properties tab, ensure that you enable the “Authorize this Windows Deployment Services server in DCHP”.

    If DHCP will be the running on the same server as WDS, you will need to configure DHCP option 60 to use value of PXEClient.

    System_CAPS_importantImportant

    In this solution we are recommending WDS with DHCP option integration for ease of use in the test environment because that is suitable for small scale testing without using routers for network traffic management. However, this is not recommended for large scale production deployments on routed networks because that method is not as reliable as configuring routers. In production environments, you should implement DHCP relay agents, sometimes referred to as IP helpers, to enable network boot requests to reach designated servers from computers across a router from a DHCP server on a remote subnet.

    System_CAPS_tipTip

    Whether you plan to co-host WDS and DHCP on the same server or use two different servers you must configure WDS to listen on a specific port. DHCP and WDS both require port number 67. If you have co-hosted WDS and DHCP you can move DHCP or the PXE site role to a separate server or use the procedure below to configure the WDS server to listen on a different port.

    Modify the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE

    Set the registry value to:

    UseDHCPPorts = 0

    For the new configuration to take effect run the following command on the co-located DHCP and WDS server:

    WDSUTIL /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes

    Verification steps: 

    • Ensure you are planning to install the MDT workbench on a supported operating system, and have installed the .NET Framework 3.5 and PowerShell 2.0 if you are not using Windows 8.1.

    • You have identified the Windows Assessment and Deployment Kit (Windows ADK) required for the version of MDT you are using.

    • WDS and required network services are present and properly configured in the test environment.

  2. Install MDT and the Windows ADK by Downloading the MDT software and installing it on a supported operating system in the test environment accepting the default values.

    System_CAPS_importantImportant

    When you first open the MDT workbench after installation, you might be prompted to check for updated components. In MDT 2013, you should not do this because it will download an older list of components. Specifically, it will download an older version of bddmanifest.cab, reverting the component manifest (ComponentList.xml) to an older version. To learn more about this issue and other known issues with MDT 2013, you can review the MDT 2013 release notes.

    After MDT is installed, you need to install the appropriate Windows ADK to support the version of MDT you are using. When installing the Windows ADK, only the deployment tools and the Windows Preinstallation Environment (Windows PE) are required to interact with deployment shares.

    System_CAPS_tipTip

    After installing Windows ADK, log off, and then log on again to the computer so that the PATH environment variable is updated to include the %Program Files%\Windows Imaging folder.

    Verification steps: Check that the MDT and the appropriate version of the Windows ADK are installed on the MDT workbench computer before continuing. If you do not install the Windows ADK, you will be prompted to install it when trying to access the deployment shares node of the workbench console.

  3. Create an MDT deployment share that will be the repository for the operating system images, language packs, applications, device drivers, and other software that will be deployed to target computers. Start the New Deployment Share Wizard from the action pane in the deployment shares node of the MDT workbench to create a new MDT deployment share and take note of the location of the deployment share created.

    For this solution, MDT deployment share properties should be configured with defaults when you run the New Deployment Share Wizard.

    System_CAPS_tipTip

    The deployment share settings are stored in the CustomSettings.ini file in the deployment share’s Control folder and can be changed later.

    Verification steps: You should now see the deployment share name displayed in the details pane. By default, the MDT will create a deployment share folder named C:\DeploymentShare and a hidden shared folder called \\<computerName>\deploymentshare$. If you go to the location of the deployment share using file explorer, you should see that a folder structure has been created for you.

  4. Import operating system files into the Operating Systems node in the Deployment Workbench using the Import Operating System Wizard. If you will have many operating systems, you should create sub-folders in the Operating Systems node to store your files before importing them.

    System_CAPS_noteNote

    You can also create applications in MDT to install desktop software, but because this solution involves using Configuration Manager for desktop application installation, none will be created as part of this solution.

    Verification steps: If the Import Operating System Wizard was successful, the message “The process completed successfully” should be displayed. The name and description of the operating systems you import should be displayed in the MDT workbench console and the operating system installation files should have been copied into the operating system folder in the MDT deployment share folder structure.

  5. Add out-of-box drivers that are required for the reference computer and the target computer in your test environment by using the New Driver Wizard. These device drivers will be added to Windows PE and deployed with the operating system. Add the device drivers in the Out-of-box Drivers node in the Deployment Workbench.

    If you will support many operating systems or device types in your test environment, you should make sub-folders for each operating system and make and model you plan to deploy to.

    System_CAPS_tipTip

    If the device drivers for the reference computer and the target computer are included with operating system you are deploying, you can skip this step.

    Verification steps: Verify that the New Driver Wizard copies the device driver files to the deployment share in the appropriate Out-of-Box Drivers\<driver name> directories.

  6. Create a standard client task sequence for the reference computer using the New Task Sequence Wizard in the Task Sequences node of the Deployment Workbench that will be used to deploy and capture a reference computer image using the operating system files you previously imported into the workbench.

    System_CAPS_tipTip

    This task sequence should both install and capture the reference computer image. This is preferable to using two task sequences (one to install and one to capture) because if there is any lapse in time between when the system is built and when it’s captured, then it is possible that other configurations can be unexpectedly introduced.

    Verification steps: If the New Task Sequence Wizard was successful, the message “The process completed successfully” should be displayed. The name and description of the task sequence you created should also now be displayed in the MDT workbench console.

  7. Enable deployment process monitoring in the MDT deployment share properties. This will provide you basic monitoring of the task sequence as it processes the steps you have configured from within the MDT workbench. This will also add a line to the customsettings.ini file that is displayed on the Rules tab of the deployment share properties similar to EventService=http:// <computername>:9800.

    Additionally, more detailed logging can be enabled by manually modifying the customsettings.ini file contents on the Rules tab of the deployment share properties to create detailed log files for each computer when a task sequence is run; you can also enable dynamic logging to capture all active task sequence actions. You will first need to first create a network share to store log files and set the proper share permissions. If you want to enable dynamic logging, you should create a folder within the previously created network share to host that dynamic log file.

    • To configure per-computer logging, update your customsettings.ini rule file with the following line: SLSHARE=\\YourMDTServerName\YourMDTLogsShareName\%ComputerName%.

    • To configure dynamic logging to capture all task sequence activities in real time, update your customsettings.ini rule file with the following line: SLShareDynamicLogging=\\YourMDTServerName\YourMDTLogsShare\ YourDymanicMDTLogsShare 

    System_CAPS_tipTip

    While you are modifying the customsettings.ini rule file, you can also customize the organization name displayed in the MDT wizard by adding the following line above the logging entries: _SMSTSOrgName=OrganizationNameYouWantDisplayed. You can also

    Together, those lines would look like this in the customsettings.ini rules file:

    [Settings]
    Priority=Default
    Properties=MyCustomProperty
    
    [Default]
    OSInstall=Y
    SkipCapture=NO
    SkipAdminPassword=YES
    SkipProductKey=YES
    SkipComputerBackup=NO
    SkipBitLocker=NO
    
    Copy Logs if en error occurs or when deployment is successfully completed
    SLShare=\\<YourMDTServerName>\<YourMDTLogsShare>
    
    ; Enable Dynamig Logging
    SLSHAREDynamicLogging=\\<YourMDTServerName>\<YourMDTLogsShare>\<YourDymanicMDTLogsShare>
    
    _SMSTSOrgName=<OrganizationNameYouWantDisplayed>
    

    Verification steps:

    • If monitoring is enabled, you should not receive the message “No monitoring data is available because monitoring is ne enabled for this deployment share.” when the monitoring node of the deployment workbench is selected.

    • A line similar to the following has been added to the customsettings.ini file contents displayed on the Rules tab of the deployment share properties: EventService=http:// <computername>:9800

    • If you have added a custom organization name to be displayed by the task sequence, a line similar to the following has been added to the customsettings.ini file contents displayed on the Rules tab of the deployment share properties: _SMSTSOrgName=<OrganizationNameYouWantDisplayed>

    • If you have enabled detailed logging by adding custom log file share locations to the customsettings.ini file contents displayed on the Rules tab of the deployment share properties, then verify that you can access the network shares for both the per-computer logging directory and the dynamic logging directly that will contain a single BDD.log log file that is dynamically updated when a task sequence runs.

  8. Update the deployment share with the latest information after you have completed configuring it by using the Update Deployment Share action in the action pane of the MDT workbench. Updating the deployment share updates all the MDT configuration files and generates a customized version of Windows PE that is used to start the reference computer and initiate LTI deployment.

    When the deployment share is updated, MDT will generate ISO images and WIM image files that are used to initiate operating system deployment according to the settings you have configured in the deployment share properties. 

    Verification steps: When the deployment workbench is updated, MDT should have created the LiteTouchPE_x64.iso and LiteTouchPE_x64.wim files (for 64-bit target computers) and LiteTouchPE_x86.iso and LiteTouchPE_x86.wim files (for 32-bit target computers) in the \\<computerName>\deploymentshare$\Boot folder.

  9. Load boot image into the WDS console to enable target computers to start using the customized Windows PE images over the network.

    All that you need to add is the boot image created by MDT to the Boot Images node in the WDS console (right-click Boot Images, and browse to the location of the boot image created by MDT in the last step (%InstallDir%\DeploymentShare\Boot\LiteTouchPE_x64.wim). There is no need to add any install images to WDS.

    Verification steps: If the Add Image Wizard was successful, the message “The operation is complete. The selected images were successfully added to the server.” should be displayed. Additionally, when you start a computer configured to boot from the network, select the option to boot from PXE, the custom boot image should be available from the list of options.

  10. Use PXE to install and capture your image over the network. Start the reference computer and select the option to PXE network boot from network using WDS and then select the boot image that was previously uploaded into WDS to start the customized Windows PE environment.

    When the Windows Deployment Wizard starts, select and run the standard client task sequence that you previously created to install and capture the operating system on the reference computer. There is no need to worry about the majority of settings that are displayed by the Windows Deployment Wizard, but be sure to select the option to capture an image of the reference computer on the Capture Image wizard page. Otherwise, simply accept the defaults, including the path to store the captured image, and begin the operating system installation and image capture process.

    System_CAPS_tipTip

    By default, you’ll need to provide network access credentials to access the deployment share from WinPE each time the computer starts from the boot image. If you will be doing a lot of testing using this method, you can add network share access credentials by editing the Bootstrap.ini file contents found on the Rules tab of the deployment share properties similar to the following example. After doing so, be sure to update the deployment share and replace the boot image stored on the PXE server.

    
    [Settings]
    Priority=Default
    
    DeployRoot=<DeployRootPath>
    UserDomain=<FQDNofTestDomain>
    UserID=<TestDomainUser>
    UserPassword=<TestDomainUserPassword>
    
    

    Verification steps: The reference computer should go through the steps necessary to install the operating system defined in the task sequence. Afterwards, it should immediately run the sysprep and capture steps to save an image of the reference computer in the network share specified when running the task sequence. By default, the captured image should be present in the %InstallDir%\DeploymentShare\Captures directory.

  11. Add the captured reference image to the deployment workbench. Before you can deploy the capture image, it must be added to the list of operating systems in the Operating Systems node in the Deployment Workbench from the %InstallDir%\DeploymentShare\Captures directory using the Import Operating System Wizard.

    Verification steps: When the Import Operating System Wizard finishes, the captured image of the reference computer should be added to the list of operating systems in the details pane of the Operating Systems node in the deployment workbench and the captured WIM file should be copied to the operating systems directory.

  12. Create a second standard client task sequence using the New Task Sequence Wizard. This task sequence will be used to deploy the captured image to a target, test computer. You should do this to ensure the basic deployment is functional as desired before moving into production environment.

    System_CAPS_tipTip

    Be sure to select the captured image from the operating system options in the deployment workbench during task sequence creation.

    Verification steps: If the New Task Sequence Wizard was successful, the message “The process completed successfully” should be displayed. The name and description of the task sequence you created should also now be displayed in the MDT workbench console.

  13. Use PXE to deploy and test your captured image over the network. Start the target computer and select the option to PXE network boot from network using WDS and then select the boot image that was previously uploaded into WDS to start the customized Windows PE environment.

    When the Windows Deployment Wizard starts, select and run the standard client task sequence that you previously created to install the captured operating system on the target computer. You should not select the option to capture an image of this computer on the Capture Image wizard page. Simply accept the defaults and click Next to begin the operating system installation process.

    Verification steps: The target computer should automatically go through the steps necessary to successfully install the reference computer image . When complete, the Deployment Summary dialog box should appear with no errors and no warnings reported.

  14. Copy the reference computer image to a portable storage device or removable media in order to transport it to the production computing environment. Before beginning the production environment steps, you need to copy the reference computer image to a valid network share in the production environment so that it can be imported into the Configuration Manager console.

    Verification steps: The captured and tested operating system image from the reference computer is now present on a portable storage device or removable media that can be taken to the production environment.

In the production environment you will use Configuration Manager to deploy the Windows operating system image (WIM file) that you captured in the test environment using MDT.

Use the following implementation steps to deploy and manage enterprise operating system images in your production environment using Configuration Manager ZTI.

  1. Ensure the production network environment will support PXE boot requests from Configuration Manager clients.

    Be sure that AD DS, DHCP, and DNS are available to computers starting from the network.

    System_CAPS_noteNote

    It is not necessary to install WDS during this step as the required WDS components will be installed on PXE-enabled Configuration Manager distribution points in the next step.

    You should also determine an appropriate range of IP addresses that DHCP will provide on the network to use as a Configuration Manager site boundary to support network book requests.

    Verification steps: You have ensured the network environment will support PXE boot requests from computers starting from the network and determined a suitable DHCP-based IP address range to use for a Configuration Manager site boundary.

  2. Prepare the Configuration Manager environment for deploying operating systems over the network.

    Enable Configuration Manager Distribution points to respond to PXE requests from the network. You will need to be sure that PXE support for clients is enabled on the PXE tab of distribution point properties (which will install WDS if required) and also allow the distribution point to respond to incoming PXE requests to enable the distribution point to accept PXE boot requests from computers on the network.

    System_CAPS_tipTip

    For additional security, you should also require a password for computers to use the PXE-enabled distribution point when starting from the network.

    The Configuration Manager client needs an account to provide credentials when accessing the Configuration Manager distribution points over the network. This account is necessary because Configuration Manager client computers use the Local System account to perform most operations on the computer, but LocalSystem cannot access network resources during network-based operating system deployments.

    To enable unknown computers to access Configuration Manager network resources, you will need to create and configure a Configuration Manager network access account.

    System_CAPS_tipTip

    You can create and configure the network access account in the Administration node of the Configuration Manager console. To do so, just right-click on your site name, select Configure Site Components and then Software Distribution. From there, select the Network Access Account tab to configure the account properties.

    Create an IP range based boundary based on the DHCP-based IP address range you determined in the previous step. You need to do this because unknown computers booting from the network will not be in AD DS yet and unless site boundaries are specified, the client assumes that the computer running Configuration Manager is in a remote site. After adding a site boundary based on the DHCP supported IP subnet, add the site boundary to a site boundary group.

    Verification steps: 

  3. Enable the default boot images to support PXE in the Configuration Manager console. In the original release of Configuration Manager 2012, you need to manually configure the default boot images to support PXE boot requests. In later versions, this support is enabled by default.

    Verification steps: Verify that the default boot images are PXE-enabled by ensuring the Deploy this boot image from the PXE service point option is enabled on the Data Source tab of the boot image properties in the Configuration Manager console.

    System_CAPS_noteNote

    After verifying that the default boot images are PXE-enabled, you should also check the content status to ensure the PXE-enabled boot images have been successfully distributed to the site distribution points supporting PXE boot requests.

  4. Import the captured reference image that you created using MDT into Configuration Manager console, operating systems images node. To do that, use the Add operating system image wizard to browse to the network share that you saved the captured reference computer image.

    Verification steps: The Add operating system image wizard completed successfully and imported the captured reference computer image into the Configuration Manager console.

  5. Before you can use PXE to deploy the captured operating system image, you must distribute the operating system image content to PXE-enabled distribution points in the site using the Distribute Content Wizard.

    After the captured operating system image is successfully added, you should also enable the option to Copy the content in this package to a package share on distribution points to allow clients to install the content from the network.

    Verification steps: The distribute content wizard should complete successfully and the content status for the captured image distribution should complete successfully after a few moments.

    System_CAPS_tipTip

    Now is a good time to ensure that both of the boot images (x86 and x64) are distributed as well as the operating system image you just imported.

  6. Create a task sequence to deploy the captured operating system image package from the Task Sequences node of the Configuration Manager console that will be used to deploy the image and join the new computer to the production domain.

    System_CAPS_noteNote

    For this solution, you do not need to install updates or applications during deployment, but after you are comfortable with the overall process, you should use those options to create more complete task sequences for future deployments.

    Verification steps: The new deployment task sequence should now be displayed in the results pane of the Task Sequences node in the Configuration Manager console.

  7. Deploy the task sequence as Available to the All Unknown Computers collection that contains default resource records (one record for 64-bit computers and another for 32-bit computers) for systems that are not currently members of the Configuration Manager database.

    You should make this task sequence deployment Available instead of Required to safeguard against the task sequence running accidentally on computers with network boot options set higher than local hard drives in the system BIOS. Also note that this can happen regardless of the availability or expiration times set for the task sequence deployment.

    System_CAPS_tipTip

    For additional security, you should require a password for computers to use PXE-enabled distribution points when starting from the network as described in step 2 of the production environment implementation steps.

    Verification steps: The deploy software wizard should complete successfully.

  8. Install the captured operating system image on a bare metal test computer in the production environment using PXE boot.

    When the computer starts and boots from the network, it will acquire an IP address from the DHCP server, connect to the Configuration Manager site server to run the task sequence you previously deployed to the All Unknown Computers collection. After a dialog box opens to notify you that the task sequence is about to run, the task sequence should run and display an installation progress dialog box to show the tasks being run on the computer as it completes the operating system deployment process.

    Verification steps: Ensure the PXE-boot is successful and the bare metal computer starts using the boot image over the network. After providing the password (if required) to start the imaging process, the actions defined in the task sequence are completed.

  9. Monitor OS deployment in the Monitoring workspace of the Configuration Manager console by expanding Deployments and selecting the task sequence deployment that you previously deployed. Right-click the task sequence name in the Results pane and click Run Summarization and then refresh the results pane information to view the most current monitoring information.

    System_CAPS_tipTip

    If you have the Reporting Services Point site system role installed, you can also review the operating system deployment reports available to you for reporting on task sequence process success.

    Verification steps: Task sequence progress and deployment status progresses through in progress to success.

  10. Validate the test production computer installation of the captured reference system image. Log into the production test computer and verify that the task sequence has successfully completed with the expected operating system installed with the expected configurations.

    You should also now be able to see the new computer name represented as an assigned computer resource client for the Configuration Manager site in the All Systems Collection in the Configuration Manager console.

    Verification steps: The task sequence should have completed successfully to install the captured reference operating system image, join the production domain, and installed and initiated the Configuration Manager client. The new computer client resource record should also now be present in the All Systems collection of the Configuration Manager console.

Implementation complete.

Show: