Windows Server 2012 : Deploying Servers - Building images - Building reference images using MDT 2012 Update 1

8/21/2013 11:21:16 AM

Building reference images using MDT 2012 Update 1

The steps that need to be performed for using a technician computer to build reference images for deploying Windows Server 2012 using MDT 2012 Update 1 are as follows:

Install the ADK on the technician computer.
Install MDT on the technician computer.
Create a deployment share using the Deployment Workbench.
Import the Windows Server 2012 operating-system source files.
Import any out-of-box drivers needed by the target production systems.
Import any applications you want to include in your image.
Import any packages—such as hotfixes, software updates, or language packs—that you want to include in your image.
Create a task sequence for deploying, sysprepping, and capturing the reference image.
Customize the MDT configuration files to automate some or all of the deployment process.
Update the deployment share to create boot images for kick-starting the deployment process.
Deploy Windows Server 2012 onto the reference computer, run Sysprep, capture a reference image, and copy it to the deployment share.

Step 1. Installing the ADK

The ADK can be installed on the following versions of Windows:

Windows Server 2012
Windows Server 2008 R2
Windows Server 2008 with Service Pack 2
Windows 8
Windows 7
Windows Vista

The ADK also requires the Microsoft .NET Framework 4 and installs it automatically if it is not already present on the computer.

Installing the ADK involves performing the following steps:

Ensure that the computer you will be installing the ADK on supports installation of the product and that all the necessary software requirements have been met.
Download the installation bootstrap file (adksetup.exe) for the ADK from the Microsoft Download Center at http://www.microsoft.com/en-us/download/details.aspx?id=30652.
Double-click on the installation bootstrap file, and follow the prompts to install the ADK components you want to install on the computer. The components to choose from include the following:
- Application Compatibility Toolkit (ACT)
- Deployment Tools
- Windows Preinstallation Environment (Windows PE)
- User State Migration Tool (USMT)
- Volume Activation Management Tool (VAMT)
- Windows Performance Toolkit
- Windows Assessment Services
- Microsoft SQL Server 2012 Express

Note

ADK components

For a basic Windows Server deployment using MDT, the only ADK components needed are the Deployment Tools and the Windows Preinstallation Environment (Windows PE). For the deployment of desktop versions of Windows, you might need other ADK components as well.

Step 2. Installing MDT

MDT 2012 Update 1 can be installed on the following versions of Windows:

Windows Server 2012
Windows Server 2008 R2
Windows Server 2008 with Service Pack 2
Windows 8
Windows 7
Windows Vista

The software prerequisites for installing MDT 2012 Update 1 include the following:

Microsoft Management Console version 3.0
Microsoft .NET Framework 3.5 with Service Pack 1 (SP1) or later
Windows PowerShell version 2.0 or later

In addition, the latest version of the Windows ADK for Windows 8 is required and should be installed before installing MDT. For more information on supported platforms and installation requirements, see the release notes for MDT 2012 Update 1, which you can download from http://www.microsoft.com/en-us/download/details.aspx?id=25175.

Installing and configuring MDT 2012 Update 1 involves performing the following steps:

Ensure that the computer you will be installing MDT 2012 Update 1 on supports the installation of the product and that all the necessary software requirements have been met.
Download the appropriate version (x64 or x86) of the MDT 2012 Update 1 Windows Installer (.msi) file for the platform you will be installing it on by using the download link on the Microsoft Deployment Toolkit home page at http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx.
Double-click on the .msi file, and follow the prompts to install MDT on the computer.

Step 3. Creating a deployment share

After you install the ADK and MDT on a computer, the next step is to create a deployment share. A deployment share is a shared folder on the technician computer that will be used to contain and manage the following items:

Operating-system source files for building and deploying images
Out-of-box drivers for target systems that need them
Applications to be deployed on target systems
Packages—for example, software updates or language packs
Task sequences, which are used to control the deployment process
Advanced configuration features, such as selection profiles, the MDT database, media deployment points, and linked deployment shares
Hidden items not displayed in the Deployment Workbench, such as Windows PE images for initiating the Lite Touch Installation (LTI) deployment process on target systems

