Deploying Windows 7 - Bandwidthco Computer Security

Deploying Windows 7 

By Mitch Tulloch 

(WindowsNetworking.com) 

Part 1: Windows AIK 2.0 Enhancements 

Windows 7 deployment: examining the enhancements made in version 2.0 of the Windows 

Automated Installation Kit. 

Introduction 

My previous series of articles titled; Deploying Vista, covered the basic concepts and tasks for 

automating the deployment of Windows Vista SP1 Enterprise using the following tools: 

Windows Automated Installation Kit (Windows AIK) version 1.1 

Windows Deployment Services (Windows DS) server role for Windows Server 2008 

Microsoft Deployment Toolkit (MDT) 2008 Update 1 

Now that Windows 7 has reached Release Candidate stage, many enterprises who passed on 

migrating their desktop computers to Windows Vista are taking a hard look at migrating them to 

Windows 7. This is a good idea for two important reasons: 

Mainstream support for Windows XP is now ended, so it's definitely time to think about upgrading 

your desktops to a newer version of Windows to ensure support. 

The general consensus is that Windows 7 is everything that Windows Vista should have been—a 

lean, reliable, high-performing operating system with exciting new features that makes end-users 

more productive and the job of IT administrators easier. 

But instead of rewriting all thirty-one (!) of my Deploying Vista articles in order to update them for 

Windows 7, the path I have decided to follow in this new series of articles is to focus on the deltas 

between deploying the two platforms. This approach should make this current series much shorter 

than the previous one, while still covering all the new features of Windows 7 deployment. 

So let us begin by looking at the newest version of the Windows AIK and how this has changed in 

Windows 7. 

Note #1: I will be referring you back to specific articles in my Deploying Vista series wherever this is 

helpful. 

Note #2: This article is based on the Release Candidate (RC) version of Windows 7 and will be 

updated later if necessary to reflect any changes made in RTM. 

Windows AIK 2.0 Enhancements 

In article 1 of my Deploying Vista series, we learned about version 1.1 of the Windows AIK, which 

included various tools, documentation, and other stuff that formed the foundation for automating Vista 

deployment. Windows 7 has a new version of the Windows AIK that includes new deployment tools 

but also deprecates some older tools. 

First, here are some of the tools that were in Windows AIK 1.1 and are still in Windows AIK 2.0 but 

may have changed somewhat: 

Windows System Image Manager (Windows SIM) is pretty much unchanged (see article 6 of my 

Deploying Vista series) although there are some new answer file settings, some existing answer 

file settings that have changed, and some deprecated answer file settings in Windows 7. We'll 

examine these changes to answer file settings changes in a future article of this series. 

Revised June 14, 2009 Page 1 of 231




ImageX, the command-line tool for offline servicing of Windows image (WIM) files is still present 

but has been enhanced with several new command-line options. We learned about ImageX in 

article 12 of my earlier series and saw how to use this tool in article 13 of that series; we'll learn 

more about the changes to ImageX in a future article of this present series. 

Several other command-line tools that were included in the Windows AIK 1.1 are also still included 

in the Windows AIK 2.0. These tools include Bootsect, Drvload, Oscdimg, and so on. 

Now here are a few tools that are new to Windows AIK 2.0: 

Deployment Image Servicing and Management Tool (DISM) is a new command-line tool in 

Windows AIK 2.0 that combines the functionality three tools found in the Windows AIK 1.1: 

Package Manager (Pkgmgr.exe), the International Settings Configuration Tool (Intlcfg.exe) and 

the Windows Preinstallation Environment (PEimg.exe) tools. DISM.exe also includes basic image 

management capabilities and can be used to mount Windows images in order to add device 

drivers, packages, and perform other image servicing tasks. We will examine DISM.exe in more 

detail in the next article of this series. 

BCDboot is a new command-line tool that can be used to quickly set up a system partition of 

repair the computer's boot environment (which is located on the system partition). BCDboot is 

typically run from Windows PE and we will examine it in more detail in a future article of this series. 

User State Migration Tool (USMT) 4.0 is a new version of USMT for Windows 7 (the old version 

3.0.1 was used with Vista) can be used for migrating user profiles during large-scale deployments 

where you want to maintain existing user data and settings. USMT 4.0 is now included in the 

Windows AIK 2.0 (with Windows AIK 1.1, you had to separately download USMT 3.0.1) and has 

some cool new features such as hardlink migration that make migrating user profiles easier than 

ever. We'll examine USMT 3.0 in a future article of this series. 

Volume Activation Management Tool (VAMT) lets you automate and centrally manage the volume 

activation of Windows clients using a Multiple Activation Key (MAK). In Windows Vista, this tool 

was part of Microsoft Volume Activation 2.0 and had to be separately downloaded; in Windows 7 

however, the new version 1.2 of VAMT is now included as part of the Windows AIK 2.0. 

Finally, the following tools that were part of the Windows AIK 1.1 are now deprecated in the Windows 

AIK 2.0: 

Package Manager (Pkgmgr.exe) is still included in Windows AIK 1.1 (and also in a default 

Windows 7 install) but is no longer needed because its functionality is now included in DISM.exe 

International Settings Configuration Tool (Intlcfg.exe) has been removed because its functionality 

is now included in DISM.exe 

Windows Preinstallation Environment (PEimg.exe) has been removed because its functionality is 

now included in DISM.exe 

PostReflect.exe and VSP1CLN.exe have also been removed. 





Installing the Windows AIK 2.0 

Whilst writing the RC version of Windows AIK 2.0, it was only available on Microsoft Connect or as 

part of your MSDN or TechNet subscription. When Windows 7 is released to manufacturing, Windows 

AIK 2.0 will be available from the Microsoft Download Center as an .iso image file you can mount or 

burn to DVD media. 

You can install the Windows AIK 2.0 onto a technician computer running any of the following 

operating systems: 

Windows XP SP3 

Windows Server 2003 R2 SP3 

Windows Vista 

Windows Server 2008 

Windows 7 

Windows Server 2008 R2 

If you install the Windows AIK 2.0 on a pre-Vista operating system, you must make sure that you 

download and install the .NET Framework 2.0 and MSXML 6.0 first on the system. 

Figure 1 below shows the splash screen when you install the Windows AIK 2.0. Note that you can use 

this screen to download the following additional tools you may need for performing your deployment: 

Application Compatibility Toolkit (ACT) 5.5 which can be used to evaluate and mitigate application 

compatibility issues before migrating your desktops to Windows 7. 

Microsoft Assessment and Planning (MAP) is an inventory, assessment and reporting tool that 

does not use agent software and can be used to securely assess your environment prior to 

beginning your migration to Windows 7. 

Microsoft Deployment Toolkit (MDT) 2010 which helps to automate desktop deployment using 

scripts, a unified Deployment Workbench, and other resources. We looked at how to use the 

earlier MDT 2008 beginning with article 24 of my Deploying Vista series; MDT 2010 includes many 

new features and enhancements and we'll be examining them in future articles of this series. 

Figure 1: Splash screen when you insert the Windows AIK 2.0 DVD 





Once you have installed the Windows AIK 2.0 on your technician computer, you can use it to deploy 

the following operating systems: 

Windows XP SP3 

Windows Server 2003 R2 SP2 

Windows Vista SP1 or later 




Additional Resources 

More information concerning the Windows AIK 2.0 can be found in the Windows Automated 

Installation Kit User's Guide (WAIK.chm) which can be accessed by clicking Start | All Programs | 

Microsoft Windows AIK on a technician computer on which you have installed the Windows AIK 2.0. 

By the time this article appears on WindowsNetworking.com you should also be able to view this 

User's Guide on Microsoft TechNet in the Windows 7 section of the Windows Client Tech Center. 

Part 2: Using DISM 

Windows 7 deployment; continuing by examining how to use the Deployment Image Servicing and 

Management(DISM)Tool. 

Note: This article is based on the Release Candidate (RC) version of Windows 7 and will be updated 

later if necessary to reflect any changes made in RTM. 

Understanding DISM 

DISM.exe is a new command-line tool that is included both in a default install of the Windows 7 

operating system and also as part of version 2.0 of the Windows Automated Installation Kit (Windows 

AIK). 

Note: Support for VHD files as bootable Windows images is new in Windows 7 and is described in a 

later article of this series. 

You can use DISM.exe service Windows images, including both Windows image (WIM) files and 

virtual hard disk (VHD) files. While DISM.exe is primarily intended for servicing offline (not running) 

Windows images, some of its functionality can also be utilized to service online (running) Windows 

operating systems. By servicing an image we mean doing things like adding or removing device 

drivers, adding or removing operating system packages, adding hotfixes, configuring international 

settings, and performing similar types of actions on the image. DISM can also be used to upgrade a 

Windows image to a different edition (for example, to upgrade from Business to Ultimate) and to 

prepare a Windows PE image for use. 

You can use DISM.exe to service images of the following Windows versions: 

Windows Vista SP1 or later 








Using DISM 

In Windows Vista (or using the Windows AIK 1.1) servicing an image required using several different 

tools. For example, let us say you wanted to install an out-of-box device driver on an image you 

captured previously from a master installation. To do this in Vista, you had to: 

Mount the image using ImageX 

Add the device driver using Package Manager (Pkgmgr.exe) 

Unmount the image using ImageX 

In addition, if your image was a Windows PE image then you also need to use the Windows 

Preinstallation Environment (PEimg.exe) tool to prepare the image. And finally, if you needed to 

modify the language and locate settings of the image, you had to use the International Settings 

Configuration Tool (Intlcfg.exe). 

Beginning with Windows 7 however, DISM.exe now replaces the Pkgmgr.exe, Intlcfg.exe and 

PEimg.exe tools found in the earlier 1.1 version of the Windows AIK. In addition, DISM also includes 

functionality for mounting and unmounting images so you can service them. 

A typical use for DISM might be to add a device driver to an offline Windows image prior to deploying 

the image onto hardware that requires that driver. Let's walk through such a scenario to learn how to 

use DISM from the command-line. 

First, in the C:\Images folder on our Windows AIK 2.0 technician computer is a Windows install image 

(install.wim file) for Windows 7: 

C:\Program Files\Windows AIK\Tools\PETools>dir C:\Images 

Volume in drive C has no label. 

Volume Serial Number is 1C9A-D699 

Directory of C:\Images 

05/03/2009 12:46 PM . 

05/03/2009 12:46 PM .. 

04/22/2009 07:28 AM 2,218,242,699 install.wim 

1 File(s) 2,218,242,699 bytes 

2 Dir(s) 180,411,486,208 bytes free 

Note: 

Remember from article 17 of my Deploying Vista series that there are two types of 

Windows images: boot and install images :) 

Next, in the C:\Drivers folder are the Windows 7 beta drivers (version 2.91) for 

Microsoft LifeCam hardware: 

C:\Program Files\Windows AIK\Tools\PETools>dir C:\Drivers 



Directory of C:\Drivers 

05/03/2009 01:19 PM . 

05/03/2009 01:19 PM .. 

05/03/2009 01:19 PM VX6000 

0 File(s) 0 bytes 


We will be mounting our image to an empty folder named C:\Servicing. Let's begin by using the 

DISM.exe command with the /get-wiminfo parameter to display a list of all the Windows images 





contained in the install.wim file. Remember that an install image can contain more than one Windows 

image. 

C:\Program Files\Windows AIK\Tools\PETools>dism /get-wiminfo 

/wimfile:C:\Images\install.wim 

Deployment Image Servicing and Management tool 

Version: 6.1.7100.0 

Details for image : C:\Images\install.wim 

Index : 1 

Name : Windows 7 STARTER 

Description : Windows 7 STARTER 

Size : 7,927,317,234 bytes 

Index : 2 

Name : Windows 7 HOMEBASIC 

Description : Windows 7 HOMEBASIC 

Size : 7,983,232,406 bytes 

Index : 3 

Name : Windows 7 HOMEPREMIUM 

Description : Windows 7 HOMEPREMIUM 

Size : 8,422,988,972 bytes 

Index : 4 

Name : Windows 7 PROFESSIONAL 

Description : Windows 7 PROFESSIONAL 

Size : 8,303,245,818 bytes 

Index : 5 

Name : Windows 7 ULTIMATE 

Description : Windows 7 ULTIMATE 

Size : 8,461,373,562 bytes 

The operation completed successfully. 

Let us say that we are going to deploy Windows 7 Professional, in which case we can see from the 

above command output that the index number is 4 for this particular image. So, let us mount this 

particular Windows image to the empty C:\Servicing folder using the /mount-wim parameter of the 

DISM.exe command: 

C:\Program Files\Windows AIK\Tools\PETools>dism /mount-wim 

/wimfile:C:\Images\install.wim /index:4 /mountdir:C:\Servicing 


Version: 6.1.7100.0 

Mounting image 

[==========================100.0%==========================] 


To verify whether the image has been mounted successfully we can use the /get-mountedinfo 

parameter like this: 

C:\Program Files\Windows AIK\Tools\PETools>dism /get-mountedwiminfo 


Version: 6.1.7100.0 

Mounted images: 

Mount Dir : C:\Servicing 

Image File : C:\Images\install.wim 

Image Index : 4 

Mounted Read/Write : Yes 


Status : Ok 





If we examine the contents of the C:\Servicing directory, we can see the files and directories of our 

mounted image: 

C:\Program Files\Windows AIK\Tools\PETools>dir C:\Servicing 



Directory of C:\Servicing 

04/22/2009 03:36 AM . 

04/22/2009 03:36 AM .. 

03/20/2009 10:42 AM 24 autoexec.bat 

03/20/2009 10:42 AM 10 config.sys 

04/22/2009 01:17 AM PerfLogs 

04/22/2009 05:26 AM Program Files 

04/22/2009 03:27 AM Users 

04/22/2009 05:29 AM Windows 

2 File(s) 34 bytes 


Now let's view what kinds of servicing actions we can perform on our mounted image: 

C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /? 


Version: 6.1.7100.0 

Image Version: 6.1.7100.0 

The following commands may be used to service the image: 

WINDOWS EDITION SERVICING COMMANDS: 

/Set-ProductKey - Populates the product key into the offline image. 

/Get-TargetEditions - Displays a list of Windows editions that an image can 

be upgraded to. 

/Get-CurrentEdition - Displays the editions of the specified image. 

/Set-Edition - Upgrades the Windows image to a higher edition. 

UNATTEND SERVICING COMMANDS: 

/Apply-Unattend - Applies an unattend file to an image. 

DRIVER SERVICING COMMANDS: 

/Remove-Driver - Removes driver packages from an offline image. 

/Add-Driver - Adds driver packages to an offline image. 

/Get-DriverInfo - Displays information about a specific driver in an 

offline image or a running operating system. 

/Get-Drivers - Displays information about all drivers in an offline 

image or a running operating system. 

INTERNATIONAL SERVICING COMMANDS: 

/Set-LayeredDriver - Sets keyboard layered driver. 

/Set-UILang - Sets the default system UI language that is used in 

the mounted offline image. 

/Set-UILangFallback - Sets the fallback default language for the system UI 

in the mounted offline image. 

/Set-UserLocale - Sets the user locale in the mounted offline image. 





/Set-SysLocale - Sets the language for non-Unicode programs (also 

called system locale) and font settings in the mounted offline image. 

/Set-InputLocale - Sets the input locales and keyboard layouts to use in 

the mounted offline image. 

/Set-TimeZone - Sets the default time zone in the mounted offline image. 

/Set-AllIntl - Sets all international settings in the mounted offline image. 

/Set-SKUIntlDefaults - Sets all international settings to the default values 

for the specified SKU language in the mounted offline image. 

/Gen-LangIni - Generates a new lang.ini file. 

/Set-SetupUILang - Defines the default language that will be used by 

setup. 

/Get-Intl - Displays information about the international settings and languages. 

APPLICATION SERVICING COMMANDS: 

/Check-AppPatch - Displays information if the MSP patches are 

applicable to the mounted image. 

/Get-AppPatchInfo - Displays information about installed MSP patches. 

/Get-AppPatches - Displays information about all applied MSP patches for all 

installed applications. 

/Get-AppInfo - Displays information about a specific installed MSI application. 

/Get-Apps - Displays information about all installed MSI applications. 

PACKAGE SERVICING COMMANDS: 

/Add-Package - Adds packages to the image. 

/Remove-Package - Removes packages from the image. 

/Enable-Feature - Enables a specific feature in the image. 

/Disable-Feature - Disables a specific feature in the image. 

/Get-Packages - Displays information about all packages in the image. 

/Get-PackageInfo - Displays information about a specific package. 

/Get-Features - Displays information about all features in a package. 

/Get-FeatureInfo - Displays information about a specific feature. 

/Cleanup-Image - Performs cleanup and recovery operations on the image. 

For more information about these servicing commands and their arguments, specify a 

command immediately before /?. 

Examples: 

DISM.exe /Image:C:\test\offline /Apply-Unattend /? 

DISM.exe /Image:C:\test\offline /Get-Features /? 

DISM.exe /Online /Get-Drivers /? 

The parameters we want to use are found under DRIVER SERVICING COMMANDS above. Let's use 

the /get-drivers parameter to display a list of drivers already installed in the mounted image: 

C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /get-drivers 


Version: 6.1.7100.0 


Obtaining list of 3rd party drivers from the driver store... 

Driver packages listing: 

Published Name : oem0.inf 

Original File Name : prnms001.inf 

Inbox : No 

Class Name : Printer 

Provider Name : Microsoft 


Date : 6/21/2006 

Version : 6.1.7100.0 





Let us now use the /add-driver parameter to add our LifeCam driver to the mounted image: 

C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /add-driver 

/driver:C:\Drivers\VX6000\vx6000.inf 


Version: 6.1.7100.0 


Found 1 driver package(s) to install. 

Installing 1 of 1 - C:\Drivers\VX6000\vx6000.inf: The driver package was 

successfully installed. 


Let's use /get-drivers again to verify that the LifeCam driver has been successfully added to the 

mounted image: 

C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /get-drivers 


Version: 6.1.7100.0 


Obtaining list of 3rd party drivers from the driver store... 

Driver packages listing: 


Original File Name : prnms001.inf 

Inbox : No 

Class Name : Printer 


Date : 6/21/2006 

Version : 6.1.7100.0 


Original File Name : vx6000.inf 

Inbox : No 

Class Name : Image 


Date : 7/18/2008 

Version : 5.5.3.74 


We now finish servicing the image by unmounting it: 

C:\Program Files\Windows AIK\Tools\PETools>dism /unmount-wim 

/mountdir:C:\Servicing /commit 


Version: 6.1.7100.0 

Image File : C:\Images\install.wim 

Image Index : 4 

Saving image 

[==========================100.0%==========================] 

Unmounting image 

[==========================100.0%==========================] 







For more information on using DISM.exe, type dism /? in the Deployment Tools Command Prompt on 

your technician computer. You can also find detailed information concerning DISM.exe in the 

Deployment Tools Technical Reference section of the Windows Automated Installation Kit User's 

Guide (WAIK.chm) which can be accessed by clicking Start | All Programs | Microsoft Windows AIK 

on your technician computer. 

Finally, check out the free e-learning Clinic 10077: What's New in Windows 7 for IT Pros on the 

Windows 7 Learning Portal section of the Microsoft Learning web site. I was the one who developed 

the content for these three clinics, and the IT Pro clinic has a short video demonstration of using DISM 

to service an image by adding drivers to the image. 

Part 3: Understanding MAP 4.0 

The Microsoft Assessment and Planning Toolkit (MAP), allows organizations to assess their current IT 

infrastructure (hardware and software) in order to determine what Microsoft technologies can help 

them meet their business needs. MAP evolved from the earlier Windows Vista Hardware Assessment 

Solution Accelerator, which was designed to help organizations assess the readiness of their desktop 

computing infrastructure for the deployment of Windows Vista and Microsoft Office 2007. MAP is a 

Solution Accelerator, a set of automation tools and a form of guidance that helps accelerate the 

adoption of Microsoft technologies by helping organizations during the planning phase of desktop or 

server migration or consolidation. A complete list of available Solution Accelerators can be found here. 

The current version of MAP (version 3.2) allows organizations to: 

Perform secure agent-less network-wide hardware and software inventory of Windows computers 

and their devices by using WMI, SNMP, and other mechanisms. 

Perform comprehensive data analysis of hardware and device compatibility in order to determine 

readiness of migration systems for Windows Vista, Windows Server 2008, Microsoft Office 2007 

and Microsoft Application Virtualization and to assist in planning for consolidation of physical 

computers onto Hyper-V or Virtual Server 2005 R2. 

Generate in-depth readiness reports containing both summary and detailed assessment results for 

different migration scenarios that include recommendations for migration or server consolidation. 

The next version of MAP (version 4.0) will be released later this year and includes these new features: 

An improved, simpler user interface that makes it easier than ever to inventory your infrastructure, 

assess readiness for different scenarios, and generate reports and recommendations. 

Support for readiness assessment for Windows 7 and Windows Server 2008 R2. 

Expanded support for readiness assessment for different server consolidation scenarios. 

Improved experience to calculate Return on Investment (ROI) for server virtualization project by 

using MAP and the Integrated Virtualization ROI Tool. 





Support for OEM and Partner customization of the MAP user interface and migration proposal 

documents. 

The focus of this present series is on deploying Windows 7 and MAP 4.0 is a terrific tool to help you 

plan your desktop migration. Even so, MAP 4.0 can do far more than just assess whether your 

desktop computers can run Windows 7. Using MAP 4.0, you can: 

Perform a comprehensive inventory of PC hardware and software including SQL Server instances. 

Assess whether your servers are ready for migration to Windows Server 2008 R2. 

Discover server roles on your network. 

Find physical computers that are potential candidates for virtualization using Hyper-V. 

Discover VMware virtual machines for potential migration to Hyper-V. 

Assess possible candidates for App-V virtualization. 

Perform readiness assessments for Microsoft Forefront and implementing Network Access 

Protection (NAP). 

Estimate potential power savings when different power management settings are implemented on 

clients and servers. 

MAP 4.0 and Windows 7 Deployment 

MAP 4.0 is one of three key tools from Microsoft that organizations typically will need to use when 

preparing to migrate their desktops to Windows 7: 

1. MAP 4.0 – Use this tool first to assess the readiness of your environment to migrate your desktop 

computers to Windows 7. 

2. ACT 5.5 – Use the Application Compatibility Toolkit 5.5 next to test your existing applications for 

possible compatibility issues when running them on Windows 7 and for mitigating such issues by 

creating application shims for problem apps. 

3. MDT 2010 – Use the Microsoft Deployment Toolkit 2010 to deploy Windows 7 once you have 

assessed that your desktop computers are ready for Windows 7 and that your legacy line-ofbusiness 

(LoB) applications can be shimmed to run properly under Windows 7. 

A product manager on the MAP team told me that internally they like to refer to these tools as "The 

Three Musketeers". Personally, I like to refer to them as MAPACTMDT :) 

Installing MAP 4.0 

To obtain the beta version of MAP 4.0, you must join the MAP 4.0 beta program. Once you have 

downloaded MAP 4.0 you can install it on: 

Windows XP SP2 or later 

Windows Vista Ultimate, Enterprise or Business 

Windows 7 Professional, Enterprise or Business 


Windows Server 2003 SP1 or later 







There are versions of MAP for the x86 and x64 architectures. Before installing MAP 4.0 you must ensure 

that you have the following additional software installed: 

.NET Framework 3.5 SP1 

Windows Installer 4.5 

Microsoft Office Word 2007 or Microsoft Word 2003 SP2 

Microsoft Office Excel 2007 or Microsoft Excel 2003 SP2 

During installation of MAP 4.0, the setup will download and install SQL Server 2008 Express Edition 

on your computer. Once installation of MAP 4.0 is completed, you will be prompted to create an 

instance of a SQL Server 2008 Express database for storing the inventory information MAP acquires 

during the assessment process (see Figure 1): 

Figure 1: Creating a SQL Server 2008 Express database instance for use by MAP 

Examining MAP 4.0 

Once MAP 4.0 has been installed on a computer, you can launch the program from the Start menu. 

The MAP console displays a navigation pane on the left that has three buttons at the bottom: 

Inventory and Assessment, Surveys, and Reference Material. Selecting the Inventory and 

Assessment button displays a tree view of options you can choose from: 

Discovery and Readiness 

Server Consolidation 

Selecting the Discovery and Readiness option as shown in Figure 2 below lets you perform inventory 

and assess readiness for: 

Migrating client computers to Windows 7, Windows Vista or Office 2007. 





Discovering server roles and SQL Server instances, and migrating servers to Windows Server 

2008 or Windows Server 2008 R2. 

Discovering virtual machines present on your network. 

Figure 2: The Discovery and Readiness option under Inventory and Assessment 

Selecting the Server Consolidation option as shown in Figure 3 below lets you perform the following 

server consolidation tasks: 

Inventory your server environment for physical servers that can be consolidated as virtual 

machines on Hyper-V. 

Gather performance metrics for server consolidation. 

Configure host machine equivalents and make recommendations concerning placement of guest 

machines. 

Calculate the potential return on investment (ROI) your organization can achieve through 

implementing a Microsoft integrated virtualization solution. 





Figure 3: The Server Consolidation option under Inventory and Assessment 

Selecting the Survey button in the bottom portion of the navigation pane allows you to: 

Use an online survey to evaluate the migration of your existing messaging infrastructure to the 

Microsoft Exchange Hosted Services available from Microsoft Online Services (click here for more 

information). 

Download the Infrastructure Planning and Design (IPD) assessment guide and scenario selection 

tool for Windows Optimized Desktop Scenarios, which you can use to evaluate the implementation 

of different Microsoft desktop virtualization technologies that could provide extra benefits to your 

desktop users, including rich and thin client solutions such as Windows Vista, App-V, VDI and 

more. 





Figure 4: The Surveys option provides links to an online survey and a Solution Accelerator 

you can download 

The final button (Reference Material) found at the bottom of the navigation pane takes you to a page 

that has links to other useful planning and assessment tools available from Microsoft. It will also direct 

you to various documentation pages on Microsoft TechNet that can help you during the planning 

phases (Figure 5): 

Figure 5: Links to additional reference material are available from within the MAP 





Conclusion 

In this article we have looked at what MAP 4.0 is and what it can be used for. We also examined the 

installation requirements and provided a brief overview of the MAP 4.0 console. In the next article of 

this series, I will help you set up a Windows 7 Readiness assessment. For more information about 

MAP and to obtain the latest version of the toolkit, click here. 

Part 4: Using MAP 4.0 

Preparing to Run the Windows 7 Readiness Assessment 

Before you use MAP to assess the readiness of your desktop computers for a migration to Windows 7, 

you need to make sure they can be assessed. The great thing about MAP is that it is agent less, 

which means that you do not need to deploy a software agent to each desktop machine that you want 

to assess. Instead of using agents, MAP uses Windows Management Instrumentation (WMI) to collect 

hardware devices and software information from the computers on your network. In order for WMI to 

be able to do this, your desktop computers must be configured to allow remote WMI queries. This 

means that you have to enable the Remote Administration and the File & Printer Sharing exceptions 

in Windows Firewall on all your desktop computers. You can use Group Policy to enable Windows 

Firewall exceptions in an Active Directory-based network (in a workgroup you have to do this 

manually on each computer). Also, in a domain environment, you need to run MAP on a computer on 

which you have logged on as a member of the Domain Admins security group (in a workgroup 

environment you need to provide MAP with local Administrator credentials for each computer). 

Additional configuration steps may need to be performed in order to prepare your desktop computers 

for assessment by MAP. For more information, see the Getting Started Guide for MAP 4.0, which is 

available from Start | All Programs | Microsoft Assessment and Planning Toolkit. Be sure also to 

review the MAP FAQ before using MAP. 

Performing a Windows 7 Readiness Assessment 

To perform your Windows 7 Readiness assessment, open the MAP console, select the Inventory and 

Assessment button at the bottom portion of the navigation pane, expand Discover and Readiness in 

the top portion of the navigation pane, and select Windows 7 Readiness (Figure 1): 

Figure 1: Running a Windows 7 Readiness assessment using MAP 4.0 





Click the Inventory and Assessment Wizard link in the right pane to launch the Inventory and 

Assessment Wizard. On the first page of this wizard you can specify which method(s) you would like 

to use in order to locate the computers on your network (Figure 2). The supported methods in MAP 

4.0 include: 

Querying Active Directory for computer accounts in domains or OUs you specify 

Using Win32 LAN Manager APIs to query the Computer Browser service to find computers 

belonging to workgroups 

Importing a list of computer names (NetBIOS or FQDNs) from a text file 

Scanning a specified IP address range for computers 

Manually specifying computer names (NetBIOS or FQDNs) if you only have a few computers to 

assess 

Discover Windows virtual machines running on VMware servers 

By default, Active Directory and Windows network protocols are used, but to keep things simple in this 

example, we will clear the second option and only query Active Directory. 

Note: Selecting different options on this page may result in additional wizard pages being displayed 

later on. 

Figure 2: Choosing which methods to use to discover computers on your network 





On the next page of the wizard we specify the Domain Admin credentials MAP can use to query 

Active Directory (Figure 3): 

Figure 3: Specify Domain Admin credentials for MAP to query Active Directory 

On the next wizard page, we will specify that MAP should only query for computer accounts in the 

Seattle Computers OU since those will be the computers we will pilot Windows 7 on (Figure 4): 

Figure 4: Specify the domain and organizational units where the computers reside 





The next wizard page asks us for credentials MAP can use to remotely connect to each computer 

using WMI (Figure 5): 

Figure 5: MAP needs credentials to remotely connect to computers using WMI 

Clicking New Account opens the Inventory Account dialog box (Figure 6). Specify a Domain Admin 

account for the inventory account: 

Figure 6: Specify a Domain Admin account for WMI connections to remote computers 





Clicking Save adds the specified account to the WMI Credentials page of the wizard (Figure 7): 

Figure 7: Credentials for remote WMI connections have been specified 

The final page of the wizard summarizes the choices you have made (Figure 8): 

Figure 8: Summary page of wizard 





Clicking Finish starts the inventory process and displays a Status dialog box (Figure 9): 

Figure 9: Status of the inventory process is displayed 

Once the assessment is finished, click Close. After a few moments MAP will display the results of the 

assessment. Figure 10 shows that two client computers were found in the specified OU and that both 

of them were ready for Windows 7: 

Figure 10: Summary results of the Windows 7 Readiness assessment 





Scrolling down the middle pane of MAP shows additional details of the assessment. For instance, we 

can see in Figure 11 that there are a few device incompatibility issues that we will need to resolve with 

device manufacturers before we migrate the computers to Windows 7. 

Figure 11: Note that 6% of the devices on the assessed computers may be incompatible with Windows 7 

Changing the Hardware Requirements 

Let us examine what hardware requirements were used during the above assessment as a basis for 

determining whether our computers are ready for Windows 7. In the Actions pane at the right side of 

the above figure, click Set Assessment Properties to open the Assessment Properties dialog box 

(Figure 12): 

Figure 12: Default hardware values used by MAP for assessing Windows 7 readiness 





By default, MAP uses the following minimum hardware requirements for Windows 7 readiness (these 

values are preliminary and are subject to change at RTM): 

CPU minimum speed 1.0 GHz 

Minimum free disk space 20 GB for x64 systems and 16 GB for x86 systems 

Minimum RAM of 2 GB for x64 systems and 1 GB for x86 systems 

What if these hardware requirements are not sufficient for the needs of our business? For example, 

since we plan on using our two computers in Seattle for some fairly intensive work, such as video 

processing, let us increase these minimum requirements and see if our computers will still be ready 

for Windows 7. To do this, select Use Custom Settings and specify the new requirements shown in 

Figure 13: 

Figure 13: Specifying more stringent hardware requirements for Windows 7 

Now click Run Assessment to re-run the Windows 7 Readiness assessment using these more 

stringent hardware requirements (Figure 14): 

Figure 14: Re-running the assessment 





Generating Proposals and Reports 

We have now run two assessments that basically answer the following two questions: 

How many computers at Seattle are ready for Windows 7? 

Will these computers still be ready for Windows 7 given our more stringent hardware 

requirements? 

Let us generate reports we can share and review with our IT team and later with management. To 

generate reports, click Generate Report/Proposal in the Action pane at the right of Figure 11 shown 

previously. When you do this, MAP generates a proposal (Word doc) and an Excel workbook 

containing various reports (Figure 15): 

Figure 15: Reports and proposals are being generated 

Let us look at the Excel workbook first as it contains the detailed information our IT staff will need to 

review. To find our proposals and reports, select View | Saved Reports and Proposals to open the 

folder where the proposals and reports are found (Figure 16): 

Figure 16: Proposals and Reports generated by MAP 





We will open the Excel workbook and look at each worksheet. The first worksheet provides a 

summary of Windows 7 readiness information for computers that are already running a Microsoft 

Windows client (Figure 17): 

Figure 17: Windows 7 Assessment Summary for Client Computers worksheet 

The next worksheet shows the system requirements provided by Microsoft in addition to any 

recommended settings that were used in the assessment (Figure 18): 

Figure 18: System Requirements Used in the Assessment worksheet 





The next worksheet provides a summary of Windows 7 readiness information for computers that are 

already running a Microsoft Windows client operating system. For rows that report "Insufficient Data" 

refer to the WMI Status column for more information about why inventory data could not be collected 

(Figure 19): 

Figure 19: Windows 7 Assessment Results for Client Computers worksheet 

The next worksheet is a summary of the hardware devices found on the computers. It identifies 

whether a driver is available on the Windows 7 DVD, from Windows Update, or if you need to contact 

the hardware manufacturer to identify if a driver is available for Windows 7. This summary worksheet 

has a row for each discovered device and provides the number of computers where the device was 

found. To identify the specific devices on each computer, refer to the Device Inventory Details 

Worksheet (Figure 20): 

Figure 20: Device Assessment Summary worksheet 





The next worksheet describes the hardware devices discovered on each specific computer. It 

identifies whether a driver is available on the Windows 7 DVD, from Windows Update, or if you need 

to contact the hardware manufacturer to identify if a driver is available for Windows 7 (Figure 21): 

Figure 21: Device Assessment Details worksheet 

The next worksheet describes computers that are not currently able to run Windows 7 and the 

hardware upgrades required for them to meet the minimum system requirements for Windows 7 

(Figure 22): 

Figure 22: Windows 7 Minimum Ready Computers After Hardware Upgrades worksheet 





The next worksheet describes computers that are not currently able to run Windows 7 or meet the 

minimum system requirements. It provides the hardware upgrades required for the computers to be 

ready for Windows 7 using the recommended hardware requirements selected for this assessment 

(Figure 23): 

Figure 23: Windows 7 Recommended Ready Computers After Hardware Upgrades worksheet 

The eighth and final worksheet describes up to 60,000 applications discovered through the inventory 

process on client machines and provides a count of the number of times a particular version of the 

software was found. The data in this sheet is based solely upon computers where a successful 

inventory was performed (Figure 24): 

Figure 24: Discovered Applications worksheet 





Finally, let us examine the Word doc generated by MAP, which summarizes the results of our 

Windows 7 Readiness assessment (Figure 25): 

Figure 25: MAP generates a proposal you can present to management 

As you can see from the outline on the left, this document contains both the results of your 

assessment and also some additional information concerning the benefits of deploying Windows 7 

Enterprise edition in your organization. You can use this document as the basis for the proposal you 

will present to management. Lastly, MAP 4.0 will give you the ability to insert your own text and logos 

within the Word template, allowing users such as consultants to customize the outputs with their own 

“branding” in future scans. 

Conclusion 

MAP 4.0 is a powerful tool for assessing whether your desktop infrastructure is ready to migrate to 

Windows 7. There are other capabilities in MAP 4.0 that can help you plan a server migration and 

consolidation. We will examine these capabilities in a future article on this site. For more information 

about MAP and to download the latest released version, click here. You can also join the MAP 4.0 

beta program on Microsoft Connect here. 

Part 5: MDT 2010 Enhancements 

Introduction 

My previous series of articles titled Deploying Vista described how to deploy Windows Vista SP1 

Enterprise edition using Microsoft Deployment Toolkit (MDT) 2008 Update 1 together with the 





Windows Automated Installation Kit (Windows AIK) version 1.1. This present series of articles about 

deploying Windows 7 will now continue by focusing on how to deploy Windows 7 Enterprise edition 

using MDT 2010 and the Windows AIK 2.0. Later on we will also examine how to bring Windows 

Deployment Services in Windows Server 2008 R2 into the mix of things, and afterwards we will look 

at how to use MDT 2010 together with Microsoft System Center Configuration Manager 2007 SP2. 

But first let us get the basics of using MDT 2010 under our belt. 

In article 24 of my previous series Deploying Vista you learned about: 

The history of Microsoft deployment solution accelerators 

The difference between Light-Touch Installation (LTI) and Zero-Touch Installation (ZTI) 

deployments 

Four possible deployment scenarios: new computer, refresh computer, replace computer, and 

upgrade computer 

How to install MDT 2008 

The Deployment Workbench 

If you have forgotten any of this, you may want to review the earlier article before proceeding further. 

MDT 2010 Enhancements 

MDT 2010 is the next version of MDT and has a lot of changes over the previous version MDT 2008 

Update 1. Let us examine some of these changes now. 

First of all, you can now deploy Windows 7 and Windows Server 2008 R2. The previous version of 

MDT (MDT 2008 Update 1) cannot deploy Windows 7—you must use MDT 2010 to do this. 

Specifically, you can use MDT 2010 to deploy the following Windows operating systems: 

Client OSes: Windows 7, Windows Vista SP1+ and Windows XP SP3. 

Server OSes: Windows Server 2008 R2, Windows Server 2008 and Windows Server 2003 R2. 

In MDT 2008 Update 1 you had to create and configure distribution shares and deployment points. 

You may recall that a distribution share was the folder that contained the source files for an operating 

system such as Windows Vista that you planned on deploying using MDT 2008 Update 1. The 

distribution share also contained any packages, drivers, or applications you wanted to include in your 

install. A deployment point on the other hand was a folder that contained all the files needed to deploy 

your Vista image together with any drivers, packages and applications needed for the install. A big 

change in MDT 2010 is that these two things (distribution shares and deployment points) are now 

combined into a single thing called a deployment share. This change simplifies the process of 

preparing and using your MDT-based deployment infrastructure. 

Here are some additional enhancements concerning deployment shares: 

Deployment shares can be hosted on local drives, network shares, or in a standalone DFS 

namespace 

Multiple deployment shares can be opened at the same time in the Deployment Workbench 





Deployment shares can be managed from any machine where the Deployment Workbench is 

installed—provided the NTFS and shared folder permissions are appropriate on the share 

Deployment shares can be linked so that when the content of one share is updated the content in 

the other share is also updated 

Another big change in this version of MDT is that the underlying scripting logic has been migrated 

from VBScript to Windows PowerShell. In other words, most of the tasks you perform using the 

Deployment Workbench are actually accomplished using Windows PowerShell commands. In addition, 

you can use Windows PowerShell commands directly to perform various MDT configuration and 

management tasks and automate them, something that was difficult to do in previous versions of MDT 

as it required editing complex scripts. In other words, anything you can do using the Deployment 

Workbench can now also be done using Windows PowerShell commands and scripts. See this post 

on Michael Niehaus's blog for a quick look at some of the powerful new capabilities added to MDT 

2010 using Windows PowerShell. 

The Deployment Workbench, which is the integrated workspace from which you can perform all of 

your deployment-related tasks, has also been enhanced in MDT 2010. For example, you can now 

create a hierarchical tree of folders in each deployment share in order to help you organize items such 

as operating systems, device drivers, and task sequences for that share. Plus you can cut/copy/paste 

and drag/drop items within these folder trees. And you can use selection profiles to manage groups of 

similar items (such as device drivers for a specific type of machine) as a single item. These changes 

all make it easier than ever to manage your deployment resources and tasks. 

Finally, there are a number of other enhancements in MDT 2010 relating to security, stability and 

performance. For example, you can now refresh a computer that has a volume protected by Windows 

BitLocker Drive Encryption without having to decrypt and re-encrypt the protected volume. This makes 

this particular refresh scenario more secure and much faster than before. There's lots more added in 

MDT 2010—see Michael Niehaus's blog for a series of articles examining in detail some of the 

exciting new features found in this new version of MDT. 

Installing MDT 2010 

You can install MDT 2010 on x86 or x64 systems running the following operating systems: 

Windows Server 2008 or Windows Server 2008 R2 

Windows 7 or Windows Vista SP1 

Windows Server 2003 SP2 (requires .NET Framework 2.0 and MSXML 6.0) 

Before you install MDT 2010 make sure you have installed the Windows AIK 2.0 on your technician 

computer. You can download both the Windows AIK 2.0 and MDT 2010 from the Microsoft Download 

Center. MDT 2010 is available in two forms: 

MicrosoftDeploymentToolkit_x64.msi 

MicrosoftDeploymentToolkit_x86.msi 

I recommend you install the 64-bit version of MDT 2010 on a 64-bit system such as an x64 version of 

Windows Server 2008 R2. Double-clicking on the Windows installer package launches the setup 

process (Figure 1): 





Figure 1: Installing MDT 2010 on a technician computer 

You should generally perform a complete install (Figure 2): 

Figure 2: Installing all components of MDT 2010 





Examining the Deployment Workbench 

Once you have installed MDT 2010 you can launch the Deployment Workbench (Figure 3): 

Figure 3: The re-vamped Deployment Workbench in MDT 2010 

If you compare Figure 3 above with Figure 3 from article 24 of my Deploying Vista series, you can see 

some obvious differences. Specifically, the old Deployment Workbench had four main subnodes on 

the left: 

Information Center 

Distribution Share 

Task Sequences 

Deploy 

The new one still has the Information Center node, but the other three have now been combined into 

a single Deployment Shares node. We will learn how to create a deployment share in the next article 

of this series. 

Upgrading to MDT 2010 

You can also upgrade to MDT 2010 from the following earlier Microsoft deployment solution 

accelerators: 

MDT 2008 Update 1 

BDD 2007 Update 2 





For information on upgrading to MDT 2010, see the Microsoft Deployment Toolkit Documentation 

Library, a Windows Help (.chm) file installed when you install MDT 2010 on a system. 

Conclusion 

In this article we have examined the new features of MDT 2010 and how to install MDT 2010 on a 

technician computer. In the next article of this series we will examine how to prepare MDT 2010 for 

deploying Windows 7 Enterprise edition using LTI. 

Part 6: Lite Touch using MDT 2010 

Introduction 

In the previous article of this series we examined the new features of MDT 2010, the latest version of 

Microsoft Deployment Toolkit. We also looked at how to install MDT 2010 and examined the basic 

layout of the updated Deployment Workbench. In this article we will examine how to manually perform 

a basic Lite Touch Installation (LTI) deployment of Windows 7 Enterprise using MDT 2010. The tasks 

we are going to perform include: 

Preparing the environment 

Creating a deployment share 

Configuring the deployment share 

Creating a task sequence 

Updating the deployment share 

Performing the install 

Before you continue reading, you may want to refer back to the following two articles from my 

previous series Deploying Vista: 

Part 25: Preparing Microsoft Deployment Toolkit for Deploying Vista 

Part 26: Deploying Vista Using Microsoft Deployment 

Preparing the Environment 

To follow along through this walkthrough, make sure you have the following environment (or 

something similar) set up: 

Domain controller for the contoso.com domain. 

DHCP server with a scope configured for leasing addresses to client computers. 

Technician computer with MDT 2010 and Windows AIK 2.0 installed. 

In my own test environment, one computer running Windows Server 2008 R2 Enterprise x64 fulfills all 

of these roles. 

Creating a Deployment Share 

Open the Deployment Workbench on your technician computer, then right-click on the Deployment 

Shares node and select New Deployment Share. The New Deployment Share wizard starts. Click the 

Browse button and create a folder named DeploymentShare$ in the root of your disk volume as 

shown in Figure 1: 





Figure 1: Specify the name and path to the deployment share folder 

Click Next and the share name will automatically be populated and the UNC path to the share will be 

displayed (Figure 2): 

Figure 2: The share name and UNC path for the deployment share are displayed 





Click Next and give your deployment share a descriptive name (Figure 3): 

Figure 3: Name the deployment share 

Click Next and choose whether you want to be able to capture an image after deploying it to a 

computer (Figure 4). We will leave this option enabled so we can use it if we deploy a reference 

(master) computer and capture its image for deployment onto multiple target (end-user) computers: 

Figure 4: Specify whether the option to capture an image will be displayed when the Windows 

Deployment Wizard runs during an install 





Click Next and specify whether the user should be allowed to set the password for the local 

Administrator account on their computer (Figure 5). We'll leave this option unchecked: 

Figure 5: The Allow Admin Password option 

Click Next and specify whether the user should be asked to enter a product key (Figure 6). We will 

leave this unchecked because we are deploying Windows 7 Enterprise, which means that activation is 

typically performed using Key Management Service (KMS): 

Figure 6: Choose whether the user is prompted to enter a product key during the install 





Now finish the wizard and review the Confirmation page to ensure everything was done as expected. 

Figure 7 shows the newly created deployment share and its folder structure in the Deployment 

Workbench: 

Figure 7: The newly created deployment share 

Configuring the Deployment Share 

Once you have created your deployment share, you need to configure it as follows: 

Add the operating system you wish to deploy 

Add any out-of-box device drivers needed for installing the operating system on the target 

computers 

Add any applications you want to install on the target computers during the install 

Add any packages such as hotfixes or security updates you want to install on the target computers 

during the install 

For simplicity we are only going to add an operating system (Windows 7 Enterprise) to the 

deployment share. In future articles we will examine how to add drivers, packages and applications to 

deployment shares. 





To add an operating system, right-click on the Operating Systems node in the deployment share and 

select Import Operating System. This starts the Import Operating System Wizard. On the first page of 

the wizard, specify that you want to import a full set of source files (Figure 8): 

Figure 8: Importing a full set of Windows 7 operating system files into the deployment share 

Insert your Windows 7 Enterprise product media into the DVD drive of your technician computer and 

browse to select the DVD (Figure 9): 

Figure 9: Importing the OS source files from the product DVD 





Click Next and the wizard skips ahead to the Destination page (Figure 10). Specify a descriptive name 

for the folder where the source files will be imported to on your technician computer (note that I have 

imported the x86 version of the OS in this example): 

Figure 10: Specify the name of the folder where the OS source files will be imported to 

Finish the wizard. The import process may take several minutes to complete. Once it is done and you 

select the Operating Systems folder in your deployment share, the imported OS is displayed (Figure 

11). 

Figure 11: Windows 7 Enterprise source files have been imported into the deployment share 





At this point you would add out-of-box drivers, packages and applications to your deployment share 

as needed. 

Creating a Task Sequence 

Now let us create a task sequence. A task sequence is a series of steps that are performed during 

deployment. We want to create a task sequence that will install Windows 7 Enterprise onto a baremetal 

target computer. To do this, right-click on the Task Sequences folder in your deployment share 

and select New Task Sequence. This launches the New Task Sequence Wizard. On the first page of 

the wizard, specify a task sequence ID (no spaces), task sequence name, and comments as desired 

(Figure 12): 

Figure 12: Creating a new task sequence for deploying Windows 7 

Click Next and select Standard Client Task Sequence from the list of available task sequence 

templates (Figure 13): 

Figure 13: Base the new task sequence on the Standard Client template 





Click Next and select Windows 7 Enterprise, which is the only imported OS at this point (Figure 14): 

Figure 14: Select an operating system to deploy using the task sequence 

Click Next and select the option to not specify a product key in the task sequence (Figure 15): 

Figure 15: Do not specify a product key in the task sequence when deploying volume-licensed 

media and using KMS activation 





Click Next and specify the name of the user who will be using the computer and your organization 

name and website/internet (Figure 16): 

Figure 16: The OS Settings wizard page 

Click Next and specify a password for the local Administrator account on the target computer (Figure 

17): 

Figure 17: Specify a password for the local Administrator account on the user's computer 





Finish the wizard. The new task sequence is displayed in the Task Sequences folder of your 

deployment point (Figure 18): 

Figure 18: The new task sequence is displayed in the Deployment Workbench 

Updating the Deployment Share 

Now we need to update our deployment share. Updating a deployment share does several things, 

one of which being the creation of customized version of the Windows Preinstallation Environment 

(Windows PE) that can be used to deploy the operating system using the task sequence. Specifically, 

updating the deployment share in this example creates the following Windows PE images in the 

C:\DeploymentShare$\Boot folder on your technician computer: 

LiteTouchPE_x64.iso – Used to manually deploy Windows 7 Enterprise x64 onto a bare-metal 

system. 

LiteTouchPE_x64.wim – Used to deploy Windows 7 Enterprise x64 onto a bare-metal system 

using Windows Deployment Services. 

LiteTouchPE_x86.iso – Used to manually deploy Windows 7 Enterprise x86 onto a bare-metal 

system. 

LiteTouchPE_x86.wim – Used to deploy Windows 7 Enterprise x86 onto a bare-metal system 

using Windows Deployment Services. 





To update your deployment share, right-click on it and select Update Deployment Share. This 

launches the Update Deployment Share Wizard (Figure 19): 

Figure 19: Updating the deployment share 

Leave the default options selected and finish the wizard. It may take some time to create the Windows 

PE images on your technician computer. Once the wizard finishes, burn the LiteTouchPE_x86.iso file 

onto a CD as you will need it to deploy Windows 7 Enterprise x86 onto your target computer. 

Note: As shown in Figure 20, on the Confirmation page of this wizard (and on all MDT 2010 wizards) 

there are two buttons: 

Save Output – saves the output of the wizard to a text file (actually it's better to save it as .rtf as it's 

more readable that way). 

View Script – displays the underlying Windows PowerShell commands that are executed by the 

wizard. 

As an example of the second, the View Script output from the Update Deployment Share Wizard 

looks like this: 





Add-PSSnapIn Microsoft.BDD.PSSnapIn New-PSDrive -Name "DS001" -PSProvider 

MDTProvider -Root "C:\DeploymentShare$" update-MDTDeploymentShare -path "DS001:" - 

Verbose 

Figure 20: Confirmation page of the wizard 

Performing the Install 

At this point, you are ready to deploy Windows 7 using MDT. Turn on your bare-metal (i.e. no OS 

installed) target computer and put your customized Windows PE CD into the CD drive on the 

computer. After a short time the Windows Deployment Wizard will start and you can follow the 

prompts almost exactly as shown in my earlier article Deploying Vista Part 26: Deploying Vista Using 

Microsoft Deployment Toolkit. The differences between what you will see when you do this using MDT 

2010 and what this earlier article shows for MDT 2008 are basically only cosmetic in nature. 

Part 7: Automated LTI Deployment 

Introduction 

In the previous article of this series we learned how to manually perform a basic Lite Touch 

Installation (LTI) deployment of Windows 7 Enterprise using MDT 2010. In this article we will learn 

how to complete and automate this process. 

Automating LTI deployment of Windows 7 using MDT 2010 involves the following steps: 

1. Create a deployment share using the Deployment Workbench. 


2. Import Windows 7 source files into the share. 




3. Add packages, drivers, and applications to your share as needed. 

4. Create a basic task sequence based on the Standard Client Task Sequence template. 

5. Edit the CustomSettings.ini and BootStrap.ini configuration files as needed to automate the LTI 

deployment process. 

6. Update the deployment share to create Windows PE boot images (.iso and .wim files) and burn 

the .iso file to CD or DVD media. 

7. Boot the destination computer using the Windows PE boot image and let the install proceed 

entirely unattended. 

We have already performed steps 1-4 in the previous article of this series, so all we need to do here is 

perform steps 5-7, so here goes. 

Editing the Configuration Files 

As in the previous version MDT 2008 Update , MDT 2010 uses configuration files to control the LTI 

deployment process. These configuration files provide input for the scripts that MDT uses to perform 

the install. There are two configuration files you must edit to perform a fully automated LTI 

deployment: CustomSettings.ini and BootStrap.ini. We have briefly examined these two files in Part 

27 of my Deploying Vista series. Let us review what these files are for and dig into them a bit deeper 

this time. 

To begin with, let us examine the default CustomSettings.ini file that MDT creates for the deployment 

share we created in the previous article. To view the contents of CustomSettings.ini, we will open the 

Deployment Workbench, right-click on the deployment share and select Properties, then select the 

Rules tab as shown in Figure 1: 

Figure 1: The default CustomSettings.ini file for a new deployment share 





Notice that this default CustomSettings.ini file does not contain any information concerning which 

operating system image is to be deployed, which task sequence will be used, and so on. If this is the 

CustomSettings.ini file then information like that will need to be supplied during deployment, that is, by 

sitting at the destination computer and responding to the prompts of the Windows Deployment Wizard 

(see Part 26 of my Deploying Vista series for examples of such wizard prompts). Of course, that is not 

what we want to do—we want to automate the install. 

Let us also examine the default BootStrap.ini file for our new deployment share, which is shown in 

Figure 2: 

Figure 2: The default BootStrap.ini file for a new deployment share 

Notice that this default BootStrap.ini file contains information about the network location of the 

deployment share, but it does not contain information concerning the credentials to be used in order 

to connect to this share. This is why one of the first things you are prompted to supply when you 

perform a manual LTI deployment is the credentials that the Windows Deployment Wizard will use to 

connect to the share. And of course, we do not want to have to supply this prompt or any prompt 

during installation—we want to fully automate the LTI deployment. 

To do this, we need to make some changes to these two configuration files. But before we do this we 

need to ask ourselves some questions, such as: 

What time zone do we want to configure for the destination computer? 

What locale do we want to configure? 

Do we want to specify a computer name or let one be randomly assigned during installation? 

Do we want to join the computer to a domain or leave it in a workgroup? 

And so on. 





The answers you provide for these questions and other questions will determine what property/value 

pairs you include in your CustomSettings.ini file. As an example of how to perform a fully automated 

LTI deployment, let's change the default CustomSettings.ini to the following: 

[Settings] 

Priority=Default 

Properties=MyCustomProperty 

[Default] 

OSInstall=YES 

SkipAdminPassword=YES 

SkipApplications=YES 

SkipAppsOnUpgrade=YES 

SkipBDDWelcome=YES 

SkipBitLocker=YES 

SkipCapture=YES 

SkipComputerName=YES 

SkipComputerBackup=YES 

SkipDeploymentType=YES 

DeploymentType=NEWCOMPUTER 

SkipDomainMembership=YES 

JoinDomain=CONTOSO 

DomainAdmin=Administrator 

DomainAdminDomain=CONTOSO 

DomainAdminPassword=Pa$$w0rd 

SkipFinalSummary=YES 

SkipLocaleSelection=YES 

KeyboardLocale=en-US 

UserLocale=en-US 

UILanguage=en-US 

SkipPackageDisplay=YES 

SkipProductKey=YES 

SkipSummary=YES 

SkipTaskSequence=YES 

TaskSequenceID=WIN7_001 

SkipTimeZone=YES 

TimeZoneName=Central Standard Time 

SkipUserData=Yes 

Note: The blank lines in the listing above are there only to make the contents of the file more readable, 

and they can be omitted if desired. 

Figure 3 shows what this looks like after we have copied and pasted this into the Rules tab: 





Figure 3: Example of a CustomSettings.ini file for a fully automated LTI deployment 

We will also need to make changes to the default BootStrap.ini file in order to automate our 

deployment. Figure 4 shows what our new BootStrap.ini file will need to look like: 

Figure 4: Example of a BootStrap.ini file for a fully automated LTI deployment 





In the next article we will examine these two edited files line by line to understand them. But for now, if 

you have completed the walkthrough in the previous article, just make the changes indicated to these 

two files and save them. Then complete the steps in the two sections that follow. 

Updating the Deployment Share 

Updating a deployment share creates Windows PE boot images we can use for initiating deployment. 

We learned how to update a deployment share in the previous article of this series. In fact, we 

updated our deployment share in the previous article, so why do we have to update it again? Because 

we made changes to the BootStrap.ini file. Any time you make a change to your BootStrap.ini file, you 

must update your deployment share. So if you're following along, update your deployment share now, 

then burn the LiteTouchPE_x86.iso file to CD-R/W media using third-party CD/DVD-burning software. 

Launching the Unattended Install 

Now turn on your bare-metal (no OS or partitions) destination computer, making sure it is connected 

to the network where your MDT computer resides. Insert the Windows PE CD you burned in the 

previous step, and sit back and watch. Windows PE will boot and display a blue screen with a 

Solution Accelerators banner across the bottom. Behind the scenes, Windows PE will establish a 

connection to your deployment share using the credentials provided in your BootStrap.ini file. Once 

this connection has been established, the installation will begin and an Installation Progress dialog 

box will be displayed. Your computer will reboot several times until finally, without the need of you 

supplying any further keystrokes, the Windows 7 desktop will appear and your install will be finished. 

Conclusion 

This article walked you through the steps for performing a fully automated LTI deployment using MDT 

2010. The next article in this series will dig deeper into the CustomSettings.ini and BootStrap.ini 

property/value pairs you can use for automating LTI deployment. 

Part 8: Understanding LTI Configuration Files 

In the previous article of this series we learned how to modify the CustomSettings.ini and 