In addition, the deployment share includes a Monitoring node that can be used for monitoring the progress and status of LTI deployments while they happen.

Creating a deployment share involves performing the following steps:

Launch the Deployment Workbench, which is used for building, capturing, and deploying Windows images to target systems.
Right-click the Deployment Shares node, and select New Deployment Share.
Follow the prompts of the New Deployment Share Wizard, and do the following:
- Specify the path, the share name, and a description for the deployment share.
- Configure the deployment share by selecting or clearing the options shown here:

Figure 1 shows the Deployment Workbench after creating a deployment share called MDT Deployment Share.

Figure 1. The Deployment Workbench with a new deployment share selected to show its structure.

Step 4. Importing operating-system source files

After you create a deployment share, the next step is to use the Deployment Workbench to import source files for the operating systems you plan to deploy. Before you can build and capture a reference image of a master installation of a supported version of Windows, you must import a full set of source files for that version of Windows. You can also import previously captured image files into your deployment share, or images stored on a Windows Deployment Services server on your network.

Importing the source files for a Windows operating system involves performing the following steps:

Launch the Deployment Workbench if it is not already running, and expand the node for the deployment share you created earlier.
Right-click the Operating Systems node in your deployment share, and select Import Operating System as shown here:
Follow the prompts of the Import Operating System Wizard to import a full set of source files for the Windows operating system you plan to deploy.

Step 5. Importing out-of-box drivers

If the computer on which you will be deploying your master installation of Windows requires any special device drivers, you should import these drivers into your deployment share. This is especially important when deploying server versions of Windows onto systems that have mass storage devices such as RAID controllers that are either very old or very new, because in both cases the drivers for these controllers might not be included with Windows Server 2012. If you don’t import boot-critical, mass-storage drivers into your deployment share, MDT might not be able to find a local storage device on which to install Windows.

Importing out-of-box drivers involves performing the following steps:

Obtain the device drivers needed for the hardware on which you will be installing Windows.
Launch the Deployment Workbench if it is not already running, and expand the node for the deployment share you created earlier.
Right-click the Out-of-Box Drivers node in your deployment share, and select Import Drivers.
Follow the prompts of the Import Drivers Wizard to import the drivers into the deployment share.

Device drivers can be one of the most frustrating and problematic aspects of Windows deployment for a number of reasons:

It can be difficult to find the drivers you need. Some vendors, such as Dell and HP, provide special tools for finding and downloading drivers for their hardware, and you will have to learn how to use their tools.
Device drivers must be in a certain form before you can import them into the Deployment Workbench. Specifically, you need the driver’s INF file. If the vendor makes its drivers available as .cab files, you can easily extract these into a folder and import them into the Deployment Workbench. If the vendor makes them available as Setup programs (.exe files), however, you might need to use a third-party tool like WinRAR to extract the driver files from the .exe file before you can import them.
Driver incompatibilities can cause problems during deployment. For example, if the wrong mass-storage driver is used when deploying Windows to a system, the system might “blue-screen”and cause the installation process to fail. This problem can often arise when a deployment share is being used to deploy several different versions of Windows and you have imported all the drivers for each of the various versions into the Out-of-Box Drivers folder of your deployment share. When you do this, the result is that during the deployment process Windows will decide which drivers to use by using Plug and Play. Unfortunately, it sometimes happens with this approach that a 32-bit driver might end up getting installed on 64-bit hardware or vice versa, resulting in a failed deployment.

You can prevent such issues from arising by creating a hierarchy of subfolders beneath the Out-of-Box Drivers folder, with each subfolder representing a specific Windows version and architecture. You can then further differentiate drivers according to the make and model of system hardware they apply to by creating a deeper subfolder hierarchy such as the following:

Out-Of-Box Drivers
--- Operating System 1
------ Make 1
--------- Model 1
--------- Model 2...
------ Make 2...
--- Operating System 2...