BootStrap.ini files of MDT 2010 in order to fully automate a Lite Touch Installation (LTI) of Windows 7 

Enterprise. In this article we will dig deeper into modifying these two files to control the LTI process. 

Understanding BootStrap.ini 

BootStrap.ini is one of two configuration files used by MDT for controlling the deployment process (the 

other configuration file is CustomSettings.ini). Both of these files are located in the Control folder of 

the deployment share. This means that these files are specific to the deployment share. In other 

words, if you have more than one deployment share, each share will have its own configuration files 

for controlling deployments made using that share. 

BootStrap.ini is used during the initial connection process when the destination computer, booted 

using the LiteTouch Windows PE image, connects to the deployment share to begin the installation 

process. This means that BootStrap.ini must contain any information needed to successfully establish 

a connection between the destination computer and the deployment share. 

The BootStrap.ini file used in the previous article of this series looked like this: 

[Settings] 



[Default] 

DeployRoot=\\SEA-DC1\DeploymentShare$ 

UserID=Administrator 

UserDomain=CONTOSO 

UserPassword=Pa$$w0rd 






You can see that BootStrap.ini consists of two sections: Settings and Default. The Settings section is 

required and contains only one property called Priority. This property tells MDT the order in which to 

parse the remaining sections of the configuration file. Since there is only one remaining section 

(Default) that is the value assigned to Priority. 

The Default section is where the work gets done. Specifically: 

The DeployRoot property specifies the UNC path to the deployment share that will be used for the 

install. This is required information. 

The UserID, UserDomain and UserPassword specify the credentials that the destination computer 

running Windows PE will used to connect to the deployment share. This is required information. In 

the sample BootStrap.ini file above, the domain Administrator account is used. For security 

reasons, in a real-world environment you would not use this account. Instead, you should create a 

new user account used solely for deployment purposes (no one should log on to a computer using 

this account). For example, you could create a domain account named MDT for this purpose. 

Because of the NTFS and shared folder permissions assigned to the deployment share, the MDT 

account only needs to be a member of the Domain Users group—it doesn't need to be a member 

of the Domain Admins group. Note that the password for this account is stored in unencrypted 

form in the BootStrap.ini file. 

The KeyboardLocale property specifies the locale for the keyboard attached to the destination 

computer. The keyboard locale can be specified either in text (for example, en-us) or hexadecimal 

(for example, 0409:00004009) form. You can specify multiple values by separating them with 

semicolons. If this property is omitted from BootStrap.ini, the Windows Deployment Wizard will 

use the keyboard locale configured in the image being deployed. 

SkipBDDWelcome = YES prevents the opening screen ("Welcome Windows Deployment") of the 

Windows Deployment Wizard from being displayed. This is required if you want to fully automate 

LTI. 

The above six properties are the only properties that can be included in BootStrap.ini. 

Remember—if you change anything in your BootStrap.ini file, you must update your deployment 

share in order to regenerate the LiteTouch Windows PE images contained in the Boot folder of the 

share. 





Understanding CustomSettings.ini 

CustomSettings.ini is the other configuration file and is also specific to each deployment share. Once 

BootStrap.ini has done its work, CustomSettings.ini takes over and controls the rest of the deployment 

process. The CustomSettings.ini file used in the previous article of this series looked like this: 

[Settings] 



[Default] 

OSInstall=YES 





























The above CustomSettings.ini file contains the same two sections (Settings and Default) that 

BootStrap.ini contains. CustomSettings.ini can contain additional sections however. For example, you 

can include additional sections for deploying Windows to specific makes and models of computers or 

specific locations on your network. We'll examine this in a later article of this series. 

The Default section in the above example contains a number of different property/value pairs. This is 

only a small subset however of the almost 300 different properties you can specify to control various 

aspects of the deployment process. There are essentially two types of properties used in the example 

above: "skip" properties and other properties. 





The "skip" properties are those that determine whether a particular page of the Windows Deployment 

Wizard is displayed or not during installation on the destination computer. For example, if 

SkipComputerName=YES is specified, the Configure The Computer Name page of the wizard is not 

displayed during installation; if SkipComputerName=NO, the page is displayed and a user sitting at 

the destination computer will have to respond in order to proceed with the installation. If you want to 

fully automate an installation, you need to specify YES for all possible skip properties, and the 

example above does this. In other words, the full list of skip properties is as follows: 



















The advantage of including all of these lines in your CustomSettings.ini file is that you can change any 

of them to NO if you want the user involved at some point during deployment. For example, if you 

want the user to choose whether or not to enable BitLocker Drive Encryption on the computer, all you 

need to do is change the line SkipBitLocker=YES to SkipBitLocker=NO in your CustomSettings.ini file 

and the Specify The BitLocker Configuration page of the Windows Deployment Wizard will be 

displayed during installation. 

If you are only interested in fully automating LTI however, you can replace all of the above skip 

properties with the following two lines lines: 

SkipWizard=YES 


The first line causes the entire Windows Deployment Wizard to be skipped (almost). The second line 

causes the final Operating System Deployment Completed Successfully line to be skipped so that the 

user doesn't have to click OK to end the install. 

In other words, our previous and somewhat long CustomSettings.ini file is now reduced to this: 

[Settings] 



[Default] 


OSInstall=YES 

SkipWizard=YES 















What about the remaining properties in the Default section of this shortened CustomSettings.ini file? 

These "other" properties provide the information that the user would have had to manually enter if the 

pages of the Windows Deployment Wizard were displayed during installation. Specifically: 

OSInstall=YES 

This line indicates that deployment is authorized to proceed. If you omit this line, deployment will 

proceed anyways by default. 


This line indicates the destination computer is a new computer that has never been a member of the 

network. Other possible values for this property are REFRESH, REPLACE and UPGRADE. 





These lines indicate that the computer will be joined to the CONTOSO domain during installation. 

Note that this example uses the domain Administrator account for this purpose, but you can use a 

member of the Domain Users account for this purpose such as the MDT user account created earlier 

for BootStrap.ini. 




These lines indicate the keyboard locale and the user locale and language settings. I think the first 

line is optional since it is also specified in BootStrap.ini, but if you don't include the other two lines the 

Locale Selection page of the Windows Deployment Wizard will be displayed during installation. 


This line indentifies the task sequence that will be used for the installation. 






This line indicates the time zone to be configured on the computer. 

Are these the only properties you need to include in CustomSettings.ini to fully automate LTI? It 

depends, if you are not installing any packages or applications as part of your installation, and if you 

are not migrating user state information during the installation, and if you are not configuring BitLocker 

on the destination computer, then the above shortened CustomSettings.ini file is probably all you 

need. 

For example, what if you want to install a language pack as part of your installation? To do this, you 

must first add the language pack to the Packages folder of your deployment share. Then you examine 

the Packages.xml file in the Control folder of your deployment share to determine the GUID 

associated with the language pack. Finally, you include the line LanguagePacks001=value in your 

CustomSettings.ini file where value is the GUID of the language pack. We'll walk through this process 

and other customizations of automated LTI in future articles in this series. 

One final question: How did I know that I needed to include the line LanguagePacks001=value in my 

CustomSettings.ini file if I wanted to include a language pack in my install? Simple—read the manual! 

You should familiarize yourself with the following topics in the Microsoft Deployment Toolkit 2010 

Documentation Library, a Help (.chm) file installed as part of MDT 2010: 

Providing Properties for Skipped Windows Deployment Wizard Pages – This topic lists the 

properties you need to include in CustomSettings.ini when you skip various pages of the Windows 

Deployment Wizard. 

Property Definition – This topic lists all the various properties you can include in 

CustomSettings.ini and what they are used for. 

Both of these topics can be found in the Help file under Microsoft Deployment Toolkit 

Reference\Properties and we'll be referring to the information they contain frequently in future articles 

of this series. 

Part 9: Deploying 32-bit vs. 64-bit Windows 

In the previous articles of this series we have looked at what is new in MDT 2010 and how to 

automate basic deployments of Windows 7 Enterprise edition using MDT 2010. In this article we are 

going to pause for a moment and consider the pros and cons of deploying 32-bit vs. 64-bit Windows. 

Is Now The Time To Deploy 64-bit Windows? 

The Windows client operating system has had a 64-bit version available since Windows XP 

Professional x64 Edition was released in 2004. Unfortunately third-party driver support for this version 

of Windows was limited at the time, which meant that users who installed it were often unable to use 

their printers, scanners, and other peripherals. When Windows Vista became available in early 2007, 

it boasted much improved third-party 64-bit driver support, and some organizations who decided to 

deploy Vista chose to deploy an x64 edition instead of an x86 version to take advantage of the ability 

of 64-bit Windows to run more applications at the same time and to use more than the 3 GB of RAM 

that 32-bit Windows is capable of using. Unfortunately some organizations which chose this path 

without proper planning soon discovered that older 64-bit AMD and Intel systems on which Vista x64 

was installed were only able to use 3 GB of RAM even when 4 GB or more RAM was installed in them. 





In other words, organizations sometimes discovered that the promised performance benefits of using 

64-bit Windows were not achieved. 

So where does this leave us today? Windows 7 has been released to manufacturing (RTM) and is 

already available for volume-licensed customers. If your organization is currently running Windows XP 

on your client computers and you are eager to move forward with migrating your client computers to 

Windows 7, should you take the plunge and deploy only 64-bit Windows 7 if the chipsets in all your 

systems support it? My answer is a resounding YES and I suggest that there is virtually no reason any 

longer to prefer 32-bit over 64-bit Windows, provided you are going to deploy Windows 7 on x64 

systems that are only a year or two old. 

Here is my short list of reasons why you should choose a 64-bit Windows 7 edition over its 

corresponding 32-bit edition: 

If you want to get the best performance possible, there are three things you can do: use a faster 

processor, add more RAM, or replace your drive with a Solid State Disk (SSD) drive. Processors 

are often tied to motherboards, so replacing them is not trivial. RAM is cheap now, and boosting 

your system's memory to 4, 8 or even 16 GB will not empty your bank account. Good SSDs are 

still very expensive however—much more so than RAM. So if you want to boost your performance 

while keeping your budget under your control, adding lots of RAM is the way to go, and 64-bit 

Window 7 Ultimate edition can use up to 192 GB of RAM if your system's motherboard can hold 

that much. So if you want the best performance at the best price, go with 64-bit Windows over 32bit 

provided your system hardware supports addressing more than 4 GB of RAM. And which 

systems support this today? Almost anything you can buy. For example, the Intel x58 workstation 

chipset includes 6 DRAM sockets, and 12 6 x 2 GB = 12 GB of DDR3 DRAM costs less than $200. 

Even quad-core I7 processors are only about $250. 

The 64-bit version of Windows 7 only occupies a couple of more GB on your hard drive than the 

32-bit version. If you are really constrained for hard drive space (i.e. hard drive 32 GB or less) then 

you might prefer installing 32-bit Windows over 64-bit. But if your system has such a small hard 

drive, you're better off buying a large one. Even large SSDs are beginning to rapidly fall in price 

these days. 

If your users rely on some mission-critical 16-bit applications then you might consider installing the 

32-bit version of Windows 7 instead of the 64-bit version. That's because 64-bit Windows 7 

doesn't support running 16-bit applications. However, you can get around this issue by using 

Windows Virtual PC and the Windows XP Mode environment, which lets users run a virtual 

instance of a 32-bit Windows XP operating system on their Windows 7 computers so that users 

can run older applications that are incompatible with Windows 7 (or with 64-bit Windows 7) while 

still being able to take advantage of the many enhancements and new features of Windows 7. 

There's one catch however: the user's system must support hardware virtualization (Intel VT or 

AMD-V) in order to run Windows Virtual PC and the Windows XP Mode environment, and usually 

only higher-end client systems less than about a year old include support for hardware 

virtualization. And if you need a more centralized and manageable way of mitigating application 

compatibility issues on desktop computers using virtualization, be sure to check out Microsoft 

Enterprise Desktop Virtualization (MED-V), a core component of the Microsoft Desktop 

Optimization Pack (MDOP) for Software Assurance (SA). MED-V uses Microsoft Virtual PC to 

create, deliver and manage corporate Virtual PC images on any Windows-based desktop. On the 

other hand, now may be the time when you should finally get serious about recoding your old 

mission-critical 16-bit applications as 64-bit applications. 





Virtually all peripherals sold in the last couple of years have 64-bit drivers available for them. Most 

peripherals these days use USB as their interface with the computer. Windows Virtual PC and the 

Windows XP Mode environment supports USB. The result? No problem! 

If your organization is really constrained in their budget—which may be typical during a recession 

or downturn like the one much of the world is currently experiencing—then you may be able to 

make a case for keeping your older computer systems and migrating them to 32-bit Windows 7. 

On the other hand, when you make your case you should consider the cost of lost productivity 

caused by the poor performance of these older systems. And if your business is that fiscally 

constrained, maybe you should just stay with Windows XP or Windows 2000 or Windows 98 or 

whatever you're currently using. 

Finally, if you are a developer and your dev system uses 32-bit Windows, you can only do 32-bit 

development on your system. If your dev system is 64-bit, you can do both 32- and 64-bit 

development. I have heard of some issues when debugging applications using Visual Studio on 

64-bit Windows that were more complicated and required workarounds compared with running 

Visual Studio on 32-bit Windows, but I'm not a developer and I can't understand these issues in 

any depth. If you want to learn more, read Visual Studio: Why is there no 64 bit version? (yet). 

Considerations when using MDT 2010 with 64-bit Windows 7 

MDT 2010 comes in two versions: x64 and x86. Both versions of MDT 2010 support deploying both 

x86 and x64 Windows operating systems. And both versions of MDT 2010 require version 2.0 of the 

Windows AIK. 

Windows AIK 2.0 however also comes in both x86 and x64 versions. And as the Deployment Guys 

have pointed out, if you are running the 32-bit version of Windows AIK 2.0 on a 32-bit Windows 7 

technician computer, you can create catalogs and answer files for both x64 and x86 custom images. 

On the other hand, if you are running 64-bit version of Windows AIK 2.0 on a 64-bit Windows 7 

computer, you cannot create catalogs or answer files for x86 custom images. And you can not run the 

64-bit version of Windows AIK 2.0 on a 32-bit Windows 7 computer. 

On the other hand, if you are only deploying 64-bit Windows 7, you can install MDT 2010 x64 and 

Windows AIK 2.0 x64 on a technician computer running Windows 7 x64 and not worry about any of 

this! 

Conclusion and Additional Resources 

Clearly in most cases the pros of migrating your client computers to 64-bit Windows 7 outweigh the 

cons in most cases. Because of this, the remaining articles in this Deploying Windows 7 series will 

focus on deploying Windows 7 Enterprise x64 using MDT 2010. Finally, here are a few resources you 

should check out concerning 64-bit Windows: 

64-bit System Design on Windows Hardware Developer Central 

32-bit and 64-bit Windows: frequently asked questions 

Memory Management - Dude where's my RAM? 

Windows Vista SP1 includes reporting of Installed System Memory (RAM) 

XP Mode vs. Med-V on the Springboard Series blog 

How MED-V v2 Helps You Manage Windows XP Mode 





Part 10: Capturing and Deploying an Image of a Reference Computer 

Introduction 

In articles 6 and 7 of this series we examined how to perform a simple, automated deployment of 

Windows 7 Enterprise by performing a Lite Touch Installation (LTI) using MDT 2010. Then in article 8 

we examined the CustomSettings.ini and Bootstrap.ini files in detail and how these two configuration 

files can be used to customize the deployment process by making it more automated. In larger 

organizations however, performing one-off installs of Windows is too simplistic. Instead, you will want 

to do first create a reference computer, that is, a computer that is configured exactly how you want 

your users' computers to be configured. Then you will want to capture the image of this reference 

computer and import the captured image into your deployment share. Finally, you will want to deploy 

this captured image to your users' computers, that is, the target computers for the deployment. This is 

what we will look at in this present article. 

Step 1: Install the Reference Computer and Capture its Image 

After your planning work has been done, the first step in image-based deployment is to install your 

reference computer. As discussed in article 9 of this series, we are going to focus here on deploying 

Windows 7 Enterprise x64 edition from here on out in this series of articles. So begin by opening the 

Deployment Workbench on your technician computer, expand your deployment share, right-click on 

the Operating Systems folder, and select Import Operating System. Then follow the steps of the 

Import Operating System wizard to import a full set of source files from your Windows 7 Enterprise 

X64 DVD. Once you have finished the import process, your Deployment Workbench will look like 

Figure 1 below: 

Figure 1: Windows 7 Enterprise x64 edition has been imported into the deployment share 

Tip: To speed the OS import process, first copy all the files and folders from the Windows DVD to a 

local folder on your technician computer, then import the OS from this local folder instead of from the 

DVD itself. 





Next, create a new task sequence for deploying Windows onto your reference computer. In your 

deployment share, right-click on the Task Sequences node and select New Task Sequence to start 

the wizard. Type WIN7EX64_REF_001 as the task sequence ID and give the task sequence a 

descriptive name as shown in Figure 2 below: 

Figure 2: Creating a task sequence for deploying Windows onto the reference computer 

On the next page, select the Standard Client Task Sequence template. Then on the Select OS page, 

select the Windows 7 Enterprise x64 source files you previously imported (Figure 3): 

Figure 3: Associating an operating system with the task sequence 





Complete the New Task Sequence Wizard in the usual way. Your new task sequence will be 

displayed in Deployment Workbench along with other task sequences you previously created (see 

Figure 4): 

Figure 4: There are two task sequences in this deployment share 

Now, before you deploy Windows to your reference computer, you need to make some changes to 

the CustomSettings.ini file on your technician computer. Right-click on your deployment share and 

select Properties, then select the Rules tab to display the contents of CustomSettings.ini. Modify what 

you see here so that it looks like Figure 5 below: 

Figure 5: Modifying the CustomSettings.ini file for deploying Windows to the reference computer 





Let us compare our new CustomSettings.ini file with the one we previously used in article 7 of this 

series for performing a completely unattended install. The table below shows these two configuration 

files side by side with the new file on the left and with differences highlighted in bold: 

CustomSettings.ini file for deploying Windows Customsettings.ini file for performing a 

to reference computer 

completely automated LTI 

[Settings] 

[Settings] 





[Default] 

[Default] 

OSInstall=YES 

OSInstall=YES 











SkipCapture=NO 




























SkipTaskSequence=NO 




TimeZoneName=Central Standard Time SkipProductKey=YES 








First, note that the value of the SkipTaskSequence property has been changed from YES to NO, and 

there is now no TaskSequenceID property. Making this change means that the Select A Task 

Sequence To Execute On This Computer page of the Windows Deployment Wizard will be displayed 

on the client (the reference computer) when the install is performed. 

Second, note that the value of SkipCapture has been changed from YES to NO. This means that the 

Specify Whether To Capture An Image page of the Windows Deployment Wizard will also be 

displayed on the client when the install is performed. 

Also, note that the JoinDomain and related properties are no longer specified. This is important. If you 

do not omit these lines, the Specify Whether To Capture An Image page of the wizard would not be 

displayed. 





Now update your deployment share to create a LiteTouchPE_x64.iso file you can burn to a CD so you 

can boot your reference computer. To speed this up, you can clear the x86 checkbox on the General 

tab of the properties of your deployment share as shown in Figure 6 below. When you do, this MDT 

will only create a LiteTouchPE_x64.iso file when you update your deployment share and will not 

create a LiteTouchPE_x86.iso file. This will speed up the process of updating your deployment share 

if you are only deploying the 64-bit version of Windows. 

Figure 6: Configuring MDT to only create a 64-bit Windows PE image 

At this point, you will want to add applications, packages and (if needed) out-of-box drivers to your 

deployment share. The goal here is to perform any customizations needed before you deploy 

Windows onto your reference computer. We will examine how to perform such customizations in a 

later article of this series. 

At this point you are ready to deploy Windows onto your reference computer, so boot your reference 

computer, insert the 64-bit WinPE CD created by MDT, and wait for MDT to do its magic. When the 

Select A Task Sequence To Execute On This Computer page of the Windows Deployment Wizard 

appears, select the WIN7EX64_REF_001 task sequence from the list of task sequences displayed. 

Then when the Specify Whether To Capture An Image page appears, select the Capture An Image Of 

This Computer option and accept the default capture location and file name, which in this example will 

be: 





Location: \\SEA-DC1\DeploymentShare$\Captures 

File name: WIN7EX64_REF_001 

The install will then proceed. Note that the install will take quite a bit longer than a simple LTI because 

once Windows has been installed on the reference computer and has been sysprepped, MDT will 

capture the image and upload it to the Captures folder of your deployment share, and capturing the 

image as a .wim file and copying it over the network to the deployment share can take some time. 

When the capture process is completed, the OOBE will be displayed on your reference computer 

(since it was sysprepped by MDT). 

Step 2: Importing the Captured Image 

The next step is to import the captured image of the reference computer. This captured image has 

been uploaded to the Captures folder of the deployment share as shown in Figure 7 next: 

Figure 7: The captured image of the reference computer 

To import this captured image into MDT, right-click on the Operating Systems folder in your 

deployment share and select Import Operating System. On the Source page of the Import Operating 

System Wizard, select Custom Image as shown in Figure 8: 





Figure 8: Importing a custom image 

Click Next. On the Image page, browse to select the captured image (Figure 9). If you need to 

conserve disk space on the technician computer, you can select the checkbox to move the captured 

image instead of copying it. 

Figure 9: Selecting a custom image to import 





Click Next. On the Setup page, leave the default option of Setup And Sysprep Files Are Not Needed 

selected (Figure 10): 

Figure 10: The Setup page of the Import Operating System Wizard 

Now finish the wizard, accepting the defaults, to import the captured image into your deployment 

share. The captured image will be displayed in the Operating Systems folder of your deployment 

share (Figure 11) which means you can now deploy it to your target computers: 

Figure 11: The captured image is ready to be deployed 





Step 3: Deploying the Captured Image to Target Computers 

You are now ready to deploy the captured image to target computers. Begin by creating a new task 

sequence with WIN7EX64_TARGET as its task sequence ID (Figure 12): 

Figure 12: Creating a task sequence for deploying the captured image of the reference 

computer to your target computers 

Select the Standard Client Task Sequence template, then associate the captured image with the task 

sequence as shown in Figure 13: 

Figure 13: Associating the captured image of the reference computer with the task sequence 





Now you will probably want to fully automate the deployment of the captured image of your reference 

computer to your target computers. To do this, open the Rules tab of the properties of your 

Deployment Share and restore the CustomSettings.ini file to the way it was before (see the right side 

of the table earlier in this article) with the exception that the TaskSequenceID property should have 

WIN7EX64_TARGET as its value (Figure 14): 

Figure 14: CustomSettings.ini file for fully automating the deployment of the captured image of 

the reference computer to target computers 

Once you have modified your CustomSettings.ini file like this, boot one of your bare-metal target 

computers, insert your WinPE CD, and watch the captured image of your reference computer being 

automatically deployed to the target computer with no other intervention on your part. 

Part 11: Capturing an Existing Installation 

Introduction 

In the previous article of these series we saw how to use MDT 2010 to deploy Windows 7 to a 

reference computer and then capture an image of this reference computer so you can deploy it to 

multiple target computers. The steps involved were as follows: 





1. Step 1: Install the reference computer and capture its Image 

2. Step 2: Import the captured Image 

3. Step 3: Deploying the captured image to target computers 

All three steps can be performed using MDT 2010 alone, that is, without needing Windows 

Deployment Services or System Center Configuration Manager. This procedure lets you build and 

deploy a customized Windows 7 image using Lite Touch Installation (LTI) for small- and mid-sized 

deployments. 

But there is another way you can use MDT 2010 to build, capture and deploy customized Windows 7 

images and that is to capture an existing installation of Windows 7 that you have manually customized. 

The steps for doing this are as follows: 

1. Step 1: Install the reference computer and manually customize it 

2. Step 2: Capture an image of the reference computer 

3. Step 3: Import the captured Image 

4. Step 4: Deploying the captured image to target computers 

Note the difference: 

In the first approach, which is outlined in article 10 of this series, you customize your reference 

computer using MDT alone. This means you use MDT to deploy the operating system, 

applications, drivers, and software updates. And if you want to further customize the operating 

system you can open Windows System Image Manager (Windows SIM) from within MDT to 

customize the unattend.xml answer file for your installation. Customizing applications however 

may require some advanced tricks involving your answer file. You have to carefully plan all your 

customizations ahead of time as the process of using MDT to deploy and capture an image of 

your reference computer is automated. 

In the second approach, which is outlined below in this article, you use MDT to deploy Windows 

(and if desired applications, drivers and software updates) to create your reference computer. 

Then you log on to your reference computer and manually perform any additional customizations 

that may be needed. Finally, once your reference computer is fully customized, you use MDT 

again to capture its image. This capability of using MDT to capture the image of a Windows 

installation that has already been deployed is new in MDT 2010 and was not possible in MDT 

2008 (with MDT 2009 you had to use Windows Deployment Services to create a capture image as 

described in my earlier article Deploying Vista – Part 21: Working With Capture Images). 

Let us examine the second approach now. 

Step 1: Install the reference computer and manually customize it 

Begin by creating your reference computer. You can do this either by manually installing Windows 7 

and the needed applications, drivers and software updates on a system, or you can use MDT 2010 to 

perform these tasks either manually or by automating them. See my article Deploying Windows 7 – 

Part 6: Light Touch using MDT 2010 for how to manually deploy an image using MDT and my article 

Deploying Windows 7 – Part 7: Automated LTI Deployment for how to automate LTI using MDT. Once 

your reference computer has been deployed, log on to it and customize the operating system and 

applications as desired. 





Step 2: Capture an image of the reference computer 

Now you are ready to capture an image of your reference computer. To do this, you are going to use 

the Sysprep and Capture task sequence template, a new type of task sequence template included in 

MDT 2010. This task sequence does not install Windows on a computer. Instead, it syspreps an 

existing Windows installation on a computer, reboots the computer into Windows PE, captures a .wim 

image file of the installation and uploads the captured image to a network share you specify. 

To create a task sequence for doing this, open the Deployment Workbench, expand your deployment 

share, right-click on the Task Sequences folder and select New Task Sequence. The New Task 

Sequence wizard opens displaying the General Settings page. Specify a task sequence ID and task 

sequence name as shown in Figure 1: 

Figure 1: Creating a new task sequence for capturing an existing installation of Windows 7 

Enterprise Edition 

On the Select Template page of the wizard, select Sysprep and Capture as the task sequence 

template to use for creating the new task sequence (Figure 2): 





Figure 2: Select the Sysprep and Capture template 

On the Select OS wizard page, select the image of the operating system you are going to capture 

(Figure 3). Why do you need to do this if you are not going to install the selected image? Because 

MDT needs this information to get the appropriate unattend.xml answer file needed to perform the 

sysprep and capture process. 

Figure 3: Select an image of the OS you are going to capture 





For the remaining steps of the wizard it does not matter what information you provide—just provide 

something when prompted. 

Now before you use this new task sequence to sysprep and capture an image of your reference 

computer, I recommend that you restore the CustomSettings.ini and Bootstrap.ini files for your 

deployment share to their original values. Specifically, change your CustomSettings.ini file back to 

this: 

[Settings] 



[Default] 

OSInstall=Y 


SkipCapture=NO 



And then change your BootStrap.ini file back to this: 

[Settings] 


[Default] 


I recommend these changes because of my own personal experience trying to get the Sysprep and 

Capture task sequence template working properly. 

Now boot your reference computer normally and log on using an administrator account. Do NOT boot 

your reference computer using your LiteTouchPE_x64.iso CD or a Windows PE bootable CD—you 

are not trying to install an image, just sysprep and capture it. Once you have logged on, open a 

command prompt window and type the following command to manually start the Windows 

Deployment Wizard on the computer: 

\\\\Scripts\LiteTouch.vbs 

Here \\\ is the UNC path to your deployment share. Figure 4 shows this 

command in my test environment: 





Figure 4: Manually launching the Windows Deployment Wizard from the reference computer 

After a few moments the Windows Deployment Wizard will open and you'll be prompted to specify 

credentials for connecting to your deployment share (Figure 5): 

Figure 5: Supply credentials to connect to your deployment share from your reference 

computer 





Now, if when you click Next you get an error message like that shown in Figure 6 below, you can try 

and resolve this issue by either: 

Replacing in the command described above with the IP address of the 

computer on which your deployment share resides. 

Applying the fix described in Fix for "Multiple connections to a server or shared resource by the 

same user, using more than one user name, are not allowed" problem with MDT 2010 found on 

the Microsoft Deployment Toolkit Team Blog. 

Figure 6: Credentials error 

I have personally tried the first approach and got it working. The fix described in the second approach 

was just published the day before writing this article so I have not had time to test it yet. 

Anyways, assuming that the credentials you supplied are accepted, clicking Next displays the wizard 

page asking you select a task sequence. Choose the task sequence you created earlier for 

sysprepping and capturing an existing installation (Figure 7). 





Figure 7: Select your sysprep and capture task sequence 

On the next wizard page, select Capture An Image Of This Reference Computer and accept the 

default image upload location (\\\\Captures) and name for the captured 

image (.wim) as shown in Figure 8 below. Note that if you replaced 

with on the credentials page you should do the same here as well. 

Figure 8: Specifying a name and upload location for image to be captured 





Click Next and review the summary page (Figure 9). 

Figure 9: Summary of what your sysprep and capture task sequence will do 

Now click Begin, and shortly you should see a progress indicator showing the image being 

sysprepped (Figure 10). 

Figure 10: The reference computer is being sysprepped and captured 

If sysprep fails with an error, go back and try one of the fixes described earlier. Otherwise, everything 

should work and the captured image of your reference computer will be uploaded to the Captures 

folder in your deployment share. 





Steps 3 and 4 : Import The Captured Image and Deploy It To Target Computers 

Now you can import the captured image of your reference computer using the process outlined in 

"Step 2: Import the captured Image" of my previous article (Deploying Windows 7 - Part 10: Capturing 

and Deploying an Image of a Reference Computer). Once this is done, you can automatically deploy 

the captured image to your target computers using the procedure outlined in my article Deploying 

Windows 7 - Part 7: Automated LTI Deployment. 

Part 12: Planning for Application Compatibility 

An important issue to consider when planning any kind of desktop deploying is application 

compatibility. If you are upgrading to Windows 7 from Windows Vista, this will hopefully not be a Bit 

issue because applications designed for Windows Vista should, in almost all cases, work properly on 

Windows 7. If you are migrating desktop computers from Windows XP to Windows 7 however, you will 

need to take time to give careful consideration to what you may need to do in order to ensure your 

applications will function properly on the new operating system. 

Why Applications Break 

What are the reasons applications designed for Windows XP sometimes “break” when you try and run 

them on Windows 7? A couple of the main problem areas are: 

User Account Control – Applications that require administrative privileges and which were 

designed for Windows XP may not work properly on Windows 7 even if the user is a member of 

the local Administrators group on his computer. Microsoft has tried to minimize this issue by 

including application compatibility shims in Windows 7 for many common applications, and these 

shims will often even allow users to run such applications as standard users instead of 

administrators. Some older applications however simply will not work on Windows 7, even when 

the user is a local admin. In such a case you may need to use one of the following tools described 

below to run your older application separately from the Windows 7 operating system: Virtual PC 

2007 SP1, Windows Virtual PC with Windows XP Mode, Microsoft Enterprise Desktop 

Virtualization, or Microsoft Application Virtualization. 

User profile structure and versioning – The user profile structure was redesigned in Windows Vista 

to make it more rational. If an older application was designed to access user profile files in the 

correct way using API function calls and environment variables, these user profile changes should 

not impact whether the application will run or not in Windows 7 since Windows 7 includes directory 

junctions for common Windows XP profile folders like My Documents. If however an older 

application has Windows XP-style profile folders hard-coded into the application's code, then the 

application could fail under Windows 7 for this reason. Another issue that can prevent an older 

application from running is if the application is confused by the version number of Windows 7. In 

other words, when you try and start the application, it checks the OS version number, finds this is 

6.1, and was coded not to know what this means and therefore does not start. In such cases as 

these where only a few users are affected, these users can try using the Program Compatibility 

Troubleshooter in Windows 7 and see if this resolves the issue. If a lot of users will be affected, 

you can try using the Application Compatibility Toolkit to try and analyze the problem and develop 

a “fix” you can deploy to the affected computers. 





Tools for Mitigating Application Compatibility Issues 

Microsoft provides a number of tools you can use to ensure you can still use your older applications 

after upgrading or migrating to Windows 7. These tools are basically of three types and these are my 

own "friendly" names for each category: 

One-off tools – Try using these tools first if only a few users are going to be affected. 

Large-scale tools – Large-scale enterprise environments should consider using these tools first. 

Virtualization tools – When all else fails, virtualize. 

Let us briefly examine each category. 

One-Off Tools for Running Older Applications 

Let us say you are retiring your old Windows XP computers for newer ones running Windows 7. 

Afterwards, several users indicate they need an older program installed on their computers. You try 

installing the program and something like this appears (Figure 1): 

Figure 1: Warning from Program Compatibility Assistant 

If you see a warning like this when installing an older program on Windows 7, you can click Check For 

Solutions Online and see if Microsoft has previously identified this issue and has created a fix for it. 

If the older program seemed to install OK on Windows 7 but problems arise when users try and run it, 

they can click Start, type program compatibility in the Start menu search box, and press ENTER to 

launch the Program Compatibility Troubleshooter (Figure 2). Doing this will cause Windows to try and 

find issues with installed applications, determine whether fixes are available, and apply the fixes to try 

and resolve the issues. 





Figure 2: Running the Program Compatibility Troubleshooter 

If this does not work the user can right-clicking on the executable program file in Windows Explorer, 

selecting Properties, selecting the Compatibilty tab, and manually trying different program 

compatibility modes to try and get the application to work properly (Figure 3). 

Figure 3: Selecting a program compatibility mode 





If none of these approaches work, see Virtualization Tools below. 

Large-Scale Tools for Analyzing and Mitigating Application Compatibility Issues 

If your organization has hundreds or thousands of users running dozens of different applications on 

their computers, you will definitely need to take a more proactive approach than the after-the-fact 

method described in the previous section above. In this case the tool you will want to use is the 

Application Compatibility Toolkit (ACT) version 5.5. ACT is a collection of tools and documentation 

that you can use to evaluate and mitigate application compatibility issues prior to beginning the 

deployment of Windows 7 in your environment. ACT helps you understand your application 

compatibility situation by identifying which of your existing applications are compatible with Windows 7 

and which might require further testing. ACT can also help you develop compatibility fixes for problem 

applications which you can then deploy as application mitigation packages to affected systems. ACT 

is a complex tool that takes some getting used to—for more information on using ACT see Chapter 5 

of the Windows 7 Resource Kit from Microsoft Press. And you can download ACT 5.5 from here. 

Virtualization Tools for Running Older Applications 

Whether you are a smaller shop that has found that the built-in application compatibility tools in 

Windows 7 are not sufficient, or a large enterprise that has discovered that application compatibility 

issues for certain older business-critical applications cannot be resolved using ACT, you still have 

several ways you can proceed in order to keep those older applications running for users who need 

them. Virtualization is the key here, and your choices from Microsoft are as follows: 

Virtual PC 2007 SP1 – If you migrated older computers to Windows 7 you can install Virtual PC 2007 

SP1 on these computers so the users of these computers can install their problematic older 

applications in a separate instance of Windows XP (or an older version of Windows) running in a 

separate virtual machine. Note that this solution has some limitations. For example, Virtual PC does 

not include support for USB devices. You can download Virtual PC 2007 SP1 from here. 

Windows XP Mode and Windows Virtual PC - Windows Virtual PC lets you run multiple Windows 

environments including Windows XP Mode from your Windows 7 desktop. By installing your 

problematic older applications into the Windows XP Mode environment, users can run these 

applications directly from the Start menu. The advantages of this virtualization approach over Virtual 

PC 2007 SP1 are: 

No separate virtual desktop for running the older applications—they are integrated into the 

Windows 7 desktop. 

Support for USB devices such as printers, scanners and so on. 

The disadvantage of this approach is that Windows Virtual PC requires processors that support 

hardware virtualization (Intel-VT or AMD-V). Only desktop computers a year or so old typically support 

such technologies. So if you migrated older systems from Windows XP to Windows 7 you won't be 

able to use this method. But if you purchased brand new Windows 7 systems to replace your older 

Windows XP computers, you may be able to use this approach to run problematic older applications 

on these computers. You can download Windows XP Mode and Windows Virtual PC from here. 

Microsoft Enterprise Desktop Virtualization – MED-V is an enterprise tool that can be used to 

deliver Virtual PC images to computers from a central repository where you can create and manage 

these images. MED-V thus helps reduce application-to-OS compatibility issues, but in a more scalable 





and managed way than simply installing Virtual PC on each user's computer. Using MED-V, you can 

manage the entire life cycle of virtual images, provision them to authenticated users in an Active 

Directory environment, monitor their usage, and more. The user remains unaware of the virtualization 

running in the background and sees only one desktop environment. MED-V is part of the Microsoft 

Desktop Optimization Pack (MDOP). For a look at how MED-V works and how you can use it, see 

Chapter 6 of my free ebook Understanding Microsoft Virtualization Solutions: From the Desktop to the 

Datacenter from Microsoft Press. 

Microsoft Application Virtualization – Microsoft App-V is an enterprise tool that can be used to 

centralize the management of the entire application life cycle. Using App-V, administrators can 

dynamically deliver applications on-demand to users who need them instead of installing them on 

each user's computer. App-V helps reduce application-to-application conflicts, for example when a 

user needs to run two different versions of the same application and are unable to install both 

versions locally on the same machine. App-V also simplifies software update management and makes 

application compatibility regression testing easier. App-V is also part of MDOP. For a look at how 

App-V works and how you can use it, see Chapter 4 of my free ebook Understanding Microsoft 

Virtualization Solutions: From the Desktop to the Datacenter from Microsoft Press. 

Part 13: Manual Migration from Windows XP to Windows 7 

Understanding the Refresh Computer Deployment Scenario 

So far we've looked at how to use MDT 2010 to deploy a Windows 7 image onto bare-metal target 

computers. This is known as the New Computer deployment scenario, whereby a new installation of 

Windows 7 is deployed to a new computer. In the New Computer scenario, there are no existing user 

settings or data that need to be migrated, and the Standard Client Task Sequence is used to deploy 

the captured image of your reference computer onto the target computer. 

But what if our target computers are already in use and are running Windows XP and have user 

settings and data stored on them? And what if we want to migrate these computers to Windows 7 

while retaining the existing user settings and data on each computer? In that case, the user settings 

and data on each computer must first be saved, then the computer must be wiped, the new operating 

system is laid down, and finally the user settings and data are restored. This is known as the Refresh 

Computer deployment scenario, and in addition to using this approach to migrate computers from 

Windows XP to Windows 7 you can also use it to "repair" user's Windows 7 computers by re-imaging 

them when they become corrupted. 

Note: Why can't one use the Upgrade Computer deployment scenario to migrate computers from 

Windows XP to Windows 7? Because there is no supported upgrade path from Windows XP to 

Windows 7, take a look at this link for a list of supported upgrade scenarios. For more information on 

deployment scenarios, see my earlier article Understanding Deployment Scenarios in my series of 

articles on deploying Vista. 

Verifying Migration Readiness 

Before you migrate a Windows XP computer to Windows 7, you should make sure the computer is 

able to run the new operating system. If you are only migrating a small number of computers, you can 

use the Windows 7 Upgrade Advisor, available from here. For larger migrations however, you should 

use the Microsoft Assessment and Planning Tool (MAP) 4.0 described in article 3 and article 4 of this 

series. 





Migrating User Settings and Data 

MDT 2010 includes the User State Migration Tool (USMT) 4.0 and uses this tool to migrate user 

settings and data during a Refresh or Replace Computer deployment scenario. A new feature of 

version 4.0 of USMT is support for hard-link migration, which allows user settings and data to remain 

stored on the computer during a Refresh Computer deployment scenario. With earlier versions of 

USMT, user state information (user settings and data) had to be copied to a network share or 

removable media because the computer was wiped during a Refresh Computer deployment scenario, 

then after the operating system is installed the user state information is restored by copying it back to 

the computer from the network share or removable media where it was saved. 

With hard-link migration however, the user state remains where it is on the user's computer, hard links 

are created for the user settings and data files. A hard link is a directory entry for a file on an NTFS file 

system. Usually each file has a single hard link, meaning the file appears in a single directory on the 

file system. With hard-link migration however, USMT creates an additional hard link for each user 

setting or data file so that the file also appears to reside in the temporary C:\MININT folder created by 

MDT during deployment. Then, instead of wiping the file system from the computer in order to reimage 

it, MDT 2010 simply deletes all operating system folders and files from the computer—the boot 

volume is not formatted—while the MININT folder ensures that the user state information is not 

deleted from the computer. After installation is complete, the user state information is restored to its 

proper locations by rebuilding the links to the files, and the MININT folder together with its hard links is 

deleted. 

The benefits of this approach for migrations are threefold: 

1. The migration is faster because the file system does not need to be wiped and recreated during 

deployment. 

2. The migration is faster because the user state information doesn't need to be copied to a network 

location, deleted from the computer, and restored. 

3. The deployment is simpler because you do not need to create a separate network share for 

storing saved user state information. 

Manually Migrating Windows XP Computers to Windows 7 

Now let us try manually migrating a Windows XP computer to Windows 7 using MDT 2010. Begin by 

customizing the computer, for example by saving a bitmap image file in the My Pictures folder of user 

Karen Berg (CONTOSO\kberg) as shown in Figure 1: 

Figure 1: Karen's computer is currently running Windows XP and has a photo in her My Pictures folder 





Now on the technician computer, open the properties of your deployment share and configure the 

BootStrap.ini file to read as follows: 

[Settings] 


[Default] 







Then configure the CustomSettings.ini file to read as follows: 

[Settings] 



[Default] 

OSInstall=YES 







SkipComputerName=NO 

SkipComputerBackup=NO 

ComputerBackupLocation=AUTO 

SkipDeploymentType=NO 






SkipFinalSummary=NO 







SkipSummary=NO 




SkipUserData=NO 

UserDataLocation=AUTO 

Then create a new task sequence based on the Standard Client Task Sequence and configure the 

task sequence to deploy Windows 7 Enterprise edition. 

Now log onto Karen's computer as Administrator, open a command prompt, and type the following 

command to launch the Windows Deployment Wizard on the computer: 





\\SEA-DC1\DeploymentShare$\Scripts\LiteTouch.vbs 

The wizard will begin by prompting you to select a task sequence (Figure 2): 

Figure 2: Select the task sequence for migrating from XP to Windows 7 

Next, you will be prompted to select the Refresh Computer deployment scenario (Figure 3): 

Figure 3: Note that the Upgrade Computer deployment scenario is not available for Windows XP 





Next, you will be prompted to specify a new name for the computer or accept the existing name 

(Figure 4): 

Figure 4: Specify the computer name 

Next, you are prompted to specify how to handle user state information. Leave this set at the default 

of automatically determining the location and storing the information locally on the computer (Figure 

5): 

Figure 5: Using hard-link migration to store user state information locally on the computer 





Next, you are prompted to make an image backup of your computer in case the migration fails. You 

should always do this, but for this walkthrough we will omit the part where you create the backup to 

speed things up (Figure 6): 

Figure 6: You should back up the computer before migrating it to Windows 7 (though we are 

not doing this here) 

Next, review the choices you have made (Figure 7): 

Figure 7: Review your selections 





Now click Begin, and soon a progress bar will indicate that user state information is being captured 

(Figure 8): 

Figure 8: User state information is being captured and saved on the computer 

After a short time, the computer will reboot and MDT will begin applying the Windows 7 image to the 

computer. Once Windows 7 has been installed and the computer reboots for the last time, the 

progress bar will indicate that the captured user state information is being restored (Figure 9). 

Figure 9: User state information is being restored 

This may take a few minutes. Once this is done, Karen Berg can log onto her refreshed computer and 

when she opens her Pictures library, she sees that the photo is still present, which indicates that her 

user state information has been successfully migrated (Figure 10): 

Figure 10: The migration of user state information was successful during the XP to Win7 migration 





In the next article of this series we'll examine how to automate this whole process. 

Part 14: Automated Migration from Windows XP to Windows 7 

Tip: You can find more information about automating LTI deployment in the Windows 7 Resource Kit 

from Microsoft Press. I'm the lead author for this Resource Kit and I also maintain the Unofficial 

Support Site for the Windows 7 Resource Kit where you will find the latest updates and other useful 

information. 

In the previous article of this series, we examined how MDT 2010 together with USMT 4.0 can be 

used to manually migrate a Windows XP computer to Windows 7 while maintaining the user settings 

and data on the computer. In this article we are going to fully automate the migration process. 

To do this, use the Deployment Workbench on your MDT computer to open the properties of your 

deployment share. If you have worked through the previous article of this series then the Bootstrap.ini 

file for this share will look like this: 

[Settings] 


[Default] 







This is fine as is. We do not need to modify Bootstrap.ini any further. 

Now examine the CustomSettings.ini file for your deployment share, which should currently look like 

this: 

[Settings] 



[Default] 

OSInstall=YES 







SkipComputerName=NO 



SkipDeploymentType=NO 


















SkipUserData=NO 





Here is where we need to make several changes in order to automate the migration process. 

First, change this line: SkipComputerName=NO 

to the following: SkipComputerName=YES 

Doing this means you won't be prompted to rename the computer during the migration. 

Next, change these two lines: 



to the following: 


ComputerBackupLocation=NONE 

Of course, not backing up the computer before migrating it is not a good idea, but we will do this to 

speed up the walkthrough. 

Next, change this line: SkipDeploymentType=NO 

to this: SkipDeploymentType=YES 

and add the following line below it: DeploymentType=REFRESH 

Doing this means that you won't be prompted to choose the type of deployment scenario to perform. 

Next, change this line: SkipTaskSequence=NO 

to this: SkipTaskSequence=YES 

Then under this line add another line specifying the task sequence you will use for the migration, 

which in my own lab environment is the following: TaskSequenceID=XP_TO_W7 

Next, change this line: SkipUserData=NO 

to this: SkipUserData=YES 

Leave this line unchanged: UserDataLocation=AUTO 





This will cause user state information to be captured and restored using hard-line migration. 

Finally, change these two lines: 



to read as follows: 



Doing this will hide the final summary screen of the Windows Deployment Wizard from the computer's 

user. 

Having made all of these changes, your CustomSettings.ini file should now look like this: 

[Settings] 



[Default] 

OSInstall=YES 









ComputerBackupLocation=NONE 


DeploymentType=REFRESH 















TaskSequenceID=XP_TO_W7 



SkipUserData=YES 






Before you perform the deployment, make sure that you have customized the users’ computer, for 

example, by copying a photo file to the My Pictures folder in her user profile as we did in the previous 

article of this series. 

Now log onto the user's computer as Administrator, open a command prompt, and type the following 

command to launch the Windows Deployment Wizard on the computer: 

\\SEA-DC1\DeploymentShare$\Scripts\LiteTouch.vbs 

Instead of having to respond to various prompts of the wizard, the progress bar will immediately be 

displayed indicating that the user state information on the computer is being captured (Figure 1): 

Figure 1: User state information is being captured 

After a short time, the computer will reboot and MDT will begin applying the Windows 7 image to the 

computer. Once Windows 7 has been installed and the computer reboots for the last time, the 

progress bar will indicate that the captured user state information is being restored (Figure 2): 

Figure 2: User state information is being restored 

Once this is done, the user can log onto her refreshed computer and when she opens her Pictures 

library, she sees that the photo is still present, which indicates that her user state information has 

been successfully migrated (Figure 3): 





Figure 3: The migration succeeded 

Considerations when Migrating from Windows XP to Windows 7 

Before you jump in and begin migrating all your Windows XP computers to Windows 7, you need to 

consider a few things. 

First, if your Windows XP computers are old and do not have the hardware to properly support 

running Windows 7 on them, consider using the Replace Computer deployment scenario instead of 

the Refresh Computer scenario. In the Replace Computer scenario, MDT first uses USMT to capture 

user state information and save it to a network share. Then MDT performs a clean installation of 

Windows 7 on a brand-new computer. Finally, MDT uses USMT to restore the user state information 

to the new computer. In this scenario, the user gets a new computer and a new operating system but 

retains her existing user settings and data. Afterwards you send the users' old computers to the 

recycle mart. 

Second, if your Windows XP computers have older applications that aren't compatible with Windows 7 

then you'll need to use the application compatibility tools and strategies outlined in part 12 of this 

series before you can consider migrating the computers to Windows 7. 

Third, if you plan on upgrading the applications on your Windows XP computers to newer versions of 

these applications, and if all important user data is redirected for storage on the network, then maybe 

you shouldn't migrate the computers at all. Instead, consider using the New Computer deployment 

scenario to deploy Windows 7 together with new applications onto either new or existing hardware, 

and forget about migrating user settings and data. After all, what better time to start from scratch than 

when you are migrating your desktop computers from an operating system that is approaching end of 

life? 

Finally, if you want to customize which user settings and data are migrated and which are not 

migrated (for example to avoid migrating settings for older applications that are no longer needed) 

then you need to learn how to customize the XML migration files that govern how USMT works. In this 





case, you can begin learning more by reading Chapter 7 of the Windows 7 Resource Kit from 

Microsoft Press. This will give you a good introduction to how USMT can be customized, and if you 

need to dig deeper into this topic then see the User State Migration Tool 4.0 User's Guide in the 

TechNet Library here. 

Part 15: Configuring the MDT Database 

Understanding the MDT Database 

So far in this series of articles we have learned how to use MDT 2010 to perform a Lite Touch (LTI) 

deployment of Windows 7 onto a single computer, either manually or fully-automated. But what if you 

need to deploy Windows 7 onto dozens or even hundreds of computers? What if you want specific 

names assigned to each computer? What if you want one group of computers to have one set of 

Windows features installed, another group to have other features, and so on? What if you want 

computers at one location to have one set of applications installed, and those at a different location to 

have a different set of applications installed? 

If you want to perform mass deployments like this and customize what drivers, features or 

applications are installed according to the computer's hardware, location or role, you can accomplish 

this with MDT by using the MDT database. The MDT database is basically a Microsoft SQL Serverbased 

version of the CustomSettings.ini file that can be used as a central repository for storing the 

configuration settings used to deploy multiple computers using MDT. Without the MDT database, you 

would need to create a separate CustomSettings.ini file for each computer you want to deploy using 

MDT and then copy/paste this file into MDT each time you deploy a new computer. With the MDT 

database, you only have one CustomSettings.ini file for all computers, plus a SQL database that 

contains the customizations specific to each computer. 

Installing SQL Server 2008 Express 

Before you can create and configure the MDT database, you must prepare your environment by 

installing and configuring one of the following versions of SQL Server in your environment: 

SQL Server 2005 

SQL Server 2008 

SQL Server 2008 Express 

You can install SQL Server either on the MDT computer itself or on a separate computer on your 

network. 

For this example, we will install SQL Server 2008 Express on our MDT computer which is a domain 

controller SEA-DC1.contoso.com in our test environment running Windows Server 2008 R2. If you 

install your SQL Server 2008 Express instance on a different platform such as Windows Server 2008 

or Windows Server 2003 SP2, you will first need to install the following two items which are 

prerequisites for installing SQL Server 2008 Express: 

Microsoft .NET Framework 3.5 SP1 

Windows Installer 4.5 Redistributable 

Begin by downloading SQL Server 2008 Express SP1 from the Microsoft Download Center. Then 

double-click on SQLEXPR_platform_ENU.exe where platform is either x64 or x86 (for Windows 

Server 2008 R2 platform must be x64) to open the SQL Server Installation Center (Figure 1): 





Figure 1: The SQL Server Installation Center 

Next, click Installation on the left to display the various installation options (Figure 2): 

Figure 2: Options for installing SQL Server 2008 Express 





Next, click "New SQL Server stand-alone installation or add Features to an existing installation" to 

launch the SQL Server 2008 Setup wizard. Skip the product key page since the Express version is 

free and doesn't require you to specify a product key, then accept the EULA. At this point the page for 

installing the Setup Support Files is displayed (Figure 3): 

Figure 3: Installing the Setup Support Files 

Click Install to install the Setup Support files. Once these are installed, the Setup Support Rules run to 

check whether your computer can support installation of SQL Server 2008 Express (Figure 4): 

Figure 4: Verifying the computer supports installing SQL Server 2008 Express 





Note that we get two warnings in this example. First, installing SQL Server on a domain controller is 

not recommended, but it is actually fine to do this for a test environment like the one we are using 

here. And second, Windows Firewall is currently blocking remote computers from being able to 

access the SQL Server instance we are going to install—we will deal with this later in this article. 

On the Feature Selection page, select Database Engine Services (Figure 5): 

Figure 5: Selecting features to install 

Accept the defaults on the Instance Configuration page (Figure 6): 

Figure 6: Installing a new instance of SQL Server 2008 Express 





On the Disk Space Requirements page, verify that the computer has sufficient disk space for the 

install (Figure 7): 

Figure 7: Disk Space Requirements page 

The Server Configuration page lets you specify a service account for each SQL Server service (Figure 

8). 

Figure 8: Server Configuration page 





For our test environment, we will use the same account for each SQL Server service. To do this, click 

"Use the same account for all SQL Server services" and type CONTOSO\Administrator and the 

password for the account (Figure 9): 

Figure 9: Specifying a service account for all SQL Server services 

On the Database Engine Configuration page, add the CONTOSO\Administrator account to the list of 

SQL Server administrators (Figure 10). Since we are logged onto the computer using this account, 

you can add it to the list by clicking Add Current User. Leave the remaining settings as they are. 

Figure 10: Adding CONTOSO\Administrator to the list of SQL Server administrators 





Accept the defaults on the Error and Usage Reporting page, then click Next to run the Installation 

Rules to determine whether the installation will succeed (Figure 11): 

Figure 11: The installation will succeed 

On the Ready to Install page, verify the installation options you have selected (Figure 12): 

Figure 12: Verify installation options 





Now click Install and view the progress of the installation. When the installation has finished, click 

Close to close the wizard. 

Configuring SQL Server 2008 Express 

Once SQL Server 2008 has been installed, it needs to be configured so that MDT can use it. To do 

this, begin by clicking Start, All Programs, Microsoft SQL Server 2008, Configuration Tools, SQL 

Server Configuration Manager. This opens the SQL Server Configuration Manager console which you 

can use to configure SQL Server protocols, services, and other features. Expand the local server 

node, then expand SQL Server Network Configuration, and select Protocols for SQLEXPRESS. Then 

right-click on Named Pipes and select Enabled (Figure 13): 

Figure 13: Enabling named pipes for the SQLEXPRESS instance 

Enabling Named Pipes like this for SQL Server is needed so that the Deployment Workbench can 

connect to the database, and also to enable client computers to connect to the database. 

Next, select the SQL Server Services node beneath the root node (Figure 14): 

Figure 14: Configuring SQL Server services 





Note that the SQL Server Browser services is currently stopped and in fact is disabled. Right-click on 

this service and select Properties, select the Service tab, and change the Start Mode of the service 

from Disabled to Automatic (Figure 15): 

Figure 15: Enabling the SQL Server Browser service 

Next, right-click on the SQL Server Browser service and select Start to start the service. Then rightclick 

on the SQL Server (SQLEXPRESS) service and select Restart. These service modifications are 

needed in order that client computers can make a connection to the named instance "SQLEXPRESS". 

Next, open Windows Firewall from Control Panel and click "Allow a program or feature through 

Windows Firewall." Then click Allow Another Program and browse as shown in Figure 16 until you can 

select the following executable: 

C:\Program Files\Microsoft SQL Server (x86)\90\Shared\sqlbrowser.exe 

Figure 16: Opening a program exception in Windows Firewall: step 1 





Once you have selected this executable, click Open to return to the Add A Program dialog box (Figure 

17): 


Then click Add and the new program exception is displayed in Windows Firewall (Figure 18): 






Finally, do the same to add another program exception for the following executable: 

C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\binn\sqlservr.exe 

These firewall exceptions are necessary to allow client computers to establish a connection to the 

SQL Server and SQL Browser services. 

Tip: Instead of creating exceptions manually like this, you can use the batch script of netsh commands 

found in KB 968872 to open the necessary firewall ports for SQL Server. 

Creating the MDT Database 

At this point, SQL Server Express is installed and configured. The final step is to create a new 

database in MDT. To do this, open the Deployment Workbench and under your deployment share 

expand Advanced Configuration to display Database. Then right-click on Database and select New 

Database (Figure 19): 

Figure 19: Creating a new MDT database: step 1 

On the SQL Server Details page of the New DB Wizard, type the name of the SQL Server (here the 

same as the MDT computer) and the database instance (SQLEXPRESS) and make sure Named 

Pipes is selected as the network library (Figure 20): 






On the Database wizard page, select Create A New Database and specify a name for your new 

database (Figure 21): 






On the SQL Share page, type the share name of your deployment share so that WinPE can establish 

a connection to your SQL Server database using Windows integrated authentication (Figure 22): 


Once you have finished the wizard without errors, the Database page will look something like Figure 