You then import the specific drivers needed for each Windows version or architecture into the appropriate driver subfolder. You can then use another MDT feature called selection profiles to associate each driver subfolder with a different task sequence, which allows each task sequence being used to deploy a different version or architecture of Windows on each make or model of hardware in your environment. The downside of the driver subfolders approach is that it is more work to set up than simply dumping all the drivers into the Out-of-Box Drivers folder and letting Plug and Play decide which ones to use during deployment.

Step 6. Importing applications

If you plan on deploying applications when you deploy Windows to target systems, you can import the application source files into the Applications node of your deployment share. Including applications is common when deploying client versions of Windows, but it is less frequently done when deploying server versions of Windows because of the complexity of installing and configuring server applications such as Microsoft Exchange, Microsoft SharePoint, or Microsoft SQL Server.

Step 7. Importing packages

If you need to include software updates, language packs, or other packages when you deploy Windows, you can import these as packages into the Packages node of your deployment share. Packages must be in the form of .cab or .msu files if you want to be able to import them into your deployment share.

Note

Software updates and deployment

Software updates can also be installed on your master installation by specifying a Windows Software Update Services (WSUS) server in the CustomSettings.ini file of your deployment share.

Step 8. Creating a task sequence

The next step is to create a task sequence. A task sequence defines the series of steps that will be performed during the deployment process and determines whether any additional software or customizations will be included when Windows is installed. For your build lab, you need to create a task sequence of type Standard Client Task Sequences that can be used to deploy Windows, together with any additional software or customizations indicated, onto the reference computer. You will also be able to use this task sequence to run Sysprep on the deployed installation of Windows, capture an image of the installation, and copy it to the Captures folder of the deployment share on your technician computer.

Task sequences can be created by right-clicking on the Task Sequences subfolder of a deployment share and selecting New Task Sequence to launch the New Task Sequence Wizard shown in Figure 2.

Figure 2. Creating a new task sequence for deploying Windows to the reference computer.

Step 9. Automating the deployment process

At this point, you can choose to automate some or all of the deployment process in your build lab. Automation can be implemented in two ways. First, you can automate the general flow of the deployment process by modifying the two configuration files associated with the deployment share:

BootStrap.ini This file contains any information needed to successfully establish a connection between the deployment share and the computer on which Windows will be installed.
CustomSettings.ini This file is used to control the remainder of the deployment process by displaying or hiding various pages of the Windows Deployment Wizard, which runs on the computer on which Windows is being installed.

The other way you can automate various aspects of the deployment process is by making modifications to the task sequence used to perform your deployment. As Figure 3 shows, a task sequence consists of a series of task sequence groups such as the following:

Initialization
Validation
State Capture
Preinstall
Install
Postinstall
State Restore

Figure 3. Customizing a task sequence.

Each task sequence group corresponds to a particular phase of the deployment process, and consists of one or more task sequence steps. For example, the Validation phase, which identifies whether the target computer is capable of running the scripts necessary to complete the deployment process, performs the following three steps in the order shown:

Validate Verifies that the target computer meets the specified deployment prerequisite conditions
Check BIOS Checks the basic input/output system (BIOS) of the target computer to ensure that it is compatible with the operating system you are deploying
Next Phase Updates the Phase property to the next phase in the deployment process

You can customize your task sequences in the following ways:

By modifying the values and selections of properties on different task-sequence step pages
By moving selected task-sequence groups or steps up and down to change when they take place during the overall deployment process
By adding new task-sequence steps to existing task-sequence groups
By adding new task-sequence groups and adding steps to them as desired

More information about customizing task sequences can be found in the documentation included when you download MDT from the Microsoft Download Center.

Note

REAL WORLD Automating your build lab

Depending on how you configured your deployment share when you created it, the CustomSettings.ini file associated with the deployment share will be configured to display most (if not all) pages of the Windows Deployment Wizard. In other words, you will have to respond to a series of prompts displayed on the reference computer to install Windows on the computer.

If you edit the CustomSettings.ini file by adding property/value pairs to it, however, you can automate most or even all of the MDT deployment process. You can also modify your task sequence to further customize your automated build process—for example, so that it downloads and installs any necessary software updates from Windows Update or a Windows Server Update Server (WSUS) on your network as part of the reference-image build process.