23: 

Figure 23: The new MDT database has been created 





Conclusion 

This article examined how to install SQL Server 2008 Express SP1 on your MDT computer and create 

a new MDT database. In the articles that follow, we will look at how to use this database to centrally 

store configuration settings for deploying Windows 7 to multiple computers using MDT. 

In the previous article of this series you learned how to create and configure the MDT database using 

Microsoft SQL Server 2008 Express. In this article and ones following we will examine how to use the 

MDT database to customize how Windows 7 is deployed based on the properties of the target 

computers, their intended roles, their locations, and their make/model. This present article focuses on 

the first method, that is, customizing how Windows 7 is deployed based on the properties of the target 

computer. 

Part 16: Using the MDT Database 

Configuring MDT Database Rules 

As explained in the previous article of this series, the MDT database lets you store many of the 

configuration settings used for customizing deployment in a single, central database. These 

configuration settings are essentially the same as those that can be stored in the CustomSettings.ini 

file, and using the database allows you to have only one, generic CustomSettings.ini file while the 

remaining settings are stored in the database. Furthermore, by using the MDT database you can often 

perform all of your deployments using only a handful of images (such as x86 client, x64 client and x64 

server) and only two task sequences (Standard Client and Standard Server). Clearly, being able to 

understand and use the MDT database is an essential key for simplifying Lite Touch (LTI) 

deployments. 

Let us begin by picking up where we left off from the previous article in this series where you learned 

how to create the MDT database in SQL Server 2008 Express. Figure 1 shows the properties of the 

MDT database we created in that article: 

Figure 1: Properties of MDT database created in previous article of this series 





Let us also examine our CustomSettings.ini file again, which is configured to perform fully automated 

deployments of Windows 7 Enterprise edition (Figure 2): 

Figure 2: CustomSettings.ini file configuring MDT database rules 

Now before we can use the MDT database to deploy Windows 7 based on the properties, intended 

roles, locations or make/model of our target computers, we need to configure our CustomSettings.ini 

file so that it can use settings we choose to store in this database. To do this, right-click on Database 

in the Deployment Workbench and select Configure Database Rules. This launches the Configure DB 

Wizard, which is a bit of a misnomer because it does not configure the database but instead 

configures your CustomSettings.ini file by adding additional rules to it so that MDT can query the 

database during deployment. The first screen of this wizard enables MDT to query the database for 

computer-specific settings and for roles, applications, packages and administrators assigned to the 

computer (Figure 3): 

Figure 3: Enabling MDT to query the database using computer options 





Note that for each item selected in this wizard, MDT will use a script to perform the corresponding 

database query. That means the more items you select, the more queries will be performed and the 

longer it will take to perform the deployment. This added delay happens right after logging into the 

Windows Deployment Wizard using the credentials you specified, that is, it happens during the 

beginning "blue screen" portion of the deployment. On the other hand, the more items you select in 

the wizard, the more options you will have later for customizing how your deployments can be 

performed. Personally, I simply recommend you leave all checkboxes selected in this wizard, which is 

what I'm doing here in this article. 

The next wizard page enables MDT to query the database for location names based on default 

gateways, for location-specific settings, and for roles, applications, packages and administrators 

assigned to the location (Figure 4): 

Figure 4: Enabling MDT to query the database using location options 

The next wizard page enables MDT to query the database for model-specific settings, and for roles, 

applications, packages and administrators assigned to the specified make and model (Figure 5): 





Figure 5: Enabling MDT to query the database using make/model options 

The next wizard page enables MDT to query the database for role-specific settings, and for 

applications, packages and administrators assigned to the role (Figure 6): 

Figure 6: Enabling MDT to query the database using role options 





The next wizard page presents a summary of your selections - verify and complete the wizard. Now 

open the CustomSettings.ini file for your deployment share and examine the changes (Figure 7): 

Figure 7: CustomSettings.ini file after configuring MDT database rules 

The new sections in this file are parsed and actions taken in the order specified by the Priority= 

statement in the initial Settings section. For example, the first section used is CSettings, which queries 

the contents of the MDT database for computer-specific information concerning the target computer 

such as the computer's Universally Unique Identifier (UUID), asset tag, serial number, or Media 

Access Control (MAC) address. 

Customizing Deployment Based on the Target Computer's MAC Address 

To see how this works in practice, let us add a new entry to the MDT database that specifies the MAC 

address of a particular computer on our network so that MDT can install Windows 7 onto this 

computer and assign the computer a pre-specified computer name. In other words, we're going to use 

the MDT database to identify a particular computer in our organization on which we want to perform a 

certain type of customized deployment of Windows 7 - this is the essence of what you can do using 

the MDT database. To do this, right-click on the Computers node in your database and select New to 

identify a particular computer you want to deploy to by adding a new record concerning the computer 

to your database (Figure 8): 





Figure 8: Step 1 of identifying a particular computer on which you want to perform a 

customized deployment of Windows 7 

In the Properties sheet that opens up for the computer you are going to define in the database, type 

the MAC address for the computer (Figure 9). The MAC address for the computer can be determined 

by using Ipconfig (if the computer already has an operating system installed) and possibly also from 

its accompanying documentation or by using a network card configuration utility that might have been 

included with the computer's documentation. 







Tip: The MAC address must be specified in the format XX:XX:XX:XX:XX:XX. If you use any other 

format such as XX-XX-XX-XX-XX-XX, MDT will flash a red exclamation point icon, and hovering your 

mouse pointer over this icon will display a tip telling you the mistake you made. So watch out for these 

flashing red exclamation point icons! 

Now let us indicate what type of customization will be performed when Windows 7 is deployed to the 

computer having this particular MAC address. To do this, select the Details tab, scroll down to the 

Identification section, and type SEA-DESK-299 as the value for the OSDComputerName property 

(Figure 10). Note that you must use the OSCComputerName property for doing this - the 

ComputerName property several lines above this is deprecated and should not be used. 



Click OK to close the Properties sheet and create the new record in the MDT database. The result is 


Figure 11: A new record has been created in the MDT database that identifies a computer and 

allows deployment to be customized for this computer 





Now when we boot the computer having this MAC address using my LiteTouch_x64 CD, the 

computer boots to Windows PE, connects to MDT and the database is queried and the record 

returned. MDT then uses CustomSettings.ini together with the results of the query to install Windows 

7 on the computer and configure the computer's name as we intended, which can be verified by 

opening the System properties on the computer after MDT finishes the install (Figure 12): 

Figure 12: Verifying that the computer has been named SEA-DESK-299 as specified in the MDT database 

Customizing Deployment Based on the Target Computer's UUID 

As a second example, we can also use MDT to customize how Windows 7 is deployed based on the 

UUID of the target computer. The UUID of a computer (sometimes called the computer's Globally 

Unique Identifier or GUID) is a hexadecimal string of the form XXXXXXXX-XXXX-XXXX-XXXX- 

XXXXXXXXXXXX that may be listed on a label on the outside of the computer's case or on a label 

inside the case. It may also be specified in the BIOS settings or displayed by the BIOS when the 

computer is starting up. If none of these helps and you already have a Windows operating system 

installed on the computer, you can use the following Windows Management Instrumentation (WMI) 

script that I wrote which lists the computer's UUID along with other information gleaned from the 

Win32_ComputerSystemProduct WMI class: 

' DisplayClassProperties.vbs 

' Used to find the UUID of a specific desktop computer 

' By Mitch Tulloch (www.mtit.com) 

Option Explicit 

On Error Resume Next 

Dim strComputer 

Dim strWMINamespace 

Dim strWMIQuery 

Dim objWMIService 

Dim colItems 

Dim objItem 

strComputer = "." 

strWMINamespace = "\root\CIMV2" 

strWMIQuery = ":Win32_ComputerSystemProduct.IdentifyingNumber='MXG5380254 





NA540',Name='PY196AV-ABA a1130e',Version='0n31211CT101AMBEM00'" 

Set objWMIService = GetObject("winmgmts:\\" & strComputer & strWMINamespace & 

strWMIQuery) 

WScript.Echo "Number of properties of " & strWMIQuery & " class is " & 

objWMIService.Properties_.count 

For Each objItem in objWMIService.Properties_ 

Wscript.Echo "Property: " & objItem.name & vbTab & "Value: " & objItem.value 

Next 

Note that you'll have to customize the following line for your particular computer before the script can 

work: 



Specifically, you'll need to use wbemtest.exe to determine how to modify the above line for a 

particular computer. To learn how to do this, see the earlier article by me on WindowsNetworking.com 

called Managing Windows Networks Using Scripts - Part 13: A Handy Return-All-Values Script. 

For example, when I run cscript DisplayClassProperties.vbs on a particular computer where the line 

identified has been customized appropriately, the results returned look like this: 

Microsoft (R) Windows Script Host Version 5.8 

Copyright (C) Microsoft Corporation. All rights reserved. 

Number of properties of :Win32_ComputerSystemProduct.IdentifyingNumber='MXG5380254 

NA540',Name='PY196AV-ABA a1130e',Version='0n31211CT101AMBEM00' class is 8 

Property: Caption Value: Computer System Product 

Property: Description Value: Computer System Product 

Property: IdentifyingNumber Value: MXG5380254 NA540 

Property: Name Value: PY196AV-ABA a1130e 

Property: SKUNumber Value: 

Property: UUID Value: 843E4800-986A-1010-9814-8CFE95F168A8 

Property: Vendor Value: HP Pavilion 061 

Property: Version Value: 0n31211CT101AMBEM00 

From the above script output you can see that this particular computer's UUID is 843E4800-986A- 

1010-9814-8CFE95F168A8. Now, if I create a new Computer record in the MDT database that 

specifies this UUID, I can perform a customized deployment of Windows 7 to this particular computer 

in a similar way as if I had specified the MAC address of the computer. 

Part 17: Deploying Applications Based on Make and Model 


from Microsoft Press. I am the lead author for this Resource Kit and I also maintain the Unofficial 


information. 

In the previous article of this series you learned how to use the MDT database to customize the 

deployment of Windows 7 based on computer properties such as the MAC address or UUID of the 

target computer. In this article we'll learn how to use the MDT database to deploy Windows 7 

Enterprise edition together with an application (Microsoft Office 2007 Enterprise edition) based on the 

make and model of the target computer. 





Adding Office 2007 as an Application 

The powerful thing about Microsoft Deployment Toolkit is that you can use it to deploy Windows 

operating system images together with any applications, packages and drivers that may be needed by 

your users on their target computers. For this walkthrough, we're going to deploy Microsoft Office 

2007 Enterprise edition together with Windows 7 Enterprise edition, which is a typical scenario for 

information workers (IWs). Begin by inserting your Office DVD into the DVD drive of your MDT 

technician computer. Then open Deployment Workbench, expand your deployment share, right-click 

on the Applications node and select New Application (Figure 1): 

Figure 1: Step 1 of adding a new application to a deployment share 

Doing this launches the New Application Wizard as shown in Figure 2 below. We will choose the first 

option here, which copies the Office installation files from the Office DVD into a folder in our 

deployment share. 






On the next wizard page, we'll type Microsoft as the publisher and Office 2007 Enterprise as the 

descriptive name for the application; we'll leave the other two fields blank (Figure 3): 


On the next page, we will browse to select our DVD drive as the source directory where the 

installation files currently reside. Note that the option to move the files to the deployment share 

instead of copying them is grayed out—this is because you can not move files from a DVD, you have 

to copy them (Figure 4): 






On the next page, we will accept Microsoft Office 2007 Enterprise as the name of the folder that will 

be created within our deployment share to host the application's installation files (Figure 5): 


On the next page, we will type setup.exe as the command that will be used to install the application on 

our target computers (Figure 6): 






Once we have finished walking through the wizard, the new application is displayed in the 

Deployment Workbench within the Applications folder of our deployment share (Figure 7): 

Figure 7: Office has been added to the deployment share as an application to be deployed 

You are done adding Office as an application in MDT. 

Customizing Office 2007 for Installation 

Before you deploy an application using MDT, you may need to further configure the application by 

opening its properties from the Workbench. This is particularly true for Office 2007, which includes its 

own special Office Customization Tool (OCT) you can use to customize your installation Office prior to 

deploying it. The OCT lets you customize Office and save your customizations in a Windows Installer 

(MSI) Patch file having an .msp file extension. Once you create this .msp file, you then save it in the 

Updates folder of your deployment share. Then, when Office is being installed on the target computer, 

the Office installation program (setup.exe) looks for an .msp file in the Updates folder of your 

deployment share, and if it finds one it applies the customizations contained in the .msp file during the 

installation of Office. For more detailed information concerning customizing Office 2007 installations 

using the OCT, see this article on Microsoft TechNet. 

To customize how Office will be deployed by MDT, right-click on the application in the Applications 

folder in the previous screenshot and select Properties. This opens the application's properties sheet, 

which has several different tabs. We'll learn more about what these tabs can be used for in a future 

article, but for now let's select the Office Products tab as shown in Figure 8: 

Figure 8: Step 1 of configuring Office for deployment using the OCT 





Now, on the Office Products tab, click the Office Customization Tool button. An information dialog box 

will be displayed indicating where you need to save the .msp file you will create using the OCT (Figure 

9): 


Clicking OK closes the dialog box and opens the OCT, which prompts you to create a new .msp file or 

open an existing one. We'll select the first option to create a new .msp file (Figure 10): 


When you click OK, the Select Product box closes and you're presented with the main screen of the 

OCT (see Figure 11). By clicking on various items on the left, you will be able to customize many 

different aspects of how Office will be customized during its deployment. 






To deploy Office unattended using MDT, we only need to configure the Licensing And User Interface 

page of the OCT. To do this, make the following customizations as shown in Figure 12 below: 

Type your Office 2007 product key into the textbox. 

Select the checkbox for accepting the EULA. 

Change the Display Level to None, which enables Office Setup to run silently without displaying 

any user interface. 

Make sure the Completion Notice checkbox is cleared—doing this will prevent Office Setup from 

displaying a message to the user when the installation is finished. 

Make sure the Suppress Modal checkbox is selected—doing this will prevent Setup from 

displaying error messages or other dialog boxes that could interrupt the installation. 

The No Cancel checkbox can be used to prevent the user from being able to cancel the 

installation by clicking the close gadget on the installation UI, but since the Display Level is set to 

None in this example, there is no installation UI so it doesn't really matter whether you select or 

clear this checkbox (we'll clear it anyways). 






Now let's save our customizations as an .msp file. To do this, select File, Save As from the OCT menu. 

Then, in the Save As dialog, browse to the following folder: 

\DeploymentShare$\Applications\Microsoft Office 2007 Enterprise\Updates 

Now type custom as the name for the .msp file you will create (Figure 13): 



You are done customizing Office for deployment. 




Determining the Make/Model of a Target Computer 

Now remember that our goal is to deploy Windows 7 together with Office 2007 to computers that have 

a certain make and model. How can you determine the make and model of a specific computer? If this 

information has not been provided to you by the vendor or displayed on a sticker on the outside or 

inside of the case, and if a Windows operating system is already installed on the computer you can 

customize the DisplayClassProperties.vbs script used in the previous article of this series to do this. 

Simply take the script in that article and replace the following line: 



with this instead: 

strWMIQuery = ":Win32_ComputerSystem.Name='INSERT'" 

Next, substitute INSERT with the actual computer name of the computer, which can be found using 

the System utility in Control Panel and for this example is SEA-DESK-115. 

Now use cscript to run the script to display the values of all the properties of the 

Win32_ComputerSystem WMI class: 

c:\scripts>cscript DisplayClassProperties.vbs 

Microsoft (R) Windows Script Host Version 5.8 

Copyright (C) Microsoft Corporation. All rights reserved. 

Number of properties of :Win32_ComputerSystem.Name='SEA-DESK-115' class is 58 

Property: AdminPasswordStatus Value: 3 

Property: AutomaticManagedPagefile Value: True 

Property: AutomaticResetBootOption Value: True 

Property: AutomaticResetCapability Value: True 

Property: BootOptionOnLimit Value: 

Property: BootOptionOnWatchDog Value: 

Property: BootROMSupported Value: True 

Property: BootupState Value: Normal boot 

Property: Caption Value: SEA-UUID-TEST 

Property: ChassisBootupState Value: 3 

Property: CreationClassName Value: Win32_ComputerSystem 

Property: CurrentTimeZone Value: -360 

Property: DaylightInEffect Value: False 

Property: Description Value: AT/AT COMPATIBLE 

Property: DNSHostName Value: SEA-UUID-TEST 

Property: Domain Value: contoso.com 

Property: DomainRole Value: 1 

Property: EnableDaylightSavingsTime Value: True 

Property: FrontPanelResetStatus Value: 3 

Property: InfraredSupported Value: False 

Property: InitialLoadInfo Value: 

Property: InstallDate Value: 

Property: KeyboardPasswordStatus Value: 3 

Property: LastLoadInfo Value: 

Property: Manufacturer Value: HP Pavilion 061 





Property: Model Value: PY196AV-ABA a1130e 

Property: Name Value: SEA-UUID-TEST 

Property: NameFormat Value: 

Property: NetworkServerModeEnabled Value: True 

Property: NumberOfLogicalProcessors Value: 1 

Property: NumberOfProcessors Value: 1 

Property: OEMLogoBitmap Value: 

Property: PartOfDomain Value: True 

Property: PauseAfterReset Value: -1 

Property: PCSystemType Value: 1 

Property: PowerManagementCapabilities Value: 

Property: PowerManagementSupported Value: 

Property: PowerOnPasswordStatus Value: 3 

Property: PowerState Value: 0 

Property: PowerSupplyState Value: 3 

Property: PrimaryOwnerContact Value: 

Property: PrimaryOwnerName Value: Windows User 

Property: ResetCapability Value: 1 

Property: ResetCount Value: -1 

Property: ResetLimit Value: -1 

Property: Status Value: OK 

Property: SupportContactDescription Value: 

Property: SystemStartupDelay Value: 

Property: SystemStartupOptions Value: 

Property: SystemStartupSetting Value: 

Property: SystemType Value: x64-based PC 

Property: ThermalState Value: 3 

Property: TotalPhysicalMemory Value: 2078859264 

Property: UserName Value: SEA-UUID-TEST\Administrator 

Property: WakeUpType Value: 6 

Property: Workgroup Value: 

Now, from the above script output of property/value pairs, examine these two lines: 

Property: Manufacturer Value: HP Pavilion 061 

Property: Model Value: PY196AV-ABA a1130e 

The Win32_ComputerSystem.Manufacturer WMI property corresponds to the Make property in MDT, 

and the Win32_ComputerSystem.Model WMI property corresponds to the Model property in MDT. In 

other words, the Make of this particular computer is HP Pavilion 061 and its Model is PY196AV-ABA 

a1130e as far as MDT is concerned. 

Customizing Deployment Based on Make/Model 

To make use of such Make/Model information and deploy Windows 7 together with Office 2007 to 

computers having this particular Make and Model, we now need to create a new Make And Model 

record in the MDT database that specifies this particular Make and Model and is configured to deploy 

Office 2007 to these computers. To do this, expand the Database node for your deployment share in 

the Workbench, right-click on Make And Model, and select New (Figure 14): 





Figure 14: Step 1 of creating a MDT DB record for Make/Model deployment of Office 

In the Properties sheet for the new record, type the Make and Model of the target computers (Figure 

15): 



Next, click the Applications tab (Figure 16): 





Click Add and select Microsoft Office 2007 Enterprise from the list of applications you can deploy to 

computers that match the Make/Model specified in this record (Figure 17): 






Click OK to return to the Applications tab which will now show Microsoft Office 2007 Enterprise 

(Figure 18): 


Click OK to apply the changes and create the new record in the MDT DB. The new record will now be 

displayed under Make And Model in the Workbench (Figure 19): 

Figure 19: A new MDT DB record for Make/Model deployment of Office has been created 

At this point we are ready to begin our deployment. Insert your LiteTouch_x64 CD into a computer 

having the specified Make/Model and turn the computer on. The Windows Deployment Wizard will run 





completely unattended and Windows 7 will be installed on the computer in the usual way. Once 

Windows 7 has been installed, the desktop will be displayed and a progress dialog will indicate that 

Office is being installed (Figure 20): 

Figure 20: Office is installed after Windows has been installed 

When Office Setup is finished, you should be able to launch Office programs from your Start menu 

(Figure 21): 

Figure 21: Office 2007 has been deployed together with Windows 7 using MDT 





Final Note 

Using Make and Model to deploy Windows using MDT is not as simple as using Computer and 

specifying the UUIDs or MAC addresses as described in the previous article of this series. To 

understand some of the complexities involved in using Make/Model for MDT deployment and to learn 

about some workarounds, see this article on The Deployment Guys blog. 

Part 18: Determining the UUID of a Computer 




information. 

In Part 16 of this series you learned how to use the MDT database to customize the deployment of 

Windows 7 based on the UUID of each target computer. In that article you also learned how to use 

WMI to determine the UUID of a computer if this UUID is not displayed in the system's BIOS or 

accompanying documentation. The method we used to do this however was a bit messy, plus the 

computer whose UUID you want to determine must already have had a Windows operating system 

installed on it. 

This brings up a question: Can you use WMI to determine the UUID of a computer if there is no 

operating system installed on it? The answer is Yes. To do this, we first need to clean up the scripting 

stuff we did in the last two articles. Then we need to build a custom Windows Preinstallation 

Environment (WinPE) image, add the scripts to this image, and burn the image to CD media. You can 

then use this CD to boot a bare-metal computer into WinPE and run the script to determine the 

system's UUID. 

And that's what this present article and the next one are all about. First, in this article we'll create a 

clean little script that will display a computer's UUID without any fiddling around. Then in the next 

article we'll learn how to create a customized WinPE "tools" CD you can use to run the script on a 

bare-metal system that has no operating system installed in order to determine the system's UUID. 

Once you've used your WinPE CD to run the script on a number of target computers, you can enter 

these UUIDs into the MDT database and deploy customized Windows images to each computer as 

desired. 

Tip: If you are new to WMI scripting, check out my 14-part introductory series of articles on 

WindowsNetworking.com titled Managing Windows Networks Using Scripts. 

Script to Determine the UUID of a Computer 

In Part 16 of this series we saw how we could determine the UUID of a computer using WMI as 

follows: 

1. We began with the DisplayClassProperties.vbs script from Part 13 of my earlier series of 

scripting articles that displays the names of all the properties of a WMI class together with the 

values of these properties. 

2. Next we ran WBEMTEST on the computer to determine how we need to customize the 

strWMIQuery = line of our script so that the script will work on that particular computer. 





The actual steps to do this are: (a) run WBEMTEST (b) connect to root\cimv2 namespace (c) 

click Enum Instances (d) type Win32_ComputerSystemProduct (e) press OK. The resulting 

output from WBEMTEST is then used as the value of in the above line of our script. 

And this must be done manually as WBEMTEST output doesn't support copy to clipboard! 

3. Then once the script was customized, we ran it on the computer and included as part of the 

script's output was the computer's UUID. 

This was all a bit messy of course—we'd rather not have to run WBEMTEST on the computer or have 

to customize the script each time we have to run it. And we'd rather just get the script to output the 

computer's UUID and not a bunch of other stuff as well. 

Here's how we can do this. We'll begin with the modified DisplayClassProperties.vbs script taken from 

Part 16 of this series: 

' DisplayClassProperties.vbs 

' Used to find the UUID of a specific desktop computer 

' By Mitch Tulloch (www.mtit.com) 

Option Explicit 

On Error Resume Next 

Dim strComputer 

Dim strWMINamespace 

Dim strWMIQuery 

Dim objWMIService 

Dim colItems 

Dim objItem 






strWMIQuery) 

WScript.Echo "Number of properties of " & strWMIQuery & " class is " & 

objWMIService.Properties_.count 


Wscript.Echo "Property: " & objItem.name & vbTab & "Value: " & objItem.value 

Next 

Now, to accomplish what WBEMTEST does and return the instances of the 

Win32_ComputerSystemProduct class, we'll need to use the SWbemServices.InstancesOf method of 

the SWbemServices object. To figure out how to do this, I simply adapted the following script from a 

page of the good old Windows 2000 Scripting Guide (see here): 


Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") 

Set colSWbemObjectSet = objSWbemServices.ExecQuery _ 

("SELECT * FROM Win32_Service") 

For Each objSWbemObject In colSWbemObjectSet 

Wscript.Echo "Name: " & objSWbemObject.Name 

Next 

My customized version of the above script looks like this: 







Set colSWbemObjectSet = objSWbemServices.ExecQuery _ 

("SELECT * FROM Win32_ComputerSystemProduct") 


strIdentifyingNumber = objSWbemObject.IdentifyingNumber 

strName = objSWbemObject.Name 

strVersion = objSWbemObject.Version 

Next 

Wscript.Echo "IdentifyingNumber: " & strIdentifyingNumber 

Wscript.Echo "Name: " & strName 

Wscript.Echo "Version: " & strVersion 

The reason I need the above script to determine the values of the three properties IdentifyingNumber, 

Name and Version is because the Win32_ComputerSystemProduct class has three key properties, 

namely (you guessed it) IdentifyingNumber, Name and Version. To see this, refer to the 

documentation page for this class on MSDN. Remember that a key property is a property that 

provides a unique identifier for an instance of a class, and to connect to an instance of a class, you 

need to specify a particular instance by using the key property of the class. Key properties are marked 

with the "Key" qualifier in MSDN documentation—refer back to Part 13 of my earlier series of scripting 

articles for more information concerning key properties. 

Now I simply need to merge the above customized script with my earlier DisplayClassProperties.vbs 

script in order to create the following new script which I've named UUID.vbs (note that I've simplified 

this script by omitting variable definitions and error handling): 

'UUID.vbs 

'Displays the UUID of a computer 

'By Mitch Tulloch (www.mtit.com) 




Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM 

Win32_ComputerSystemProduct") 


strIdentifyingNumber = objSWbemObject.IdentifyingNumber 

strName = objSWbemObject.Name 

strVersion = objSWbemObject.Version 

Next 

strWMIQuery = ":Win32_ComputerSystemProduct.IdentifyingNumber='" & 

strIdentifyingNumber _ 

& "',Name='" & strName & "',Version='" & strVersion & chr(39) 


strWMIQuery) 


If objItem.name = "UUID" Then 

Wscript.Echo objItem.name & " = " & objItem.value 

End If 

Next 

Note that the tricky part here is making sure the quotes are correct in the strWMIQuery = 

statement. For instance, the statement ends with & chr(39) which appends the single quote needed to 

properly complete the syntax of the statement. It took some fiddling to get this to work—the trick that 

helped me was to temporarily insert a Wscript.echo strWmiQuery statement immediately after the 





strWMIQuery = statement so I could run the script and output the contents of the string to see 

whether the string had the correct syntax, then make a change and run the script again, and so on 

until I got the syntax right. 

Testing the Script 

Now let's see if our script works by running it from the command-line on a computer that has Windows 

XP installed on it (Figure 1): 

Figure 1: Running UUID.vbs on a computer that has an operating system 

Let us make our script even easier to run by creating an accompanying batch file named UUID.bat 

that reads as follows: 

@ECHO OFF 

cscript.exe //nologo UUID.vbs 

This makes it easier to run the script and also makes the output cleaner (Figure 2): 

Figure 2: Running UUID.bat on a computer that has an operating system 





Conclusion 

Now that our script is ready, we need to build a WinPE image and include our script in this image so 

we can run our script on bare-metal systems. You will learn how to do this in the next article of this 

series. 

Part 19: Building a Custom WinPE Tools CD 



Support Site for the Windows 7 Resource Kit with answers to questions posted by readers, as well as 

links to the latest resources on Windows 7 deployment, administration and troubleshooting. 

In Part 18 of this series you learned how to create a WMI script that can be used to determine the 

UUID of a computer. The reason you may want to do this is because you wish to use the MDT 

database to customize the deployment of Windows 7 based on the UUID of each target computer 

(see Part 16 of this series for how to do this). Now, you can of course run this script on a computer 

that has a Windows operating system installed, but how can you determine the UUID of a bare-metal 

system, that is, a computer that has no operating system? The simple answer is to build a Windows 

PE "tools" CD that includes the script. Then, using this CD you can boot a bare-metal system, run the 

script, and display the system's UUID. And that is what this article is about. 

Note: The steps for building a custom Windows PE image have changed in Windows 7 from Windows 

Vista. To learn how to build Windows PE 2.1 (Windows Vista SP1 and later) see my earlier article 

titled Deploying Vista – Part 11: Working with Windows PE. 

Step 1: Create the Build Environment 

To create the Windows PE 3.0 build environment, log on to a technician computer on which Windows 

AIK 2.0 has been installed. Then click Start, All Programs, Windows AIK, right-click on Deployment 

Command Prompt and select Run As Administrator. The Deployment Tools Command Prompt opens 

(Figure 1): 

Figure 1: The Deployment Tools Command Prompt 





In this walkthrough, we will set up a build environment for creating a 64-bit Windows PE image. To do 

this, type the following command: 

copype.cmd amd64 C:\BUILDPE 

Here \BUILDPE is a folder that will be created on the root of C: drive on our technician computer. This 

folder will be used to contain our build environment. The output of the command is shown in Figure 2: 

Figure 2: Creating a Folder to Contain the Build Environment 

Let us examine the build environment in Windows Explorer (Figure 3): 





Figure 3 

The folders and files in the root of our build folder are as follows: 

\ISO folder contains the files needed to build an .iso file of Windows PE that we can burn to a CD 

\mount folder is an empty folder where we will mount our image using DISM.exe so we can 

service it 

etfsboot is a program we can use to create the boot sector for our Windows CD 

efisys.bin is used instead of etfsboot on systems that boot using Extensible Firmware Interface 

(EFI) 

efisys_noprompt.bin is used instead of etfsboot on IA64 systems 

winpe.wim is a base Windows PE image file which we can customize as desired 

To finish setting up our Windows PE build environment, use the copy command like this: 

copy C:\BUILDPE\winpe.wim C:\BUILDPE\ISO\sources\boot.wim 

This command copies the base Windows PE image (winpe.wim) from the root folder \BUILDPE to the 

\ISO\sources folder and renames it boot.wim (Figure 4): 





Figure 4: Copying the Base Windows PE Image to the \ISO\sources Folder and Renaming it boot.wim 

Let us verify the result using Windows Explorer (Figure 5): 

Figure 5: Copy of the Windows PE Base Image. 

Step 2: Mount the Base Image 

Before you can service your Windows PE image, you need to mount it using the DISM command. To 

do this, we use the /mount-wim command-line option as follows: 





dism /mount-wim /wimfile:C:\BUILDPE\ISO\sources\boot.wim /index:1 

/mountdir:C:\BUILDPE\mount 

The above command mounts the Windows image contained in the boot.wim file to the \mount folder of 

our build environment (Figure 6): 

Figure 6: Mounting the Windows PE Base Image So You Can Service It 

Tip: For more information about the DISM command which is new in Windows 7, see Part 2 of this 

series. 

Let us examine the mounted base Windows PE image in Windows Explorer (Figure 7): 

Figure 7: The Mounted Base Windows PE Image 





Note that the folder structure of a mounted Windows image looks just like that of an installed Windows 

operating system. 

Next, we are going to service (customize) our mounted base Windows PE image in two ways: 

By adding support for running WMI scripts 

By adding our UUID scripts to the image 

Step 3: Add Support for Running WMI Scripts 

Before you can run WMI scripts from within Windows PE, you must add packages that provide such 

functionality to Windows PE. We will begin by adding the WinPE-WMI Feature Pack, which provides 

support for Windows Management Instrumentation (WMI) from within Windows PE. To do this, you 

need to use the /add-package command-line option of DISM. You also need to know where this 

package is located within the Windows AIK folder structure on your technician computer. Here is the 

command you use to do this: 

dism /image:C:\BUILDPE\mount /add-package /packagepath:"C:\Program Files\Windows 

AIK\Tools\PETools\amd64\WinPE_FPs\winpe-wmi.cab" 

This command adds the package contained in the file winpe-wmi.cab to your mounted Windows PE 

image. Figure 8 shows the result of running this command: 

Figure 8: Adding WMI Support to Windows PE (step 1) 

In addition to adding the package, you must also add the corresponding Language Pack (winpewmi_en-us.cab) 

for that package. For US English (en-us) this is done as follows: 

dism /image:C:\BUILDPE\mount /add-package /packagepath:"C:\Program Files\Windows 

AIK\Tools\PETools\amd64\WinPE_FPs\en-us\winpe-wmi_en-us.cab" 

Figure 9 shows this being done: 





Figure 9: Adding WMI Support to Windows PE (step 2) 

Although we have now finished adding WMI support to our Windows PE image, we still won't be able 

to run WMI scripts from within Windows PE unless we also add the WinPE-Scripting Feature Pack 

(winpe-scripting.cab) and its corresponding Language Pack (winpe-scripting_en-us.cab) to our image. 

Figure 10 shows how this is done: 

Figure 10: Adding Scripting Support to Windows PE 

We can use the /get-packages command-line option of DISM to verify that the packages have in fact 

been added to the image (Figure 11): 





Figure 11: Verifying that the Packages have been added to the Image 

Note that the state of each package is displayed as Install Pending. This is because the changes we 

are making have not yet been committed to the image. 

Step 4: Adding the Scripts to the Image 

Let's now add the two scripts (UUID.vbs and UUID.bat) we created in the previous article of this series 

to our mounted Windows PE image. We can use the copy command to do this by copying the scripts 

from a USB flash drive to the \Windows\System32 folder within our mounted image (Figure 12): 

Figure 12: Copying the Scripts to the Mounted Windows PE Image 





We can use Windows Explorer to verify that the scripts have been copied to our mounted image 

(Figure 13): 

Figure 13: The Two Scripts have been Copied to the \Windows\System32 Folder of the Mounted 

Windows PE Image 

Why copy these scripts to the \Windows\System32 folder? Because that way the scripts will be 

included as part of the Windows PE RAM disk that is loaded into memory and accessible as X: drive 

from the Windows PE command prompt. If we copied the scripts instead to the \ISO folder of our build 

environment, the scripts would be included as part of the Windows PE CD and we would need to 

change to the CD drive letter before we could run the scripts from within Windows PE. So copying 

them to the \Windows\System32 folder makes it easier to run the scripts from within Windows PE. 

Note: If the scripts or tools you are adding to Windows PE require additional memory, use the /setscratchspace 

command-line option of DISM to allocate 64, 128, 256 or even 512 MB of additional 

memory to Windows PE (the default allocation is 32 MB). 

Step 5: Commit Changes and Dismount the Image 

We have now serviced (customized) the base Windows PE image by adding packages and scripts to 

the image. We can use the \unmount-wim command-line option of DISM to do this: 

dism /unmount-wim /mountdir:C:\BUILDPE\mount /commit 





Figure 14 shows the result of running this command: 

Figure 14: Dismounting the Image after Committing the Changes 

Step 6: Create the Windows PE .iso Image 

We now need to transform our customized Windows PE image in the \BUILDPE folder into an .iso file 

that we can burn onto writable CD media. To do this, we can use the oscdimg command as follows: 

oscdimg –n –bC:\BUILDPE\etfsboot.com C:\BUILDPE\ISO C:\BUILDPE\WMI-PE-CD.iso 

This adds the CD volume boot sector to the Windows PE image and transforms it into an .iso file, 

which we have here named WMI-PE-CD.iso (Figure 15): 

Figure 15: Using oscdimg to Create an .iso file of Windows PE 





Use Windows Explorer to verify that the .iso image has been created (Figure 16): 

Figure 16: An .iso Image File has been Created Using oscdimg from the Customized Windows 

PE Build Environment 

Now copy this .iso file to a computer that has a CD burner and burn it the file to the CD. 

Step 7: Testing the Result 

We are finally ready to test our custom WinPE "tools" CD. Turn on a bare-metal system, insert the CD 

and press a key when asked whether you want to boot the system from its CD drive. Once Windows 

PE has loaded and initialized, you will be presented with an X:\Windows\System32> command prompt. 

Simply type uuid at this command prompt and watch the UUID of the computer suddenly appear 

(Figure 17): 

Figure 17: Using UUID.bat and UUID.vbs on a Custom Windows PE Tools CD to Display the 

UUID of a Bare-metal System 





After performing Step 7 on a bunch of systems and copying down the results, you can create new 

entries in the MDT 2010 database that let you deploy customized Windows PE images to your 

computers—see Part 16 of this series for how to do this. 

Part 20: Securing MDT (Part 1) 





Credentials in Bootstrap.ini 

I'll return to explaining how to configure and use the MDT database soon, but at this point I would like 

to bring up the issue of MDT security. So far in this series of articles on deploying Windows 7 we 

haven't been very concerned about security. For instance, the Bootstrap.ini file we have been using 

for our deployment share in these articles looks like this: 

[Settings] 


[Default] 







The user account specified by the UserID, UserPassword and UserDomain properties in Bootstrap.ini 

is used by the Windows Deployment Wizard running on the target computer to connect to the 

deployment share on the MDT server and access the contents of this share. Until now we have been 

using the default Administrator account in the domain for this purpose. There are two reasons why 

this is not a good idea. 

First, if you are initiating your Lite Touch (LTI) deployment manually by booting your target computers 

using your LiteTouchPE CD, you should be aware of the fact that your Bootstrap.ini file is actually 

present on this CD. To see this, let's begin by examining the contents of a LiteTouchPE CD in 

Windows Explorer (Figure 1): 





Figure 1: Contents of a LiteTouchPE CD as viewed in in Windows Explorer 

Note that most of the CD consists of a Windows image file Boot.wim, which is found in the \sources 

folder on your CD. (The \boot folder contains only some files used to enable the CD to boot and 

mount this image.) Now, let us say you left your LiteTouchPE CD lying around and someone stole it. 

The thief could then install Windows AIK 2.0 on a computer and mount the Boot.wim file on this CD to 

an empty folder using the Imagex command as follows (Figure 2): 

Figure 2: Mounting the Boot.wim file from a LiteTouchPE CD 





Once the Boot.wim file has been mounted to the empty folder (here named C:\PEbootfiles) the thief 

could then browse the contents of the mounted image using Windows Explorer (Figure 3): 

Figure 3: Your Bootstrap.ini file is present in the Boot.wim file of your LiteTouchPE CD 

The thief could then open Bootstrap.ini in Notepad (Figure 4): 

Figure 4: This Bootstrap.ini file contains administrative credentials for your domain! 





At this point your entire Windows infrastructure has been compromised since the thief has obtained 

Domain Admins credentials. So, if you are going to use Domain Admin credentials in your 

Bootstrap.ini file, you obviously need to protect your LiteTouchPE CD (or DVD or USB flash drive 

depending on the boot media you are using to initiate LTI deployment). In other words, do not let 

unauthorized persons have access to such media. 

The other security issue concerns transmissions of credentials over the network. When you boot a 

target computer into Windows PE using your LiteTouchPE boot media, the computer typically 

acquires an IP from a DHCP server and then tries to establish a connection with the deployment 

share on your MDT server. Now, if you are using MDT in a New Computer scenario (that is, to 

perform a bare metal deployment onto a target computer that currently has no operating system) then 

Kerberos or NTLM authentication is used to securely pass the credentials indicated in the 

Bootstrap.ini file from the target computer to the MDT server, and someone sniffing the network would 

not be able to steal these credentials. But if you using MDT in a Refresh Computer scenario (that is, 

to re-image an existing computer and save/restore user state information) then Bootstrap.ini is 

processed from the deployment share and the credentials are passed over the network in clear text. 

This means that someone sniffing the network in this scenario could steal the credentials specified in 

Bootstrap.ini, and if these are Domain Admins credentials then your network is compromised. 

Of course, if you're using MDT in a test environment or in a secure lab that mirrors your production 

network but has a different domain, then it's fine to leave the default Administrator account for the 

domain in Bootstrap.ini as shown in Figure 4 above. If you're using MDT in a production environment 

however, you probably don’t want to do this. We'll see one possible solution to this issue in a 

moment. 

Credentials in CustomSettings.ini 

The other place credentials are specified in MDT is in the CustomSettings.ini file for your deployment 

share. Specifically, the following portion of a CustomSettings.ini file is used to automate the process 

of joining target computers to the domain during the final phase of deployment: 





Note that we have been using the same account (CONTOSO\Administrator) in these articles for both 

Bootstrap.ini (to allow the target computer to access the deployment share) and CustomSettings.ini 

(to join the target computer to the domain once the install has completed). Now your 

CustomSettings.ini file is not present on your LiteTouchPE boot media, your Boostrap.ini file, so that's 

not an issue. But in all deployment scenarios where automated domain-join is performed, the above 

info contained in CustomSettings.ini is transmitted over the network from the MDT server to the target 

machine in clear text. This means that if you use a Domain Admins account to automatically join 

deployed computers to your domain, someone sniffing your network could easily compromise the 

security of your entire network. The problem however is that, generally speaking, admin-level 

credentials are required if you want to join a computer to a domain. There are some workarounds to 

this issue however as we'll shortly see. Once again however, if you're using MDT in a test 

environment or in a secure lab, you can leave the default Administrator account for the domain in 

CustomSettings.ini as shown above. 





Using Separate Build and Join Accounts 

If we are going to use our MDT server to deploy Windows in a production environment, the first thing 

we can do to make MDT more secure is to use separate user accounts for connecting to the 

deployment share and for joining computers to the domain. In this example we will create two new 

user accounts: 

mdt_build This "build" account will be used to enable target computers to connect to our 


mdt_join This "join" account will be used to automatically join target computers to the domain as 

the deployment process finishes on the computers. 

When you create these accounts in Active Directory Users and Computers, they are automatically 

assigned membership in the Domain Users group. Let's leave it at that for the moment—do not add 

these accounts to the Domain Admins group. 

Now let us examine the ACLs on our deployment share. Figure 5 indicates that the Users group on 

the MDT server, which includes the Domain users group as a member, has Read & Execute 

permission on the share: 

Figure 5: ACL of Users group for a deployment share 





Now if all you are using this deployment share is for installing Windows on target computers, then 

Read & Execute permission is sufficient since it allows the target computer to read files contained in 

the share and run scripts and programs in the share. In other words, our build account, which is 

specified in Bootstrap.ini, can be a simple Domain Users account—it does not have to be a Domain 

Admins account. That is good news! So let's go ahead and change the account specified by the 

UserID property in our Bootstrap.ini file from Administrator to mdt_build. Once we've done this, our 

new Bootstrap.ini file looks like Figure 6: 

Figure 6: Bootstrap.ini now specifies a Domain Users account 

Do not forget that after you make changes to your Bootstrap.ini file you need to update your 

deployment share (Figure 7): 

Figure 7: Always update your deployment share after modifying Bootstrap.ini 





And do not forget also that after updating your deployment share you'll need to burn a new 

LiteTouchPE CD since the Bootstrap.ini file is included on it. 

So far, so good. Now the issue of using the join account is a bit more complicated, so we'll get to this 

later. Meanwhile, I need to mention to you that the change you've just made in your Bootstrap.ini file 

has broken something for if you now try and configure your MDT database to deploy Windows 

differently to different computers based on the computer's UUID, MAC address, or other machine 

property as described earlier in Part 16 and Part 17 of this series, you'll discover that this no longer 

works! Specifically, you'll be able to deploy Windows 7 using MDT but any customizations you've 

specified in the MDT database won't be applied (and the target computer won't join the domain either). 

You may or may not see an error message displayed at the end of the deployment process, but either 

way if you later examine the BDD.log in the %WINDIR%\Temp\Deployment logs folder on a deployed 

target computer, you'll see the following error: 

ZTI error opening SQL Connection: Cannot open database "MDT" requested by 

the login. The login failed. (-2147467259) 

We will see how to fix this issue in the next article of this series where we'll also examine the issue of 

securely joining the domain as well. 

Part 21: Securing MDT (Part 2) 





In the previous article of this series, we examined the security issues involving two user accounts 

used by MDT: 

The account specified in Bootstrap.ini that is used by target computers to connect to the 

deployment share on your MDT server 

The account specified in CustomSettings.ini that is used by target computers to join the domain at 

the completion of the install. 

I indicated that in a simple lab environment it's OK to use the default Administrator account for the 

domain for both of these purposes. However, for security reasons in your production environment you 

will probably want to use separate accounts for each of these purposes, and preferably ordinary 

Domain Users accounts instead of Domain Admins accounts. So what we did in the previous article is 

create two new Domain Users accounts: mdt_build for our Bootstrap.ini file and mdt_join for our 

CustomSettings.ini file. After doing this we updated our deployment share because our Bootstrap.ini 

file had changed, and then we burned the resulting LiteTouchPE_x64.iso file to CD media. If we then 

boot our target computers using this CD, MDT will deploy Windows 7 to them but any customizations 

entered into the MDT database won't be applied and an SQL Connection error will result. The problem 

is that our new account CONTOSO\mdt_build has not been granted rights to access our MDT 

database using Windows Integrated Security. This present article shows you how to resolve this SQL 

issue, and it also describes how to ensure your domain-joins are (reasonably) secure. 





Installing SQL Server Management Studio 

To modify access rights to the MDT database on our SQL Server, we can use SQL Server 

Management Studio. In this series of articles we are using SQL Server 2008 Express Edition SP1 

which we installed on our MDT server in article 15 of this series. To do this, we will install Microsoft 

SQL Server 2008 Management Studio Express on an administrator workstation running Windows 7 

and the use it to grant the necessary rights to our CONTOSO\mdt_build account. Microsoft SQL 

Server 2008 Management Studio Express is a free download from Microsoft. 

Begin by double-clicking on the downloaded installation file SQLManagementStudio_x64_ENU.exe. 

Doing this brings up a warning dialog that you will need to install Service Pack 1 afterwards (Figure 1): 

Figure 1: Step 1 of installing SQL Server 2008 Management Studio Express 

Clicking Run Program opens the SQL Server Installation Center (Figure 2): 






Click Installation at the left to display the installation options (Figure 3): 


Clicking the first option on this page runs the Setup Support Rules to verify the install can proceed 

(Figure 4): 

Figure 4: Step 4 of installing SQL Server 2008 Management Studio Express. 





The next screen indicates that no product key is required for the install (Figure 5): 


Accept the EULA next, then click Install. The Setup Support Rules are installed (Figure 6): 






On the Feature Selection page, make sure Management Studio – Basic is selected (Figure 7): 


Proceed through the remaining steps until the install is complete (Figure 8): 






Now download SQL Server 2008 Service Pack 1 and double-click on the installation file 

SQLServer2008SP1-KB968369-x64-ENU to begin the installation. Once again the SQL Server 

Installation Center is displayed, and after clicking on the first option the Welcome page is displayed 

and Setup the Support Rules run (Figure 9): 

Figure 9: installing SQL Server 2008 Service Pack 1 

Then proceed through the installation of SP1 accepting all the defaults until the service pack has been 

installed. 

Configuring Access Rights Using SQL Server Management Studio 

Now let us use SQL Server Management Studio to configure the appropriate database access rights 

for the CONTOSO\mdt_build account. Begin by launching SQL Server Management Studio from the 

Start menu (Figure 10): 

Figure 10: Launching SQL Server Management Studio 





When the Connect To Server dialog appears, leave the Authentication method set at Windows 

Authentication (Figure 11): 

Figure 11: The Connect To Server dialog 

Click the Server Name field and then click Browse For More (Figure 12): 

Figure 12: Selecting the server name 





When the Browse For Servers dialog displays the available SQL Servers, select the local instance 

SQLEXPRESS that is installed on your MDT server (Figure 13): 

Figure 13: Select the local instance SQLEXPRESS 

Click OK to close the Browse For Servers dialog and return to the Connect To Server dialog. The 

instance SQLEXPRESS will be displayed as the SQL Server name (Figure 14): 

Figure 14: The instance SQLEXPRESS is selected as the SQL Server name 

Clicking Connect causes SQL Server Management to connect to the SQLEXPRESS instance on your 

MDT server and opens the Microsoft SQL Server Management Studio console (Figure 15): 





Figure 15: The Microsoft SQL Server Management Studio console 

In the Management Studio console, expand Security and then right-click on Logins and select New 

Login from the shortcut menu (Figure 16): 

Figure 16: Creating a new login for your SQL Server 





On the General page of the Login – New dialog, click Search and select the CONTOSO\mdt_build 

account from Active Directory. Once this is done, the account will be displayed in the Login Name field 

of this page. In addition, change the Default Database setting at the bottom of the page from master 

to MDT (since MDT was the name we gave to our database when we created it back in article 15 of 

this series). The General page of the Login – New dialog should now look like Figure 17: 

Figure 17: General page after settings have been configured 

Do not make any changes to the Server Roles page. On the User Mappings page, select the 

checkbox for MDT, then click the button and add CONTOSO\mdt_build as a user mapped to this login. 

Then select the checkbox for db_datareader to assign the db_datareader fixed database role to the 

CONTOSO\mdt_build account (Figure 18): 





Figure 18: Assigning the db_datareader fixed database role for MDT to CONTOSO\mdt_build 

Since members of the db_datareader fixed database role can read all data from all user tables, doing 

the above enables your target computers to access customizations in your MDT database. 

Do not make any changes to the remaining two pages (Securables and Status) of the Login – New 

dialog. Clicking OK displays the new login you created (Figure 19): 





Figure 19: The account CONTOSO\mdt_build has been granted read access to your MDT database 

You can now use the MDT database again to deploy Windows 7 in a customized fashion to your 

target computers as described in earlier articles in this series. 

Tip: If you need to grant multiple user accounts access to you MDT database, you can create a 

security group to contain these accounts and then use the above procedure to assign the 

db_datareader fixed database role to the group. 

Tip: For more information concerning SQL Server database-level roles, see this page on MSDN. 

Performing Domain-Joins Securely 

Let us finish off by addressing the issue of the mdt_join account which we have specified in 

CustomSettings.ini and which is used by MDT to join the target computer to the domain. If we leave 

this account as an ordinary Domain User, then MDT will be able to join the first few computers it 

installs into the domain but then will fail to join any others. This is because by default any user 

account that belongs to the Authenticated Users built-in identity (such as mdt_join) has the Add 

Workstations To A Domain user right assigned to it, which means the account can create up to 10 

computer accounts in the domain. So if you're only deploying 10 computers, you're in luck. Otherwise, 

to perform your domain-joins securely you can choose from one of the following ways to proceed: 





Method 1: Make your mdt_join account a member of the Domain Admins group. Then remove the 

DomainAdminPassword = line from your CustomSettings.ini file. The result will be that 

your Lite Touch installs will no longer be completely automated, and you'll have to walk around to 

each machine and type in the password for your mdt_join account when prompted for this (make sure 

no one is looking over your shoulder when you do this). More hassle, but more secure. 

Method 2: Make your mdt_join account a member of the Domain Admins group, do not make any 

changes to your CustomSettings.ini file, and ignore the security consequences that the domain-join 

credentials are transmitted in clear text over the network (and are temporarily stored in obfuscated 

form on each target computer during installation). If you choose this approach, it might be best to do 

your deployment on a weekend or evening when others aren't around. For extra security, change the 

password of your mdt_join immediately after you've finished your deployment. Don't forget to change 

the password in both Active Directory and in your CustomSettings.ini file. 

Method 3: Make your mdt_join account a member of the Domain Admins group. Omit the entire 

domain-join section (four lines) in your CustomSettings.ini file. Then in Deployment Workbench open 

the properties of the task sequence you are using, select the OS Info tab, and click Edit Unattend.xml 

to open the answer file MDT uses for deploying Windows using this task sequence. In the specialize 

pass, expand the Microsoft-Windows-UnattendedJoin component and configure the necessary 

settings in Identification and Credentials to join the target computer to the domain. The password you 

specify for the domain-join account here will be obfuscated but not encrypted, and the unattend.xml 

file will be cached on the target computer anyway during deployment, so this approach doesn't make 

deployment any more secure. 

Method 4: Omit the entire domain-join section (four lines) in your CustomSettings.ini file and deploy 

your target computers into a workgroup instead of a domain. Then join the machines to the domain 

later on either by doing it manually on each machine (if you only deployed a dozen or so computers) 

or by running a netdom join script using Group Policy (if you have lots of computers) or by some other 

method. 

Method 5: Grant the appropriate permissions for the mdt_join account to create and update computer 

accounts in Active Directory. This approach allows you to leave the mdt_join account as an ordinary 

Domain Users account which solves our security problems, but it takes some careful work in order to 

implement. Briefly, the steps you will need to perform are as follows: 

1. Open the Active Directory Users and Computers console. 

2. Select the View menu, then toggle on Advanced Features. 

3. Create an organizational unit (for example DeployedComputers) that will contain the computer 

accounts of newly deployed computers. (This way you won't have to modify the permissions 

on the default Computers container.) 

4. Open the properties of the DeployedComputers OU and select the Security tab. 

5. Click Advanced to open the Advanced Security Settings dialog for the OU. 

6. Click Add and add an ACE for your mdt_join account to the ACLs for this OU. 





7. In the Permission Entry dialog, assign Allow permissions (with scope set to This Object And All 

Descendant Objects) as follows: 

Create computer objects 

Delete computer objects 

8. Click OK, then click Add again and add a second ACE for your mdt_join account that assigns 

Allow permissions (with scope set to Descendant Computer Objects) as follows: 

Read all properties 

Write all properties 

Read permissions 

Write permissions 

Change password 

Reset password 

Validated write to DNS host name 

Validated write to service principal name 

9. Click OK repeatedly to close all open dialogs. 

Your mdt_join account should now be able to create new computer accounts and update these 

accounts as needed even though mdt_join is not a member of the Domain Admins group. Finally, in 

order to fully automate domain-joins using MDT you will need to add the following line to your 

CustomSettings.ini file: 

MachineObjectOU=OU= DeployedComputers,DC=CONTOSO,DC=COM 

One final approach you could follow would be to carry all the client computers on your production 

network into your secure lab, deploy Windows on them, and then carry them back into the offices 

where they belong. If you decide upon this approach however, be careful you do not injure your back! 

Part 22: Bulk Populating the MDT Database Using PowerShell 





In previous articles of this series we have examined how to configure and use the MDT database for 

Lite Touch deployments. For example, in article 16 we saw how you can use the Deployment 

Workbench to add new target computers to the database so you can customize deployment of 

Windows 7 based on the MAC address or UUID of each target computer. Doing this manually using 

the Deployment Workbench is tedious however—what if you have dozens or hundreds of computers 

you want to add to the database? 

That's where Windows PowerShell can be useful since it allows you to write scripts to automate 

tedious administrative tasks. While MDT 2010 now includes built-in PowerShell support, it doesn't 

include cmdlets for manipulating the MDT database. However, Michael Niehaus the developer of MDT 

has created a separate PowerShell module you can use to add PowerShell support for manipulating 

the MDT database. This article shows how to import this module and use PowerShell to take a 





spreadsheet of target computer information and bulk import this information into the MDT database as 

new computer items. 

Note: This article assumes that you're a PowerShell beginner with only minimal prior experience 

writing PowerShell scripts but with a bit of other programming experience. 

Installing the PowerShell Module for MDT 

Begin by downloading the compressed PowerShell module file named MDTDB.zip from this blog post 

by Michael Niehaus or by using this direct link. Right-click on the downloaded file, select Properties, 

and click Unblock. Then unzip the MDTDB.psm1 script file and copy it to a folder (here assumed to be 

C:\Scripts) on your MDT server. 

Now open the PowerShell command shell and type Get-ExecutionPolicy to view the current execution 

policy on your server (see here for more information): 

Figure 1: Viewing the current execution policy 

If the current execution policy is Restricted, the MDTDB.psm1 script won't run, so use the Set- 

ExecutionPolicy Unrestricted command to change the execution policy to Unrestricted like this: 

Figure 2: Changing the execution policy to Unrestricted. 





Now type Import-Module –name C:\Scripts\MDTDB.psm1 to add the MDT PowerShell module to the 

current PowerShell session as shown here: 

Figure 3: Importing the MDT PowerShell module. 

Note that the output from running the Import-Module command lists all the new PowerShell cmdlets 

we now have available for manipulating the MDT database. For example, in the figure above you can 

see the New-MDTComputer cmdlet which we'll be using later in this article to add new computers to 

the database. 

To verify that the module has been imported, type Get-Module as shown here: 

Figure 4: Verifying that the module has been imported 





Connecting to the MDT Database 

Now we need to connect our PowerShell session to the MDT database. To do this, we will use the 

Connect-MDTDatabase cmdlet. To view the syntax for this cmdlet, type Get-Help Connect- 

MDTDatabase as shown here: 

Figure 5: Viewing the syntax for Connect-MDTDatabase 

To connect to a MDT database named MDT on a SQL Server instance named SQLEXPRESS on a 

MDT server named SEA-MDT-01, type this command: 

Connect-MDTDatabase –sqlServer SEA-MDT-01 –instance SQLEXPRESS –database MDT 

Figure 6: Connecting to the MDT database 





Working with Computer Items 

Let us begin by seeing whether there are already any computer items in the MDT database. To do 

this, we are going to use the Get-MDTComputer cmdlet, so let us use Get-Help to view the syntax for 

this cmdlet: 

Figure 7: Viewing the syntax for Get-MDTComputer 