Automation is a good thing in build labs because it simplifies the task of maintaining your reference images by regenerating them when the need arises.

Step 10. Updating the deployment share

Before the technician computer can be used to build a reference image, the deployment share must be updated to create or regenerate the boot images that will be used to kick-start the deployment process on the reference computer. To update a deployment share, right-click on it, select Update Deployment Share, and follow the wizard prompts. Updating a deployment share might take several minutes and creates two types of boot media:

LiteTouchPE_ arch.iso ISO files can be created for two architectures (x64 and x86) and can either be burned to DVD and used to boot physical computers or attached to virtual machine to boot them into the deployment process.
LiteTouchPE_ arch.wim WIM files can also be created for two architectures (x64 and x86) and imported into a Windows Deployment Services server (if you have one) to enable target systems (physical or virtual) to PXE-boot into the deployment process.

Note

Selecting boot media

Because Windows Server 2012 can be installed only on x64 system hardware, you must use either the LiteTouchPE_x64.iso or LiteTouchPE_x64.wim files as your boot media for kick-starting the deployment process. You cannot use ISO or WIM files for the x86 architecture for deploying Windows Server 2012.

Step 11. Deploying and capturing the reference image

At this point, you are now ready to use your technician computer to deploy Windows Server 2012, along with any additional software or customizations you have specified, to the reference computer in your build lab. To do this, you do the following:

Boot the bare-metal reference computer using the boot media (either ISO or WIM) created in step 10.
Proceed through the steps of the Windows Deployment Wizard as it displays on the reference computer, responding to each prompt as appropriate. For example, on the Capture Image page shown in Figure 4 you can select the option Capture An Image Of This Reference Computer, which installs Windows, runs Sysprep, captures an image, and copies the image over the network to the Captures folder of your deployment share on your technician computer.

Figure 4. Specifying that an image be captured when the installation is finished.

Testing reference images

After you build your reference image, you should first deploy it on a test system in your build lab to make sure everything works as intended. Depending on whether your production environment has physical servers or virtual machines, you can choose either physical servers or virtual machines as your test systems.

To test your reference images, use your build lab to do the following:

Create a new task sequence of type Standard Client Task Sequence that you will use to deploy your reference image to your test systems.
Prepare your boot media for kick-starting the deployment process by doing one of the following:
1. Burning the LiteTouchPE_64.iso file to DVD media for manually booting a physical test system
2. Attaching the LiteTouchPE_64.iso to a virtual machine for manually booting a virtual test system
3. Importing the LiteTouchPE_64.wim file into a Windows Deployment Services server for automatically booting a test system (physical or virtual) using PXE boot
Boot the test system, and deploy your reference image onto it.
When the deployment process has completed, log on to your test system and verify that the software and customizations you specified to be included in the installation have been installed and applied as intended.

When you’re satisfied that your reference image works properly, you are ready to deploy it onto systems in your production environment.

Others

- Windows Server 2012 : Deploying Servers - Preparing the build lab

- Windows Phone 8 : Multitasking - Background Transfer Service

- Windows Phone 8 : Multitasking - Location-Aware Apps

- Active Directory 2008 : Managing Enterprise Security and Configuration with Group Policy Settings -- Implementing an Audit Policy (part 2) - Auditing Directory Service Changes

- Active Directory 2008 : Managing Enterprise Security and Configuration with Group Policy Settings -- Implementing an Audit Policy (part 1) - Auditing Access to Files and Folders

- Active Directory 2008 : Managing Enterprise Security and Configuration with Group Policy Settings -- Managing Software with Group Policy (part 2)

- Active Directory 2008 : Managing Enterprise Security and Configuration with Group Policy Settings -- Managing Software with Group Policy (part 1)

- Microsoft Lync Server 2010 : PBX Integration - Key Improvements

- Microsoft Lync Server 2010 : PBX Integration - End-User Scenarios

- Microsoft Lync Server 2010 : PBX Integration - Integration Methods