To list all existing computer items in the database, simply type Get-MDTComputer like this: 

Figure 8: Listing computers in the MDT database 





The Get-MDTComputer cmdlet shows that there is one computer item in the database and that this 

computer item has a MAC address of EE:EE:EE:FF:FF:FF and ID number 2. The ID number is the 

key field for computer items. In other words, each computer item in the database will have a unique ID 

number. 

If we open the Deployment Workbench we can see this computer item: 

Figure 9: Viewing a computer item using the Workbench 

We could delete this computer item using the Workbench, but let's do this using PowerShell instead. If 

desired type Get-Help Remove-MDTComputer to display the syntax for deleting computer items. then 

type Remove-MDTComputer –id 2 –verbose to delete the computer item and display verbose 

details concerning the operation: 

Figure 10: Removing a computer item from the database 





Importing Computers into the Database 

Now let us bulk import some computers into the database. Begin by creating an Excel spreadsheet 

with various columns for the name, UUID, MAC address and other properties of these computers. 

Each row of the spreadsheet will correspond to a single computer. For this walkthrough I've created a 

spreadsheet of a few computers in my lab: 

Figure 11: Create a spreadsheet for your target computers 

Now export this spreadsheet as a comma-delimited (CSV) text file (named C:\Data\machines.txt) 

which you can open in Notepad to view: 

Figure 12: CSV file for target computers 

Now use Import-Csv cmdlet to import the CSV file and assign it to the variable $machines like this: 

$machines = Import-Csv C:\Data\machines.txt 





Figure 13: Importing the CSV file into a variable 

Typing $machines displays the imported information, which is stored as an array: 

Figure 14: The computer information is stored as an array 





You can type $machines.count to display the number of elements in this array: 

Figure 15: The array has 3 elements, one for each computer 

To display the first element of the array, you can type $machines[0] like this: 

Figure 16: Displaying the first element of the array 





As you can see from the figure above, the first element of the array contains the information about the 

first computer. To display only the name of this computer, type $machines[0].name like this: 

Figure 17: Displaying the name of the first computer 

Adding the Imported Computers to the Database 

Now that we know a bit about manipulating arrays, we are ready to import the information stored in 

the array variable $machines into our MDT database. To do this, we are going to be using the New- 

MDTComputer cmdlet so let's display the syntax for this cmdlet: 

Figure 18: View the syntax for New-MDTComputer 





Remember from article 16 that computer items must be uniquely identified in the database using one 

(or more) of the following fields: 

Universally Unique Identifier (UUID) 

Asset tag 

Serial number 

MAC address 

Let us add a computer item for the first computer in our spreadsheet using its MAC address as the 

identifier. To do this, we type the following command: 

New-MDTComputer –macAddress $machines[0].mac –settings @{OSInstall='YES'} 

Figure 19: Adding the first computer to the database using its MAC address as identifier 

Close and re-open the Workbench to refresh it and you should see the new computer item: 

Figure 20: The new computer item has been added to the database 





If you double-click on this computer item you can display its properties: 

Figure 21: Properties of the new computer item 

Selecting the Details tab shows that the OSinstall property has been set to YES as expected: 

Figure 22: Detailed properties of the new computer item 





However, note in the figure above that the OSDComputerName property of the new computer item 

has no value. The OSDComptuerName property specifies the name you want MDT to assign to the 

target computer, and if you refer back to Figure 11 you will see that we wanted this property set to 

DESK-A for this particular computer. 

Let us see how to add a new computer to the database while also specifying the computer's name. To 

show how to do this, let's add a computer item for the second computer in our spreadsheet using its 

MAC address as the identifier and also specifying its name (which as you can see from the previous 

Figure 11 should be DESK-B). To do this, we type the following command: 

New-MDTComputer –macAddress $machines[1].mac –settings 

@{OSInstall='YES';OSDComputerName=$machines[1].name} 

Figure 23: Adding the second computer to the database using its MAC address as identifier 

and specifying the computer's name 

If you close and reopen the Workbench, open the properties for the new computer, and select the 

Details tab, you can see that this time the OSDComputerName property has the expected value 

DESK-B assigned to it: 






Let us try one more example and add a computer item for the third computer in our spreadsheet using 

its MAC address as the identifier while also specifying the computer name, organization name, and 

user's full name. To do this, we'll type a single PowerShell command but continue it across several 

lines to make it more readable: 

New-MDTComputer –macAddress $machines[2].mac –settings @{ 

OSInstall='YES'; 

OSDComputerName=$machines[2].name; 

FullName='Michael Allen'; 

OrgName='Contoso Ltd.'} 

Figure 25: Adding the third computer to the database with several properties being specified 





Note that in PowerShell you do not have to use any special line continuation character if the 

command breaks across an array specified by curly braces. 

Close and reopen the Workbench, open the properties for the new computer, and select the Details 

tab to see that the expected properties have been configured: 


Bulk Creation of Computer Items in the Database 

We now know how to use a single PowerShell command to create a new computer item in the MDT 

database and configure various properties of that item. Now let's see how we can use a script to 

automate this process so we can bulk create lots of computers in the database in one step. 

First, instead of typing separate commands to create each computer in the database, let's use a For 

loop to iterate through the elements of the $machines array like this: 

For ($i=1; $i -le $machines.count; $i++) 

{ 

New-MDTComputer -macAddress $machines[$i-1].mac -settings @{ OSInstall='YES'; 

OSDComputerName=$machines[$i-1].name;} 

} 





Figure 27: Using a For loop to add computers to the database 

Note that the loop does not execute until you finish typing the closing brace—you do not need to use 

any line continuation characters like in VBScript. 

The result of running this command can be seen by opening the Workbench: 

Figure 28: Three computer items have been created using a single command 

Now let's turn all this into a script that does the following: 


Installs the MDT PowerShell module 

Connects to the MDT database 

Imports the CSV file of target computer info 




Creates computer items in the database including the names of the computers and the 

organization name Contoso Ltd. 

To do this, type the following PowerShell script into Notepad: 

Import-Module –name C:\Scripts\MDTDB.psm1 


$machines = Import-Csv C;\Data\machines.txt 


{ 

New-MDTComputer -macAddress $machines[$i-1].mac -settings @{ 


OSDComputerName=$machines[$i-1].name; 

OrgName='Contoso Ltd.' 

} 

} 

Now save this text file as Create.ps1 since PowerShell scripts must have the .ps1 file extension. Open 

the Workbench and delete any existing computer items in the database, then close the Workbench. 

Now browse to your Create.ps1 file, right-click on it and select Run With PowerShell. The PowerShell 

command shell will be displayed for a moment and then will close. As an alternative to double-clicking 

on the .ps1 file, you can open the PowerShell command shell, change to the directory where the 

Create.ps1 file is located, and type Create.ps1 to run your script. 

Now open the Workbench and you should see your new computer items. We've achieved our goal of 

being able to populate the MDT database with multiple computer items in one step. 

Here's a bonus for you. Administrators often want to name computers using some standard naming 

convention, and let's say we want to name these three computers SEA-CLI-001, SEA-CLI-002 and 

SEA-CLI-003 instead of DESK-A, DESK-B and DESK-E. We can do this by modifying the above script 

with a bit of fancy string manipulation as follows: 

Import-Module –name C:\Scripts\MDTDB.psm1 


$machines = Import-Csv C;\Data\machines.txt 


{ 

$n = "{0:D3}" -f $i 

New-MDTComputer -macAddress $machines[$i-1].mac -settings @{ 


OSDComputerName='SEA-CLI-' + $n 

OrgName='Contoso Ltd.' 

} 

} 





Save this script as Create2.ps1 and then run the script. When you example the Details tab of the 

properties of the computer items created by the script, you'll see that the computers are named using 

the specified naming convention: 

Figure 29: Creating computer items using a naming convention 


There are lots of good PowerShell resources out there, but for beginners I recommend you check out 

Chapter 13 of the Windows 7 Resource Kit which has a good introductory tutorial written by Ed Wilson 

a.k.a. The Scripting Guy. 

Part 23: Managing Drivers – Introduction 





Injecting Boot-Critical Device Drivers: A Story 

Here's a simple example of how device drivers can add complexity to even a simple deployment 

scenario. I have an old Dell PowerEdge 800 server in my lab, and a while back I wanted to repurpose 





this server by installing Windows Server 2008 R2 on it. The server has an integrated Dell CERC 6channel 

SATA hardware RAID controller with three 80 GB SATA hard drives configured as a RAID 0 

array (i.e. stripe set). So I put the Windows Server 2008 R2 product media into the DVD drive in the 

server, booted the server, and proceeded through the installation steps. When I got to the screen 

titled "Where do you want to install Windows?" a message was displayed saying "No drives were 

found. Click Load Driver to provide a mass storage driver for installation." 

What's the problem here? It seems that Windows Server 2008 R2 does not include an inbox driver for 

this particular hardware RAID controller because the PowerEdge 800 server is an older model that 

was designed for Windows Server 2003. Now at the time I was doing this there was no Windows 

Server 2008 R2 certified driver for the controller, but there was a 64-bit Windows Server 2003 driver 

available and a quick chat with a Dell support technician suggested that this driver "hasn't been 

validated but seems to work" with Windows Server 2008 R2. So I downloaded the self-extracting 

Windows Server 2003 x64 driver package and extracted the files from the package, which look like 

this: 

Figure 1: Windows Server 2003 x64 driver files for Dell CERC 6-channel SATA hardware RAID 

controller 

Note: While writing this article I checked the Dell Support site and discovered that they have now 

released a certified Windows Server 2008 driver for their CERC 6-channel SATA hardware RAID 

controller, which breathes new life into my old PowerEdge 800 server. 





So I copied these mass storage controller driver files to a flash drive, rebooted my server with the 

Windows Server 2008 R2 product media in the DVD drive, and walked through Setup again. This time 

when I got to the screen titled "Where do you want to install Windows?" I inserted my flash drive and 

clicked Load Driver, then I clicked Browse and selected the folder on my flash drive where the driver 

files were stored. At that point the "Select the driver to be installed" screen showed the following mass 

storage driver available for installation: 

DELL CERC SATA 1.5/6ch RAID Controller (C:\\cercsr6.inf) 

I clicked selected the driver, clicked Next and continued with a successful installation of Windows 

Server 2008 R2 on the machine. 

Now, most administrators have gone through this kind of procedure before, but the question is: How 

does this work with Microsoft Deployment Toolkit? 

Injecting Mass Storage Drivers Using MDT 2010 

First, what happens if you try using MDT to deploy Windows on a system for which there is no in-box 

mass storage controller driver available? In my scenario above, this would mean first importing 

Windows Server 2008 R2 into the Operating Systems node in the Deployment Workbench and then 

creating a new task sequence based on the Standard Server Task Sequence template. Then take my 

existing Lite Touch Windows PE CD, boot my server with it, and wait for MDT to perform the install. 

What happens when I do this is that when the wizard begins to gather information concerning the 

local disk system on the server, the wizard fails with an error screen that says "Operating system 

deployment did not complete successfully." Expanding the details on this screen indicates that "Disk 

(0) was not found. Unable to continue. Possible cause: Missing Storage Driver." That's pretty 

informative, and it's just what we would expect in this scenario. 

What I need to do now is to add the driver I downloaded to MDT as an out-of-box driver. To do this, 

begin by right-clicking on the Out-Of-Box Drivers folder in the Workbench and select Import Drivers: 

Figure 2: Step 1 of adding an out-of-box driver into the Deployment Workbench 





In the Import Driver Wizard that appears, click Browse to select the folder where the mass storage 

driver is located: 


Click Next and review the information on the Summary page: 






Click Next and verify on the Confirmation page that the driver files have been successfully imported 

into the Workbench: 


Figure 6 below shows that the driver files for the mass storage controller have been successfully 

imported into the Workbench: 

Figure 6: The driver files have been successfully imported into the Deployment Workbench 





The file we are mainly interested in is the cercsr6.inf file; double-clicking on this file displays its 

properties: 

Figure 7: General tab of the driver's properties 

As expected, the General tab shows that this driver is intended only for x64 systems and not x86. If 

desired I could add a comment here like "This old driver for Windows Server 2003 x64 is reported to 

work with Windows Server 2008 R2 so I'm going to try it" or something similar. 

Clicking the Details tab displays additional read-only information concerning the driver: 

Figure 8: Details tab of the driver's properties 





Are we finished? No, not quite. We have imported the driver into the Workbench, so the driver is now 

available for installation on the target computer but it hasn't yet been incorporated into our Lite Touch 

Windows PE image files, that is into the files LiteTouchPE_x64.wim and LiteTouchPE_x64.iso. What 

we need to do is to inject the driver into our image files so that the driver will be available during the 

initial WinPE phase of Setup, otherwise Setup will fail because WinPE would not be able to see the 

hard drives in the system. Fortunately, MDT makes injecting drivers into WinPE images a snap— 

simply right-click on your deployment share and select Update Deployment Share and any changes 

made to your environment will be injected if required into your WinPE images. Figure 9 shows the 

results from doing this, and you can see that the boot image (.wim) file was mounted, the mass 

storage driver was injected, and the.iso file associated with the boot image was re-created: 

Figure 9: Injecting the mass storage driver into the WinPE boot image by updating the 

deployment share 

Now I simply burn my LiteTouchPE_x64.iso file onto recordable CD media and use it to boot my old 

PowerEdge server. When I do this, the installation proceeds normally and Windows Server 2008 R2 is 

successfully installed on the system. 

Conclusion 

This article examined how to add an out-of-box driver to MDT in order to deploy Windows onto a 

system for which no in-box mass storage controller driver was present. But what if you need to add 

dozens, hundreds or thousands of out-of-box drivers to MDT for different operating systems you need 

to deploy, for different system architectures (x86 or x64), and for different makes and models of 

systems? In the next article we'll learn how you can use two new features of MDT 2010, namely 

custom folders and select profiles, to manage complex driver scenarios. 





Part 24: Managing Drivers – Issues and Approaches 





In the previous article of this series we saw how to use MDT 2010 to inject a boot-critical out-of-box 

mass storage driver into a Lite Touch Windows PE boot image in order to deploy Windows onto a 

system for which no in-box mass storage controller driver was present. We also learned the steps for 

importing drivers into the Out-Of-Box Drivers folder of your deployment share. But what if you need to 

add dozens, hundreds or even thousands of out-of-box drivers to MDT for different operating systems 

you need to deploy, for different system architectures (x86 or x64), and for different makes and 

models of systems? In this article and the next few we'll learn how to use new features in MDT 2010 

to manage complex driver scenarios. 

Why Drivers Complicate Deployment 

Anything but the most simple deployment scenario involves deploying more than just an operating 

system. Real-world deployment scenarios usually involve deploying all of the following to target 

computers: 

Operating system 

Device drivers 

Applications 

Language packs 

Patches for OS and apps 

Customizations for OS and apps 

Deploying drivers is one of the more difficult tasks of real-world deployment scenarios. One reason for 

this is because organizations with large numbers of computers tend to purchase them over time. The 

result is often a plethora of different makes and models of systems from different manufacturers and 

may even include custom-built white-box systems. The result is that many different drivers are needed 

to support all the different systems in your organization. 

Another reason drivers add complexity to deployments is because drivers may not only be needed for 

the installed operating system to work properly, they may also be needed just to boot the system to 

start the installation process. As we saw in the previous article of this series, sometimes drivers 

(especially mass storage drivers but sometimes network interface card drivers also) need to be 

injected into the Lite Touch Windows PE boot media, otherwise you won't even be able to boot the 

target computer to start deploying Windows to the computer. Fortunately with desktop computers, the 

generic Lite Touch Windows PE boot image created by MDT is usually able to boot the computer, 

connect to the deployment share over the network, and continue with the installation. For servers 

however, with their RAID cards and other goodies, you may need to add additional drivers to 

Windows PE just to get the installation started. 

Another reason drivers make deployment difficult is because incompatibilities can sometimes arise. 

For instance, there are situations where installing the wrong driver on a system can cause the system 

to “bluescreen”. This can particularly be an issue with mass storage drivers. Or sometimes installing 

two similar drivers (one recent, one older) for the same hardware can cause the wrong driver to be 

installed because the vendor designed one driver poorly (e.g. malformed INF). Or sometimes the 

vendor releases a new driver for an updated version of the hardware and says that the new driver still 





supports the older version of the hardware, but when you try it you find out that the old hardware 

doesn't work properly with the new driver. 

Finally, when you are deploying the latest version of Windows such as Windows 7, both very new and 

very old hardware can often have driver problems. While Windows 7 has tons of in-box drivers, it may 

not have suitable drivers for hardware that was released after Windows 7 RTM'd. And Windows 7 may 

not include suitable drivers for hardware from the XP or earlier era. Unfortunately it can sometimes be 

difficult to find the right driver for your hardware on the vendor's website (assuming the vendor is still 

around for older hardware). Then, once you have downloaded the driver, you may need to jump 

through hoops to extract the driver files so you can import them into your deployment share. That is 

because the Import Driver Wizard you saw in the previous article can only import drivers that have 

INF files available. Unfortunately, some vendors like to release additional device management 

software bundled along with their drivers, with the result that these drivers may have to be installed at 

the end of the deployment process by running the vendor's Setup routine, which requires extra fiddling 

with your task sequence. 

Different Approaches to Managing Drivers for Deployment 

Then there's the question of whether to try and control which specific drivers get deployed to which 

specific target computers during deployment, or whether you just want to let Windows use Plug and 

Play to decide which drivers should be installed on any particular target computer. In other words, 

there are basically two different approaches you can follow for managing drivers during deployment: 

the "let me decide" approach vs. the "let Windows decide" approach. We'll look at the second 

approach first since it's the simpler approach to implement. But before we do this, a little history. 

An Outdated Approach to Managing Drivers 

Most organizations perform their desktop deployments by building a master installation image and 

then deploying this master image to their target computers. We saw in article 10 of this series how 

you could use MDT to create a master image by deploying Windows (along with applications, 

language packs, patches and other customizations) onto a master (or reference) computer and then 

capturing a sysprepped image of that computer and uploading it to your deployment share. And in 

article 11 of this series we saw another way of creating a master image by starting with a 

preinstalled/preconfigured computer and using the new Sysprep and Capture task sequence to 

capture a master image from this computer. Either way, you first build your master image (or two if 

you need to deploy both x64 and x86 Windows) using an MDT server in your lab environment, and 

then you deploy your master image(s) to target computers using a separate MDT server on your 

production network. 

Now when you build your master computer using your lab MDT server, you generally won't want to 

inject any additional out-of-box drivers into your master image. Years ago, administrators building 

master images often used to add all the drivers all their different types of target computers needed to 

their master images. The result of baking all these extra drivers into their master image was often 

problematic—images were huge and difficult to maintain, and driver conflicts often caused problems— 

sometimes as severe as bluescreens. 

Then BDD (the precursor to MDT) came along, and when BDD 2007 added support for Plug and Play 

enumeration the need for baking all your out-of-box drivers into the master image disappeared. 

Instead, you could now let Windows decide during deployment which drivers to pull down from the 

deployment share and install on each target system. Let's see how to implement this approach now. 





Using the "Let Windows Decide" Approach to Managing Drivers 

In the "let Windows decide" approach you simply import all the drivers your different types of target 

computers will need into your deployment share. Then, when you use MDT to deploy your master 

image onto a particular system using MDT, Windows will use Plug and Play to determine which 

additional out-of-box drivers will need to be installed on each system by matching the PnP IDs of each 

hardware component with the PnP IDs supported by available drivers—in other words, by using Plug 

and Play enumeration. 

The main advantage of this approach is simplicity. Since this is the way MDT performs Lite Touch 

deployment by default, there's less initial time and effort needed for planning how to manage drivers 

for your deployment—you just dump them all into your deployment share and let MDT and PnP do 

their magic. And since almost no up-front planning or preparation is needed, you can get up and going 

very quickly by following this approach. 

Here's how it can work in practice. Let's say your organization is in the process of transitioning from 

Windows XP to Windows 7 and has the following desktop systems: 

Dell Optiplex 580 systems that will need either Windows 7 x64 or Windows 7 x86 installed on 

them 

Dell Precision T3500 systems that will need Windows 7 x64 installed on them 

Hewlett-Packard Pro 3015 Microtower systems that will need either Windows 7 x64, Windows 7 

x86 or Windows XP SP3 installed on them. 

Once you've downloaded all the drivers for these systems, copy them to a folder such as C:\Drivers 

on your production MDT server: 

Figure 1: Dell and HP drivers to be imported into your deployment share 





In this example, your downloaded driver files are organized into two folders (Dell and HP) with 

subfolders named after models. Then beneath each model folder are various subfolders for operating 

system (e.g. Windows 7 x64 vs. x86) or device (e.g. audio) or driver package ID number (for HP 

drivers). 

To import all of these drivers into your deployment share, open the Deployment Workbench, right-click 

on the Out-Of-Box Drivers folder, and select Import Drivers to launch the Import Drivers Wizard. Then 

click Browse on the Specific Directory page and select the root C:\Drivers folder: 

Figure 2: Select the root folder where all your drivers are stored 

Click OK to return to the Specify Directory page: 

Figure 3: Importing all drivers found under C:\Drivers 





Note that what this does is it imports all drivers in C:\Drivers and in any subfolders beneath this folder. 

Click through the remaining steps of the wizard. The result will look something like this: 

Figure 4: All the drivers needed for desktop deployment have been imported into the Out-Of- 

Box Drivers folder 

Note that the import process may take some minutes to perform since there are hundreds of 

megabytes of drivers to import—and that's only for three different make/models with a couple of 

different operating systems! 

Now that all the drivers have been imported into your deployment share, you can use MDT to deploy 

your master image to your target computers. As the master image is being deployed, Windows will 

use PnP enumeration to determine which additional drivers in the deployment share will need to be 

installed on the target computer to ensure its hardware components function as designed. 

This "let Windows decide" approach has the virtue of simplicity—are there any caveats? There's really 

only one—driver conflicts may occur for certain types of hardware, especially if you're deploying 

multiple operating systems from your deployment share. But if you're only deploying a single 

operating system, for example Windows 7 x64, and you only have a few different makes and models 

of target computers, then this "let Windows decide" approach of simply dumping all your out-of-box 

drivers into your deployment share and letting PnP enumeration decide who gets what usually works 

just fine. On the other hand, if you test this approach in your MDT lab environment and you find that 

some systems get the wrong drivers installed on them (for example, a Windows XP Professional 

driver gets installed on a system you are deploying Windows 7 x86 onto), then you'll need a different 





approach to managing drivers for deployment. That's where selection profiles are useful, which is 

what we'll look at in the next article of this series. 

Part 25: Managing Drivers – Selection Profiles 





In the previous two articles of this series we began discussing how to use MDT 2010 to manage outof-box 

drivers needed for Lite Touch deployment. We learned why drivers complicate deployment and 

examined a simple "let Windows decide" of importing all your out-of-box drivers into the Out-of-Box 

Drivers folder of your deployment share and letting PnP enumeration on the target computers decide 

which drivers need to be downloaded from the deployment share and installed. If you are deploying 

Windows to only a few different makes and models of computers, this simple approach generally 

works fine. However, if you are deploying Windows to lots of different makes/models of computers, 

and particularly if you are deploying multiple versions of Windows (e.g. Windows 7 and Windows XP) 

from the same deployment share, then problems can sometimes occur with this approach because of 

driver conflicts. For example, you might find that some computers end up installing the wrong drivers, 

such as a Windows XP Professional driver getting installed on a system you are deploying Windows 7 

x86 onto. 

The possibility of driver conflicts is one reason why it's important to set up a separate MDT server for 

your lab environment before you use MDT for deployment on your production network. In particular, 

your MDT lab environment should include one target computer of each make/model of computer that 

is present on your production network. That way, you can first try the "let Windows decide" approach 

to managing drivers in your lab and see if any driver conflicts result. If you don't see any conflicts, you 

can then use this simple approach for managing drivers for your production deployment. If you do see 

conflicts however, then your production deployment will need a more controlled approach to 

managing drivers, which I call the "let me decide" approach. This approach uses two new features 

introduced in MDT 2010, namely custom folders and selection profiles. We'll learn about these two 

features as we examine how the "let me decide" approach to managing drivers works. 

Using the "Let Me Decide" Approach to Managing Drivers 

In this approach to managing drivers for deployment, you exercise control over which drivers are 

installed for different deployment scenarios. To do this, you begin by creating a hierarchical folder 

structure within your deployment share to contain the different drivers needed for each scenario. For 

example, let's say you plan on deploying the following three versions of Windows to different target 

computers: 

Windows 7 Enterprise edition x64 architecture for newer systems 

Windows 7 Enterprise edition x86 architecture for older systems 

Windows XP Professional (x86) for specific users who still need this OS 

To avoid driver conflicts that might be caused by a 32-bit driver being installed on 64-bit hardware or 

vice versa, or which might be caused by a Windows XP driver being installed on Windows 7 or vice 

versa, begin by right-clicking on the Out-of-Box Drivers folder in your deployment share and select 





New Folder from the context menu. This launches the New Folder wizard, in which you type a name 

for the new folder you are creating (see Figure 1): 

Figure 1: Creating a new folder named Windows 7 x64 

Finish the wizard to create the subfolder Windows 7 x64 beneath your Out-of-Box Drivers folder (see 

Figure 2). This subfolder is where you will store any drivers needed for deploying Windows 7 x64 to 

target computers. 

Figure 2: Custom folder for storing drivers needed for deploying Windows 7 x64 





Once you have done the same for the other operating systems you plan to deploy, your folder 

hierarchy looks like that shown in Figure 3: 

Figure 3: Folder hierarchy for deploying drivers to different operating systems 

Now you use the Import Driver Wizard described in the previous article of this series to import the 

necessary drivers for each operating system. The result might look something like Figure 4: 

Figure 4: Drivers needed for Windows 7 x64 deployment have been imported 





Custom folders are a powerful new feature in MDT 2010 and you can use them to create folder 

hierarchies for applications, operating systems, drivers, packages and task sequences. The more 

complex the folder structure you create, the more control you will have over your deployment—that's 

the plus side of custom folders. But complex folder structures are usually more difficult and timeconsuming 

to manage—that's the minus side. Custom folders can also be moved around by dragging 

and dropping within your deployment share. Note however that moving a custom folder does not 

really move any of the underlying files stored in the file system folder where the contents of your 

deployment share are located. In other words, custom folders are simply a logical way of organizing 

your applications, operating systems, drivers, packages and task sequences. 

Now we need to create our selection profiles. A selection profile simply lets you select one or more 

folders in your deployment share. Selection profiles are thus used to group items together, and this 

might be done for various reasons. For example, you can use selection profiles to inject the 

appropriate set of device drivers and packages into your Windows PE image or into your target 

computer's operating system. You can also use selection profiles for other purposes such as creating 

linked deployment shares (new in MDT 2010) or for creating specialized deployment media. 

MDT 2010 also includes some default selection profiles that can be used for general purpose 

deployment scenarios. Figure 5 below shows the default selection profiles—note that selection 

profiles are stored in the Selection Profiles folder beneath the Advanced Configuration folder in your 


Figure 5: Default selection profiles included in MDT 2010 

The default selection profiles are as follows: 

All Drivers – This includes all folders beneath the Out-of-Box Drivers folder in your deployment 

share. 

All Drivers and Packages – This includes all folders beneath the Applications and Out-of-Box 

Drivers folder in your deployment share. 

All Packages – This includes all folders beneath the Packages folder in your deployment share. 





Everything – This includes all applications, operating systems, device drivers, operating system 

packages, and task sequences in your deployment share. 

Nothing – This one doesn't include any folders from your deployment share. 

Sample – This is a sample selection profile that includes all packages and task sequences in your 


To create a selection profile that includes only drivers for Windows 7 x64 systems, right-click on the 

Selection Profiles folder and select New Selection Profile. When the New Selection Profile Wizard 

begins, type a name for your new selection profile as shown in Figure 6: 

Figure 6: Step 1 of creating a selection profile that includes only drivers for Windows 7 x64 systems 

Click Next and then select the Windows 7 x64 subfolder beneath the Out-of-Box Drivers folder as 


Figure 7: Step 2 of creating a selection profile that includes only drivers for Windows 7 x64 systems 





Finish the wizard to create your new selection profile. Once you have repeated the steps above to 

create additional selection profiles for Windows 7 x86 and Windows XP Professional, your list of 

available selection profiles should look something like Figure 8: 

Figure 8: Three new selection profiles have been created 

Now let's make use of our three new selection profiles to control which drivers are deployed with 

which operating system. To do this, we'll create three new task sequences, one for each of our 

selection profiles. In other words, one task sequence will be used for deploying Windows 7 x64, one 

for deployment Windows 7 x86, and one for deploying Windows XP Professional. Figure 9 shows our 

three task sequences: 

Figure 9: Create a new task sequence for each new selection profile 





To associate a particular task sequence with a particular selection profile, right-click on the task 

sequence and select Properties to open its properties page. Then select the Task Sequence tab. 

Since we want to use selection profiles to control which drivers are injected into our Windows PE boot 

images and into the operating system being deployed to the target computer, we need to configure 

the Inject Drivers task within the Preinstall task group in our task sequence. To configure this task, 

select it on the left and then click the Choose A Selection Profile list control to display the available 

selection profiles you can choose from (Figure 10): 

Figure 10: Choosing a selection profile for the Inject Drivers task within the Preinstall task 

group of a task sequence 

Note: Task sequences consist of various task groups (e.g. Initialization, Validation, State Capture, 

etc.) and tasks within these groups (e.g. Gather Local Only, Inject Drivers, Apply Patches, etc.). Task 

groups can also contain other task groups. You can create new task groups and tasks to customize 

how your deployments are performed. We will dig deeper into this in a future article of this series. 

Because the task sequence whose properties we opened is the one for installing Windows 7 x64, we 

need to associate the Windows 7 x64 Drivers selection profile with this task sequence as shown in 

Figure 11: 





Figure 11: Associating the Window 7 x64 Drivers selection profile with the Windows 7 x64 

Enterprise task sequence 

Note in the above screenshot that when you choose a selection profile for injecting drivers, you have 

two options. The first is to only install matching drivers from the selection profile on the target 

computer. In other words, PnP enumeration runs on the target computer to determine which drivers 

contained in the folders indicated by the selection profile, and only those drivers actually needed by 

the target computer's hardware are installed. This is the default setting and you should usually leave it 

as is. 

The second option is to install all drivers from the selection profile, even if some of those drivers aren't 

actually needed by the target computer's hardware. You should only use this option if you have 

drivers that can't be identified properly using PnP enumeration on the target computer. Drivers for the 

Bluetooth wireless stack sometimes fall within this category, and by selecting the second option you 

can ensure that the Bluetooth drivers needed by your target computer's hardware get installed. Other 

examples of hardware/drivers where this option might be needed might be to pre-stage NIC drivers 

needed for laptop docking stations that are disconnected from their laptops and for printers that will be 

connected after deployment is finished. Just be careful if you select this option—if you install drivers 

that aren't needed by the target computer's hardware, some of these unnecessary drivers could 

conflict with drivers that are needed by the hardware, and this can sometimes cause unpredictable 

results. 

Anyways, now all you need to do is use your Lite Touch Windows PE CD (or your Lite Touch PE .iso 

with Windows Deployment Services) to boot a particular target computer, step through the Windows 

Deployment Wizard, select the task sequence for the operating system you need to deploy on that 





computer, and MDT will ensure that the correct drivers for that operating system are installed on the 

computer. You can of course automate all this to a certain extent (see the previous articles in this 

series for more information on how to do this by editing CustomSettings.ini or using the MDT 

database). Till next time! 

Part 26: Managing Drivers – By Make and Model 





In the last few articles of this series we have been discussing how to use MDT 2010 to manage outof-box 

drivers needed for Lite Touch deployment. We have learned why drivers complicate 

deployment and have examined two approaches to managing drivers: 

The "let Windows decide" approach where you import all your out-of-box drivers into the Out-of- 

Box Drivers folder of your deployment share and then let PnP enumeration on the target 

computers decide which drivers need to be downloaded from the deployment share and installed. 

The "let me decide" approach where you exercise control over which drivers are installed by 

creating a hierarchical folder structure within your deployment share to contain the different drivers 

needed for each deployment scenario. 

The "let Windows decide" approach has the advantage of simplicity, but in order to make it work you 

need to build a deployment test lab with one of every type of make and model of computer in your 

production environment. Then every time you add a new or updated driver to the Out-of-Box Drivers 

folder of your deployment share, you need to retest deploying to every make and model to make sure 

the new or updated driver doesn't cause problems with existing hardware. So the "let Windows 

decide" approach is easy to set up but can involve a lot of ongoing maintenance. 

The "let me decide" approach on the other hand is more work to set up, especially if you create a 

complex folder structure and use lots of selection profiles and task sequences to manage how drivers 

are deployed to target computers. Once set up however, this approach can be easier to maintain in 

the long run since it can eliminate the kinds of problems that can occur when a computer ends up 

installing the wrong driver. 

There's a variation of the "let me decide" approach however that can make the job of managing 

drivers for your deployments even easier. This involves using driver groups instead of selection 

profiles, and that's what this article is about. 

Injecting Drivers by Make and Model 

In the previous version MDT 2008 you could use driver groups to logically organize out-of-box drivers 

you import into your deployment share. For example, you could create one driver group for mass 

storage drivers, another for Windows PE images, and so on. Then you could associate a particular 

driver group with a particular task sequence to control which drivers get deployed using that task 

sequence. 





In MDT 2010, you can't create driver groups any longer using the Workbench because now you can 

create custom folders instead, which provide you with more flexibility that driver groups did previously. 

However, you can still define new driver groups using the DriverGroup property and use this property 

as a variable within your task sequence to control which drivers are deployed to a target computer 

based on the make and model of the computer. 

Tip: If you are unsure of the make/model of a particular computer, you can use the WMI script in Part 

17 of this series to determine this information. 

Here is how you can inject drivers during deployment based on the target computer's make and model. 

Begin by creating a custom folder hierarchy beneath the Out-Of-Box Drivers folder of your deployment 

share that has a structure that looks like this: 

Out-Of-Box Folders 

Operating System 

Make 

Make… 

Operating System… 

Model 

Model… 

For example, for the last few articles we imagined a company that needed to deploy different versions 

of Windows to the following desktop systems: 

Dell Optiplex 580 systems that will need either Windows 7 x64 or Windows 7 x86 installed on 

them 

Dell Precision T3500 systems that will need Windows 7 x64 installed on them 

Hewlett-Packard Pro 3015 Microtower systems that will need either Windows 7 x64, Windows 7 

x86 or Windows XP SP3 installed on them. 

Figure 1 shows what the folder structure should look like for deploying Windows 7 x64 to these 

different systems: 

Figure 1: Folder structure for deploying Windows 7 x64 by Make and Model 





You would also create similar folder structures beneath the Windows 7 x86 and Windows XP 

Professional folders. Then you import the necessary out-of-box drivers for each system into the 

appropriate folder once you've obtained these drivers from each vendor's website. The result will look 

something like this (Figure 2): 

Figure 2: Imported out-of-box drivers for Dell Optiplex 580 systems 

Now open the properties of the task sequence used for deploying Windows 7 x64 to target computers. 

Under the Preinstall task group, select the task named Configure that is just before the Inject Drivers 

task. Then click Add, select General, and select Set Task Sequence Variable as shown in Figure 3: 

Figure 3: Create a task for setting a new task sequence variable just prior to the Inject Drivers task 





Once the new Set Task Sequence Variable task has been created, specify DriverGroup001 as the 

name of the task sequence variable and assign this variable the value Windows 7 

x64\%make%\%model% as shown in Figure 4: 

Figure 4: The new task sequence variable DriverGroup001 has the value Windows 7 

x64\%make%\%model% 

What happens when this task runs is that target computers whose Make is Dell Inc. and Model is 

Optiplex 580 have drivers in the folder Windows 7 x64\Dell Inc.\Optiplex 580 injected during 

deployment, computers whose Make is Dell Inc. and Model is Precision T3500 have drivers in the 

folder Windows 7 x64\Dell Inc.\Precision T3500 injected during deployment, and computers whose 

Make is Hewlett-Packard and Model is HP Pro 3015 Microtower have drivers in the folder Windows 7 

x64\Hewlett-Packard\HP Pro 3015 Microtower injected during deployment. More accurately, only 

those drivers in these folders that PnP determines need to be injected are actually injected. But the 

bottom line is that using this approach, Dell Optiplex 580 systems cannot have Dell Precision T3500 

or Hewlett-Packard Pro 3015 Microtower drivers injected by mistake. Each make and model system 

will receive only the drivers that are designed for it. 

We're not quite done however, because the next task Inject Drivers has the All Drivers selected by 

default, and MDT injects drivers based on the addition of the applicable driver group and selection 

profile. So if the driver group says only Dell Optiplex 580 drivers should be installed but the selection 





profile says all drivers should be installed, the result will be that all drivers are installed. Or more 

specifically, PnP will install drivers from the pool of all available drivers and not just those drivers 

designed for Dell Optiplex 580 systems, which means we're back to the "let Windows decide" 

approach unless we can prevent the All Drivers selection profile from being applied. This is simple to 

do however, just select the Inject Drivers task in the Preinstall task group and change the selection 

profile from All Drivers to Nothing as shown in Figure 5: 

Figure 5: Select the Nothing selection profile 

Now if the driver group says only Dell Optiplex 580 drivers should be installed and the selection profile 

says no drivers should be installed, the result will be that only Dell Optiplex 580 drivers are installed, 

which is just what we want. 

The key to making this approach work is that the custom folders you create for Make and Model must 

exactly match the Win32_ComputerSystem WMI class properties Manufacturer and Model 

respectively for each system. In the example above, the folder named Dell Inc. matches the 

Manufacturer property for the two systems, but older Dell computers might return Dell Computer 

Corporation or Dell Computer Corp. or some other value when the Manufacturer property is queried 

using WMI and if you were deploying to those systems you would have to create additional folders 

using these names. 





Finally, the reason this approach is easier to maintain in the long run is because when, for example, 

an updated driver is released for Dell Optiplex 580 systems, you import the driver into the Optiplex 

580 folder and then you only need to perform one test deployment (to a Dell Optiplex 580 computer) 

in your deployment test lab to ensure the new driver does not cause problems with this type of system. 

Contrast this with the "let Windows decide" approach where each time you update even a single 

driver you need to perform test deployments to all of your different types of systems. 

Part 27: Managing Drivers – Tips and Tricks 





In the last few articles of this series we examined two approaches ("let Windows decide" and "let me 

decide") that you can use for managing out-of-box drivers when performing Lite Touch deployment 

using MDT 2010. This article wraps up our discussion of managing drivers with some tips, tricks and a 

story. First the story, which was submitted to me by reader Tim Lors and which illustrates well the kind 

of headaches you can have when trying to manage drivers during deployment: 

"More than a year ago, I wrote scripts that would install drivers on WinXP PCs. The problem I ran into 

choosing drivers was not related to the OS. It was a failure of the manufacturer to properly implement 

PnP between their driver inf file and the hardware itself. Specifically, the inf file would indicate it was 

the best driver for a certain piece of hardware when in fact it wouldn’t even function with that 

incarnation of hardware. The only method I found to actually get the right driver installed in these 

difficult cases was to compare the hardware PnP IDs to a list of known problematic drivers, and if I 

found a match I would manually chose the right driver based on additional criteria – usually the PC 

model number. The most common additional criteria needed for the "let me decide" choice was PC 

model number, but occasionally involved the BIOS version or the PnP subset ID, and in one rare case 

trial & error. Of course trial & error was difficult because once Windows installed what driver it 

believed to be the best choice, you had to isolate that ‘non-working’ driver from Windows, or it would 

just re-install it. Note this scenario occurred in an environment with almost 10,000 PCs covering more 

than 25 different models." 

Most IT pros I talk to who do deployments tell me that drivers are one of their biggest headaches, and 

the story above only serves to drive this point home. So having spent the last four articles in this 

series covering this subject, I'm going to end the discussion of drivers with some tips and tricks to help 

make things easier for you. 

Finding Drivers 

The first difficulty is to find the out-of-box drivers your systems might need. Some vendors make this 

job easier than others, and Dell is particularly to be commended in this respect because they make 

drivers available for each desktop system as a .cab file for each operating system. To download 

these .cab files, go to www.delltechcenter.com and in the scrolling menu listbox on the left select 

Home, Microsoft, Microsoft System Center, SCCM – System Center Configuration Manager, Dell 

Business Client Operating System Deployment, Dell Business Client Operating System Deployment – 

The .CAB Files and you'll see the page shown in Figure 1: 





Figure 1: Download drivers for Dell client systems as .cab files 

Once you download a .cab file you can extract it into a folder, then you point to this folder when you 

import the driver into your deployment share. 

Other vendors also have tools for downloading drivers but in my opinion they're not as simple and 

helpful as Dell's approach. Here are a few examples of these tools and where to find them: 

HP SoftPaq Download Manager 

Lenovo Update Retriever 

Extracting INF files from EXEs 

Sometimes a system vendor provides drivers for a device in the form of an .exe file instead of a .cab 

file. In that case, a great tool to have in your toolset is WinRAR which lets you extract the driver files 

from the .exe file to a folder. Remember, in order to import a driver MDT needs the .inf file and related 

files for the driver—you can't import an .exe file as a driver. 

Preventing Drivers from Being Injected 

To prevent a particular driver you have imported from being injected (for example if your testing has 

determined that the driver causes problems when installed) just open the properties of the driver and 

clear the Enable This Driver checkbox (Figure 2): 





Figure 2: You can enable or disable a driver to allow or prevent the driver being injected 

Note that the above driver was designed for both 32- and 64-bit Windows. If you determine that it 

doesn't work as intended for 64-bit Windows, you can leave the driver enabled but deselect the x64 

checkbox to prevent it from being injected during deployment of 64-bit Windows. 

If desired you can even disable all the drivers in a folder by disabling the folder (Figure 3): 

Figure 3: You can disable a custom folder in your deployment share 





Managing Boot Drivers Using Selection Profiles 

You can also use selection profiles to manage drivers during the Windows PE boot phase of LTI 

deployment. To do this, open the properties of your deployment share and select either the Windows 

PE x64 Components or Windows PE x86 Components tab to manage drivers for the architecture you 

of the operating system you are deploying (Figure 4): 

Figure 4: Managing drivers during the boot process of LTI deployment 

By default, the All Drivers And Packages selection profile is selected here but only network and mass 

storage drivers from this selection profile are included in your Windows PE boot image. If needed you 

could create a custom selection profile that includes hardware-specific WinPE drivers for your target 

systems. 

Using Multiple Driver Groups to Deploy By Make and Model 

In the previous article of this series we saw how we could define a single driver group called 

DriverGroup001 and use this to manage drivers when deploying by make and model of the target 

computers. Keith Garner, a Deployment Specialist with Xtreme Consulting Group, has an excellent 

post that expands on this subject by showing how you can organize your drivers more efficiently and 

then use several driver groups to control how they are injected during deployment. 

Another good post to read is this one about using model aliases by Michael Murgolo, a Senior 

Consultant with Microsoft Consulting Services. 





Adding Drivers to an Image 

You can use the DISM.exe command to add drivers to an offline image, just mount the image and use 

DISM with the /add-driver option (See article 2 in this series for information on how to use DISM.exe). 

To add drivers to the driver store (that is, to pre-stage drivers so that they'll be available when 

Windows detects a device has been attached which needs the driver) you can use the PnPutil.exe 

command. This can be useful for example if you have used the Microsoft Update Catalog to download 

a .cab file of drivers for a printer and want to pre-stage these drivers in your reference computer so 

that when you deploy it the drivers are available for installation. See here and here for more 

information on PnPutil.exe. 

Maintain Driver Configurations When Capturing a Windows Image 

Finally, if you are capturing a reference image and deploying onto identical hardware you can provide 

users with a faster first-boot experience by configuring the PersistAllDeviceInstalls setting in your 

answer file for sysprepping the reference computer. See this article on TechNet for details. 

Part 28: Managing Software Updates 





When you deploy Windows to target computers, you want those computers to be fully patched right 

after deployment so they can be secure from the start. This can be a challenge however because 

security updates and other types of updates are released by Microsoft on a regular basis for their 

products. Fortunately, you can use Windows Server Update Services (WSUS) to manage the 

distribution of such software updates during the LTI deployment process and afterwards as well. This 

article examines how to install and configure WSUS and how to incorporate WSUS into your MDT 

2010 deployment infrastructure. 

Using WSUS in Build vs. Production Environment 

You should use WSUS in both of your MDT deployment environments: build and production. Your 

build environment is the isolated lab where you deploy and capture images of your master (reference) 

computers and then test deploying the captured images to all the different types of PCs present in 

your production environment. Using WSUS in your build environment enables your master images to 

be patched up to the date of creation of the image. If you don't patch your master images like this, 

your production deployments will take longer to perform since all available updates will need to be 

applied to them during deployment. 

It can be a chore however to try and keep a master image up to date with patches after the image has 

been captured. You can use DISM for this purpose, but it takes time and effort to do this (see article 2 

in this series for how to use DISM). As a result, you'll probably also want to use WSUS in your 

production environment so that patches are applied to target computers as they are deployed by MDT. 

That way, whatever patches aren't already present in the image will be applied during the deployment 

process so that once deployment is finished the computers are fully patched and secure. On the other 

hand, another approach you can follow is to use MDT to recreate all your master images each time 

new software updates are released by Microsoft. If you only have a few master images to maintain, 

this might be the best approach to follow. In that case, you only need to use WSUS in your build 

environment and not your production environment. Either way, the steps that follow for installing and 





configuring WSUS and configuring MDT to use WSUS apply to both build and production deployment 

environments. 

Installing WSUS 

On the Windows Server 2008 R2 platform, WSUS is available as an installable server role. For earlier 

Windows Server platforms, you must obtain WSUS from the Microsoft Download Center. In this 

walkthrough we're going to install the WSUS role on a member server named SEA-MDT-01 in the 

CONTOSO domain, which is the server we've been using as our MDT 2010 server throughout this 

series of articles. Before you install WSUS, you need to install a database for use by the service. This 

can be either Microsoft SQL Server 2008 Express or the Standard or Enterprise Edition of SQL Server 

2005 SP2 or SQL Server 2008. If you don't have an SQL Server or SQL Server Express database 

available, WSUS will automatically install the minimal Windows Internal Database for its use. Because 

we'll be installing the WSUS role on our MDT server SEA-MDT-01, which already has SQL Server 

2008 Express SP1 installed on it for hosting the MDT database, we'll use this existing database during 

our installation of WSUS. See article 15 in this series for details on how we installed SQL Server 

Express on our MDT server. 

Begin by launching the Add Roles wizard from either the oobe.exe screen or Server Manager, and 

select the WSUS role at the bottom of the list of available roles (doing this also automatically installs 

the Web Server role on your server): 

Figure 1: Step 1 of installing the WSUS server role 





Begin the WSUS Setup wizard by selecting a location where downloaded updates will be stored on 

the server (in this walkthrough we are using volume U which is a dedicated volume for storing 

updates): 


Select the installed SQL Server Express database instance on the server: 






The next screen shows that the WSUS Setup wizard has successfully connected to the SQL server 

instance SQLEXPRESS: 


We'll use the Default Web Site for the WSUS role: 






Click Next on the confirmation page to finish installing WSUS: 


Configuring WSUS 

Once WSUS has finished installing on your server, the WSUS Configuration wizard automatically 

launches: 






Click Next and optionally join the Microsoft Update Improvement Program if desired: 

Figure 8: Step 1 of configuring the WSUS server role 

The default configuration is for WSUS to download updates from the Microsoft Update (MU) website: 






Large companies may choose to set up a hierarchy of WSUS servers so that servers at branch offices 

obtain their updates from a server at headquarters, which obtains its updates from MU. 

Moving forward, specify a proxy server if you have one: 


Click the Start Connecting button to connect your WSUS server to an upstream server, which in this 

case will be the MU website: 






Now select the language(s) for the updates you will be downloading: 


Select only those Microsoft products for which you want to apply updates during the deployment 

process. In this walkthrough, we will only download updates for Windows 7: 






By default all critical and security updates are downloaded, plus definition updates which apply to 

WSUS itself: 


If desired, you can download other types of updates to install during the deployment process. A good 

choice here would be the last two items in the list above, namely Update Rollups and Updates. 

The next screen indicates that the default configuration is for you to manually synchronize WSUS 

when desired: 






If you want, you can change the option in the previous screen so that WSUS synchronizes on a 

schedule, for example each night at 2 am. 

The next screen is configured by default to begin synchronization immediately, but we're going to 

deselect the checkbox so that we can perform further configuration: 


Once the wizard is finished, open the WSUS admin console from Administrative Tools and select 

Options: 






Click the Automatic Approvals link on the right hand side of the above screen to open the Automatic 

Approvals dialog: 


Click the Edit button to edit the Default Automatic Approval Rule: 






Click the first hyperlink in the Step 2 box at the bottom. This opens a new dialog that lets you choose 

which updates should be automatically approved so you don't have to manually approve them. 

Automatic Approval will be the best choice for organizations that don't have the IT staff resources to 

be able to verify and test every released update against the matrix of all installed applications (in 

reality this is most organizations). By default, only critical and security updates are approved 

automatically: 


If you configured WSUS earlier to download Update Rollups and Updates, then you will probably want 

to select the last two checkboxes in the above dialog as well. Click OK to return to the Automatic 

Approvals dialog, and select the checkbox indicated to enable the rule that automatically approves the 

types of updates you have specified: 



Click OK to finish configuring WSUS. 




Synchronizing WSUS 

The next step is to synchronize your WSUS server with the upstream server, which in this case is the 

MU website. In the WSUS admin console, right-click on the Synchronization node and select 

Synchronize Now: 

Figure 22: Synchronizing WSUS 

When synchronization is complete, you'll see the result in the details pane of the console: 

Figure 23: Results of synchronizing WSUS 





Note that "Succeeded" does not mean that all updates have been downloaded. Because WSUS uses 

BITS to download updates in the background, this can take some time. To check on the progress of 

downloading updates, select the All Updates node under Updates. Any updates that have an icon in 

the first column like the bottom two in the figure below are still being downloaded from MU and are not 

yet available for deployment: 

Figure 24: Updates have been downloaded and approved 

By selecting the Updates node you can get a quick picture of different categories of updates: 

Figure 25: Overview of updates 





Additional information can be generated from the Reports node if desired: 

Figure 26: Generating reports 

At this point WSUS has been configured and updates for Windows 7 have been downloaded. 

Configuring MDT to Use WSUS 

Now we need to configure MDT so that our target computers will pull updates from WSUS during the 

LTI deployment process. Open the Deployment Workbench and select a task sequence for either 

build or production deployment, depending on which environment you are working in. Open the 

properties of the task sequence and select the Task Sequence tab. Select the Windows Update (Pre- 

Application Installation) task within the State Restore task group, and on the Options tab for this task 

clear the checkbox indicated below to enable the use of WU (or WSUS in this case) to patch the 

target computer during the deployment process: 

Figure 27: Configuring a task sequence to use WSUS 





Apply the change, then do the same for the Windows Update (Post-Application Installation) task two 

steps down in the task group, then close the task sequence properties. 

Now open the CustomSettings.ini file for your deployment share and add the following line to the 

[Default] section: 

WSUSServer=http://SEA-MDT-01 

This tells the target computers which server they should pull updates from during the deployment 

process: 

Figure 28: Configuring CustomSettings.ini so that target computers will use WSUS during the 

deployment process 

Click OK to apply the change and we are done. Now try using MDT to deploy Windows 7 to a target 

computer, and after deployment is finished open Programs and Features from Control Panel, click the 

View Installed Updates link on the left, and you should see that a bunch of updates have been 

installed on the computer during the deployment process: 





Figure 29: Updates were installed on a target computer during LTI deployment 

Conclusion 

In the next and final article of this series, we will add Windows Deployment Services into the mix and 

tie everything together for our LTI deployment infrastructure. 

Part 29: Completing the LTI Deployment Infrastructure 





Deployment is a huge subject and there's still lots to explore on the subject, but for now at least it's 

time to draw this series to a close and move on to other topics. If you've been following along you 

should now be able to use MDT to do the following: 

Install, configure, secure and use MDT to perform Lite Touch Installation (LTI) deployments of 

Windows 7. 

Perform a manual or automated LTI deployment of Windows 7 by booting target computers using 

a LTI WinPE CD. 





Capture and deploy a reference or master installation of Windows 7. 

Use the MDT database to deploy a customized installation of Windows 7 together with 

applications like Microsoft Office to specific target computers that are identified by their UUID, 

MAC address, or other characteristics. 

Inject out-of-box drivers into the deployment process in ways appropriate for your environment. 

Use WSUS to ensure target computers are fully patched as part of the deployment process. 

There's one thing we still need to take care of however: How can we start the deployment process 

automatically instead of having to boot target computers using the LTI WinPE CD? It would be nice if 

we could just turn on a computer that has no operating system installed and watch MDT deploy 

Windows 7 onto the computer without our need of doing anything other than pressing the power 

button on the computer. Well, you can in fact do this by using Windows Deployment Services (WDS), 

which was described in detailed in my earlier Deploying Vista series of articles right here on 

WindowsNetworking.com beginning with article 18 of that series. 

So let's now add WDS to our LTI deployment infrastructure to make our MDT deployments even more 

automated (and save us from the cost and effort having to burn a bunch of CDs). To review, our LTI 

deployment infrastructure currently has two servers both running Windows Server 2008 R2 and 

configured as shown in Table 1 below: 

Name of server Roles and software installed 

SEA-DC-01 AD DS server role (domain controller) 

DSN server role 

DHCP server role 

SEA-MDT-01 Windows AIK 2.0 

MDT 2010 

SQL Server Express SP1 

WSUS 3.0 SP2 

We will now complete our LTI deployment infrastructure by adding the WDS role to server SEA-MDT- 

01. 

Installing and Configuring WDS 

Begin by launching the Add Roles wizard and select the WDS role: 





Figure 1: Step 1 of installing and configuring WDS 

Finish the wizard until the role has been installed. Then open the WDS admin console from 

Administrative Tools and note that WDS still needs to be configured on the server: 






Right-click on the server node under “Servers” (as shown above) and select Configure Server from 

the shortcut menu. This launches the WDS Configuration wizard which asks you to specify a location 

for storing images and other files. We'll choose disk volume W on our server, which is dedicated for 

this purpose: 


On the PXE Server Initial Settings wizard page, we'll select "Respond to all client computers (known 

and unknown)" which allows any computer with no operating system installed to PXE boot from our 

WDS computer: 



Finish the WDS Configuration wizard. 




Adding the LTI Boot Image to WDS 

Once WDS has been configured on our MDT server, we need to import the LTI WinPE image as a 

boot image in WDS. Remember, MDT can create two types of LTI WinPE images: 

ISO files you can burn to CDs which you can then use to boot your bare-metal target systems 

WIM files, which is the type of image you can import into WDS 

Open the WDS admin console, right-click on the Boot Images node, and select Add Boot Image: 

Figure 5: Step 1 of adding the LTI boot image to WDS 

The wizard prompts you for the location of the boot image you want to import: 






Click Browse and open the Boot folder of your deployment share, and select the 

LiteTouchPE_x64.wim file: 


Click Open in the above dialog and then either accept the default name for the image or give it a new 

name: 






Finish the steps of the Add Image wizard. The WDS admin console should now display the imported 

LTI WinPE boot image: 

Figure 9: Step 5 of adding the LTI boot image to WDS. 

Configuring WDS to Ensure PXE Boot 

One final step you should perform is to open the properties of your WDS server, select the Boot tab, 

and select the second (middle) option to ensure PXE boot is always used for both known and 

unknown clients: 

Figure 10: Configuring WDS to ensure PXE boot 





WDS is now installed and configured on your MDT server. Your LTI WinPE boot image has now been 

imported into WDS. All you need to do now is ensure that the BIOS of your target computers is 

configured for PXE booting (typically in the order CD, HD, network, floppy) and then you can turn your 

target computers on and sit back and watch as they PXE boot from WDS, download a boot image, 

boot into WinPE, and begin installing Windows 7. 

Conclusion 

To review, our complete LTI deployment infrastructure has two servers both running Windows Server 

2008 R2 and configured as shown in Table 2 below: 

Name of server Roles and software installed 

SEA-DC-01 AD DS server role (domain controller) 

DSN server role 

DHCP server role 

SEA-MDT-01 Windows AIK 2.0 

MDT 2010 

SQL Server Express SP1 

WSUS 3.0 SP2 

Windows Deployment Services 

You can use such an infrastructure in either your build and/or production environments to create and 

maintain your master images and/or deploy Windows 7 to target computers across your network. 

There’s a lot more you can do with deployment, such as using System Center Configuration Manager 

(ConfigMgr) together with WDS and MDT to perform both LTI and Zero-Touch Installation (ZTI) 

deployments, but for now we'll bring this series to a close and move on. I hope you've found these 

articles useful!

Deploying Windows 7 - Bandwidthco Computer Security

Create successful ePaper yourself

Delete template?

Save as template?