Contents

Deploy Windows 10 with the Microsoft Deployment Toolkit (MDT)

Get started with MDT
Deploy Windows 10 with MDT
Prepare for deployment with MDT
Create a Windows 10 reference image
Deploy a Windows 10 image using MDT
Build a distributed environment for Windows 10 deployment
Refresh a Windows 7 computer with Windows 10
Replace a Windows 7 computer with a Windows 10 computer
Perform an in-place upgrade to Windows 10 with MDT
Customize MDT
Configure MDT settings
Set up MDT for BitLocker
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Simulate a Windows 10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use web services in MDT
Use Orchestrator runbooks with MDT
 Get started with MDT
11/23/2022 • 10 minutes to read • Edit Online

Applies to
Windows 10
This article provides an overview of the features, components, and capabilities of the Microsoft Deployment
Toolkit (MDT). When you have finished reviewing this information, see Prepare for deployment with MDT.

About MDT
MDT is a unified collection of tools, processes, and guidance for automating desktop and server deployment.
You can use it to create reference images or as a complete deployment solution. MDT is one of the most
important tools available to IT professionals today.
In addition to reducing deployment time and standardizing desktop and server images, MDT enables you to
more easily manage security and ongoing configurations. MDT builds on top of the core deployment tools in the
Windows Assessment and Deployment Kit (Windows ADK) with more guidance and features designed to reduce
the complexity and time required for deployment in an enterprise environment.
MDT supports the deployment of Windows 10, and Windows 7, Windows 8.1, and Windows Server. It also
includes support for zero-touch installation (ZTI) with Microsoft Configuration Manager.

IMPORTANT
For more information about MDT supported platforms, see MDT Release Notes and MDT FAQ.

Key features in MDT

MDT has been in existence since 2003, when it was first introduced as Business Desktop Deployment (BDD) 1.0.
The toolkit has evolved, both in functionality and popularity, and today it's considered fundamental to Windows
operating system and enterprise application deployment.
MDT has many useful features, such as:
Windows Client suppor t. Supports Windows 7, Windows 8.1, and Windows 10.
Windows Ser ver suppor t. Supports Windows Server 2008 R2, Windows Server 2012, Windows
Server 2012 R2, Windows Server 2016, and Windows Server 2019.
Additional operating systems suppor t. Supports Windows Thin PC and Windows Embedded
POSReady 7, and Windows 8.1 Embedded Industry.
UEFI suppor t. Supports deployment to machines using Unified Extensible Firmware Interface (UEFI)
version 2.3.1.
GPT suppor t. Supports deployment to machines that require the new GPT partition table format. This
feature is related to UEFI.
Enhanced Windows PowerShell suppor t. Provides support for running PowerShell scripts.
The deployment share mounted as a standard PSDrive allows for administration using PowerShell.
Add local administrator accounts. Allows you to add multiple user accounts to the local
Administrators group on the target computers, either via settings or the deployment wizard.
Automated par ticipation in CEIP and WER. Provides configuration for participation in Windows
Customer Experience Improvement Program (CEIP) and Windows Error Reporting (WER).
Deploy Windows RE. Enables deployment of a customized Windows Recovery Environment (Windows
RE) as part of the task sequence.
Deploy to VHD. Provides ready-made task sequence templates for deploying Windows into a virtual
hard disk (VHD) file.
Improved deployment wizard. Provides more progress information and a cleaner UI for the Lite Touch
Deployment Wizard.
Monitoring. Allows you to see the status of currently running deployments.
Apply GPO Pack . Allows you to deploy local group policy objects created by Microsoft Security
Compliance Manager (SCM).
Par titioning routines. Provides improved partitioning routines to ensure that deployments work
regardless of the current hard drive structure.
Offline BitLocker. Provides the capability to have BitLocker enabled during the Windows Preinstallation
Environment (Windows PE) phase, thus saving hours of encryption time.
USMT offline user-state migration. Provides support for running the User State Migration Tool
(USMT) capture offline, during the Windows PE phase of the deployment.
 The offline USMT backup in action.
Install or uninstall Windows roles or features. Enables you to select roles and features as part of
the deployment wizard. MDT also supports uninstall of roles and features.
Microsoft System Center Orchestrator integration. Provides the capability to use Orchestrator
runbooks as part of the task sequence.
Suppor t for DaRT. Supports optional integration of the DaRT components into the boot image.
Suppor t for Microsoft Office. Provides added support for deploying Microsoft Office.
Suppor t for Modern UI app package provisioning. Provisions applications based on the new
Windows app package standard, which is used in Windows 8 and later.
Extensibility. Provides the capability to extend MDT far beyond the built-in features by adding custom
scripts, web services, System Center Orchestrator runbooks, PowerShell scripts, and VBScripts.
Upgrade task sequence. Provides a new upgrade task sequence template that you can use to upgrade
existing Windows 7, Windows 8, and Windows 8.1 systems directly to Windows 10, automatically
preserving all data, settings, applications, and drivers. For more information about using this new
upgrade task sequence, see the Microsoft Deployment Toolkit resource page.

MDT Lite Touch components

Many features in MDT support Lite Touch Installation (LTI) for Windows 10. An LTI deployment strategy requires
little infrastructure or user interaction, and can be used to deploy an operating system from a network share or
from a physical media, such as a USB flash drive or disk.
When the Windows operating system is being deployed using MDT, most of the administration and
configuration is done through the Deployment Workbench, but you also can perform many of the tasks using
Windows PowerShell. The easiest way to find out how to use PowerShell in MDT is to use the Deployment
Workbench to perform an operation and at the end of that task, select View Script . You're provided the
PowerShell command.
If you select View Script on the right side, you'll get the PowerShell code that was used to perform the task.

Deployment shares
A deployment share is essentially a folder on the server that is shared and contains all the setup files and scripts
needed for the deployment solution. It also holds the configuration files (called rules) that are gathered when a
machine is deployed. These configuration files can reach out to other sources, like a database, external script, or
web server to get more settings for the deployment. For Lite Touch deployments, it's common to have two
deployment shares: one for creating the reference images and one for deployment. For Zero Touch, it's common
to have only the deployment share for creating reference images because Configuration Manager deploys the
image in the production environment.

Rules
The rules (CustomSettings.ini and Bootstrap.ini) make up the brain of MDT. The rules control the Windows
Deployment Wizard on the client and, for example, can provide the following settings to the machine being
deployed:
Computer name
Domain to join, and organizational unit (OU) in Active Directory to hold the computer object
Whether to enable BitLocker
Regional settings You can manage hundreds of settings in the rules. For more information, see the Microsoft
Deployment Toolkit resource center.
Example of an MDT rule. In this example, the new computer name is being calculated based on PC- plus the first
seven (Left) characters from the serial number

Boot images
Boot images are the Windows Preinstallation Environment (Windows PE) images that are used to start the
deployment. They can be started from a CD or DVD, an ISO file, a USB device, or over the network using a Pre-
Boot Execution Environment (PXE) server. The boot images connect to the deployment share on the server and
start the deployment.

Operating systems
Using the Deployment Workbench, you import the operating systems you want to deploy. You can import either
the full source (like the full Windows 10 DVD/ISO) or a custom image that you've created. The full-source
operating systems are primarily used to create reference images; however, they also can be used for normal
deployments.

Applications
Using the Deployment Workbench, you also add the applications you want to deploy. MDT supports virtually
every executable Windows file type. The file can be a standard .exe file with command-line switches for an
unattended install, a Microsoft Windows Installer (MSI) package, a batch file, or a VBScript. In fact, it can be just
about anything that can be executed unattended. MDT also supports the new Universal Windows apps.

Driver repository
You also use the Deployment Workbench to import the drivers your hardware needs into a driver repository
that lives on the server, not in the image.

Packages
With the Deployment Workbench, you can add any Microsoft packages that you want to use. The most
commonly added packages are language packs, and the Deployment Workbench Packages node works well for
those packages. You also can add security and other updates this way. However, we generally recommend that
you use Windows Server Update Services (WSUS) for operating system updates. The rare exceptions are critical
hotfixes that aren't available via WSUS, packages for the boot image, or any other package that needs to be
deployed before the WSUS update process starts.

Task sequences
Task sequences are the heart and soul of the deployment solution. When creating a task sequence, you need to
select a template. The templates are located in the Templates folder in the MDT installation directory, and they
determine which default actions are present in the sequence.
You can think of a task sequence as a list of actions that need to be executed in a certain order. Each action can
also have conditions. Some examples of actions are as follows:
Gather. Reads configuration settings from the deployment server.
Format and Par tition. Creates the partition(s) and formats them.
Inject Drivers. Finds out which drivers the machine needs and downloads them from the central driver
repository.
Apply Operating System. Uses ImageX to apply the image.
Windows Update. Connects to a WSUS server and updates the machine.

Task sequence templates

MDT comes with nine default task sequence templates. You can also create your own templates. As long as you
store them in the Templates folder, they'll be available when you create a new task sequence.
Sysprep and Capture task sequence. Used to run the System Preparation (Sysprep) tool and capture
an image of a reference computer.

NOTE
It's preferable to use a complete build and capture instead of the Sysprep and Capture task sequence. A complete
build and capture can be automated, whereas Sysprep and Capture can't.

Standard Client task sequence. The most frequently used task sequence. Used for creating reference
images and for deploying clients in production.
Standard Client Replace task sequence. Used to run User State Migration Tool (USMT) backup and
the optional full Windows Imaging (WIM) backup action. Can also be used to do a secure wipe of a
machine that is going to be decommissioned.
Custom task sequence. As the name implies, a custom task sequence with only one default action (one
Install Application action).
Standard Ser ver task sequence. The default task sequence for deploying operating system images to
servers. The main difference between this template and the Standard Client task sequence template is
that it doesn't contain any USMT actions because USMT isn't supported on servers.
Lite Touch OEM task sequence. Used to preload operating systems images on the computer hard
drive. Typically used by computer original equipment manufacturers (OEMs) but some enterprise
organizations also use this feature.
Post OS Installation task sequence. A task sequence prepared to run actions after the operating
system has been deployed. Useful for server deployments but not often used for client deployments.
Deploy to VHD Client task sequence. Similar to the Standard Client task sequence template but also
creates a virtual hard disk (VHD) file on the target computer and deploys the image to the VHD file.
Deploy to VHD Ser ver task sequence. Same as the Deploy to VHD Client task sequence but for
servers.
Standard Client Upgrade task sequence. A simple task sequence template used to perform an in-
place upgrade from Windows 7, Windows 8, or Windows 8.1 directly to Windows 10, automatically
preserving existing data, settings, applications, and drivers.
Selection profiles
Selection profiles, which are available in the Advanced Configuration node, provide a way to filter content in the
Deployment Workbench. Selection profiles are used for several purposes in the Deployment Workbench and in
Lite Touch deployments. For example, they can be used to:
Control which drivers and packages are injected into the Lite Touch (and generic) boot images.
Control which drivers are injected during the task sequence.
Control what is included in any media that you create.
Control what is replicated to other deployment shares.
Filter which task sequences and applications are displayed in the Deployment Wizard.

Logging
MDT uses many log files during operating system deployments. By default the logs are client side, but by
configuring the deployment settings, you can have MDT store them on the server, as well.
Note
The easiest way to view log files is to use Configuration Manager Trace (CMTrace), which is included in the
Configuration Manager Toolkit.

Monitoring
On the deployment share, you also can enable monitoring. After you enable monitoring, you'll see all running
deployments in the Monitor node in the Deployment Workbench.

See next
Prepare for deployment with MDT
 Prepare for deployment with MDT
11/23/2022 • 9 minutes to read • Edit Online

Applies to
Windows 10
This article will walk you through the steps necessary to prepare your network and server infrastructure to
deploy Windows 10 with the Microsoft Deployment Toolkit (MDT). It covers the installation of the necessary
system prerequisites, the creation of shared folders and service accounts, and the configuration of security
permissions in the file system and in Active Directory.

Infrastructure
The procedures in this guide use the following names and infrastructure.
Network and servers
For the purposes of this article, we'll use three server computers: DC01 , MDT01 , and HV01 .
All servers are running Windows Server 2019.
You can use an earlier version of Windows Server with minor modifications to some procedures.
Note: Although MDT supports Windows Server 2008 R2, at least Windows Server 2012 R2 or later is
required to perform the procedures in this guide.
DC01 is a domain controller, DHCP server, and DNS server for contoso.com , representing the fictitious
Contoso Corporation.
MDT01 is a domain member server in contoso.com with a data (D:) drive that can store at least 200 GB.
MDT01 will host deployment shares and run the Windows Deployment Service. Optionally, MDT01 is also a
WSUS server.
A second MDT server (MDT02 ) configured identically to MDT01 is optionally used to build a
distributed environment for Windows 10 deployment. This server is located on a different subnet than
MDT01 and has a different default gateway.
HV01 is a Hyper-V host computer that is used to build a Windows 10 reference image.
See Hyper-V requirements below for more information about HV01.
Client computers
Several client computers are referenced in this guide with hostnames of PC0001 to PC0007.
PC0001 : A computer running Windows 10 Enterprise x64, fully patched with the latest security updates, and
configured as a member in the contoso.com domain.
Client name: PC0001
IP Address: DHCP
PC0002 : A computer running Windows 7 SP1 Enterprise x64, fully patched with the latest security updates,
and configured as a member in the contoso.com domain. This computer is referenced during the migration
scenarios.
Client name: PC0002
IP Address: DHCP
PC0003 - PC0007 : These are other client computers similar to PC0001 and PC0002 that are used in this
guide and another guide for various scenarios. The device names are incremented for clarity within each
scenario. For example, PC0003 and PC0004 are running Windows 7 just like PC0002, but are used for
 Configuration Manager refresh and replace scenarios, respectively.
Storage requirements
MDT01 and HV01 should have the ability to store up to 200 GB of files on a data drive (D:). If you use a
computer with a single system partition (C:), you'll need to adjust some procedures in this guide to specify the C:
drive instead of the D: drive.
Hyper-V requirements
If you don't have access to a Hyper-V server, you can install Hyper-V on a Windows 10 or Windows 8.1
computer temporarily to use for building reference images. For instructions on how to enable Hyper-V on
Windows 10, see the Verify support and install Hyper-V section in the Windows 10 deployment test lab guide.
This guide is a proof-of-concept guide that has detailed instructions for installing Hyper-V.
Network requirements
All server and client computers referenced in this guide are on the same subnet. This isn't required, but each
server and client computer must be able to connect to each other to share files, and to resolve all DNS names
and Active Directory information for the contoso.com domain. Internet connectivity is also required to download
OS and application updates.
Domain credentials
The following generic credentials are used in this guide. You should replace these credentials as they appear in
each procedure with your credentials.
Active Director y domain name : contoso.com
Domain administrator username : administrator
Domain administrator password : pass@word1
Organizational unit structure
The following OU structure is used in this guide. Instructions are provided below to help you create the required
OUs.

Install the Windows ADK

These steps assume that you have the MDT01 member server running and configured as a domain member
server.
On MDT01 :
Visit the Download and install the Windows ADK page and download the following items to the
D:\Downloads\ADK folder on MDT01 (you'll need to create this folder):
The Windows ADK for Windows 10
The Windows PE add-on for the ADK
The Windows System Image Manager (WSIM) 1903 update
(Optional) The MDT_KB4564442 patch for BIOS firmware
This patch is needed to resolve a bug that causes detection of BIOS-based machines as UEFI-based
machines. If you have a UEFI deployment, you don't need this patch.

TIP
You might need to temporarily disable IE Enhanced Security Configuration for administrators in order to download files
from the Internet to the server. This setting can be disabled by using Server Manager (Local Server/Properties).

1. On MDT01 , ensure that you're signed in as an administrator in the CONTOSO domain.

For the purposes of this guide, we're using a Domain Admin account of administrator with a
password of pass@word1 . You can use your own administrator username and password as long as
you properly adjust all steps in this guide that use these login credentials.
2. Start the ADK Setup (D:\Downloads\ADK\adksetup.exe), select Next twice to accept the default installation
parameters, select Accept to accept the license agreement, and then on the Select the features you want
to install page accept the default list of features by clicking Install . This will install deployment tools and the
USMT. Verify that the installation completes successfully before moving to the next step.
3. Start the WinPE Setup (D:\Downloads\ADK\adkwinpesetup.exe), select Next twice to accept the default
installation parameters, select Accept to accept the license agreement, and then on the Select the features
you want to install page select Install . This will install Windows PE for x86, AMD64, ARM, and ARM64.
Verify that the installation completes successfully before moving to the next step.
4. Extract the WSIM 1903 update (D:\Downloads\ADK\WSIM1903.zip) and then run the UpdateWSIM.bat
file.
You can confirm that the update is applied by viewing properties of the ImageCat.exe and ImgMgr.exe
files at C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment
Kit\Deployment Tools\WSIM and verifying that the Details tab displays a File version of
10.0.18362.144 or later.
5. If you downloaded the optional MDT_KB4564442 patch for BIOS based deployment, see this support article
for instructions on how to install the patch.

Install and initialize Windows Deployment Services (WDS)

On MDT01 :
1. Open an elevated Windows PowerShell prompt and enter the following command:

Install-WindowsFeature -Name WDS -IncludeManagementTools

WDSUTIL /Verbose /Progress /Initialize-Server /Server:MDT01 /RemInst:"D:\RemoteInstall"
WDSUTIL /Set-Server /AnswerClients:All

Optional: Install Windows Server Update Services (WSUS)

If you wish to use MDT as a WSUS server using the Windows Internal Database (WID), use the following
command to install this service. Alternatively, change the WSUS server information in this guide to the WSUS
server in your environment.
To install WSUS on MDT01, enter the following at an elevated Windows PowerShell prompt:

Install-WindowsFeature -Name UpdateServices, UpdateServices-WidDB, UpdateServices-Services, UpdateServices-

RSAT, UpdateServices-API, UpdateServices-UI
cmd /c "C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall CONTENT_DIR=C:\WSUS

To use the WSUS that you have installed on MDT01, you must also configure Group Policy on DC01 and
perform the neccessary post-installation configuration of WSUS on MDT01.

Install MDT
NOTE
MDT installation requires the following:
The Windows ADK for Windows 10 (installed in the previous procedure)
Windows PowerShell (version 5.1 is recommended; type $host to check)
Microsoft .NET Framework

On MDT01 :
1. Visit the MDT resource page and select Download MDT .
2. Save the MicrosoftDeploymentToolkit_x64.msi file to the D:\Downloads\MDT folder on MDT01.
Note : As of the publishing date for this guide, the current version of MDT is 8456 (6.3.8456.1000), but
a later version will also work.
3. Install MDT (D:\Downloads\MDT\MicrosoftDeploymentToolkit_x64.exe) with the default settings.

Create the OU structure

Switch to DC01 and perform the following procedures on DC01 :
To create the OU structure, you can use the Active Directory Users and Computers console (dsa.msc), or you can
use Windows PowerShell.
Copy the following list of OU names and paths into a CSV file and save it as ~\Setup\Scripts\oulist.csv .

OUName,OUPath
Contoso,"DC=CONTOSO,DC=COM"
Accounts,"OU=Contoso,DC=CONTOSO,DC=COM"
Computers,"OU=Contoso,DC=CONTOSO,DC=COM"
Groups,"OU=Contoso,DC=CONTOSO,DC=COM"
Admins,"OU=Accounts,OU=Contoso,DC=CONTOSO,DC=COM"
Service Accounts,"OU=Accounts,OU=Contoso,DC=CONTOSO,DC=COM"
Users,"OU=Accounts,OU=Contoso,DC=CONTOSO,DC=COM"
Servers,"OU=Computers,OU=Contoso,DC=CONTOSO,DC=COM"
Workstations,"OU=Computers,OU=Contoso,DC=CONTOSO,DC=COM"
Security Groups,"OU=Groups,OU=Contoso,DC=CONTOSO,DC=COM"

Next, copy the following commands into a file and save it as ~\Setup\Scripts\ou.ps1 . Be sure that you're
viewing file extensions and that you save the file with the .ps1 extension.
 Import-CSV -Path $home\Setup\Scripts\oulist.csv | ForEach-Object {
New-ADOrganizationalUnit -Name $_.ouname -Path $_.oupath
Write-Host -ForegroundColor Green "OU $($_.ouname) is created in the location $($_.oupath)"
}

Lastly, open an elevated Windows PowerShell prompt on DC01 and run the ou.ps1 script:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

Set-Location $home\Setup\Scripts
.\ou.ps1

This will create an OU structure as shown below.

To use the Active Directory Users and Computers console (instead of PowerShell):
On DC01 :
1. Using the Active Directory Users and Computers console (dsa.msc), in the contoso.com domain level, create a
top-level OU named Contoso .
2. In the Contoso OU, create the following OUs:
a. Accounts
b. Computers
c. Groups
3. In the Contoso / Accounts OU, create the following underlying OUs:
a. Admins
b. Service Accounts
c. Users
4. In the Contoso / Computers OU, create the following underlying OUs:
a. Servers
b. Workstations
5. In the Contoso / Groups OU, create the following OU:
a. Security Groups
The final result of either method is shown below. The MDT_BA account will be created next.
Create the MDT service account
When creating a reference image, you need an account for MDT. The MDT build account is used for Windows
Preinstallation Environment (Windows PE) to connect to MDT01.
To create an MDT build account, open an elevated Windows PowerShell prompt on DC01 and enter the
following (copy and paste the entire command, taking care to notice the scroll bar at the bottom). This command
will create the MDT_BA user account and set the password to "pass@word1":

New-ADUser -Name MDT_BA -UserPrincipalName MDT_BA -path "OU=Service

Accounts,OU=Accounts,OU=Contoso,DC=CONTOSO,DC=COM" -Description "MDT Build Account" -AccountPassword
(ConvertTo-SecureString "pass@word1" -AsPlainText -Force) -ChangePasswordAtLogon $false -
PasswordNeverExpires $true -Enabled $true

If you have the Active Directory Users and Computers console open you can refresh the view and see this new
account in the Contoso\Accounts\Ser vice Accounts OU as shown in the screenshot above.

Create and share the logs folder

By default MDT stores the log files locally on the client. In order to capture a reference image, you'll need to
enable server-side logging and, to do that, you'll need to have a folder in which to store the logs. For more
information, see Create a Windows 10 reference image.
On MDT01 :
1. Sign in as CONTOSO\administrator .
2. Create and share the D:\Logs folder by running the following commands in an elevated Windows
PowerShell prompt:

New-Item -Path D:\Logs -ItemType directory

New-SmbShare -Name Logs$ -Path D:\Logs -ChangeAccess EVERYONE
icacls D:\Logs /grant '"MDT_BA":(OI)(CI)(M)'

See the following example:

Use CMTrace to read log files (optional)
The log files in MDT Lite Touch are formatted to be read by Configuration Manager Trace (CMTrace), which is
available as part of the Microsoft System 2012 R2 Center Configuration Manager Toolkit. You should also
download this tool.
You can use Notepad (example below):

Alternatively, CMTrace formatting makes the logs much easier to read. See the same log file below, opened in
CMTrace:
After installing the ConfigMgrTools.msi file, you can search for cmtrace and pin the tool to your taskbar for easy
access.

Next steps
When you've completed all the steps in this section to prepare for deployment, see Create a Windows 10
reference image.

Appendix
Sample files
The following sample files are also available to help automate some MDT deployment tasks. This guide doesn't
use these files, but they're made available here so you can see how some tasks can be automated with Windows
PowerShell.
Set-OUPermissions.ps1. This sample Windows PowerShell script creates a domain account and then
configures OU permissions to allow the account to join machines to the domain in the specified OU.
MDTSample.zip. This sample web service shows you how to configure a computer name dynamically using
MDT.
 Create a Windows 10 reference image
11/23/2022 • 31 minutes to read • Edit Online

Applies to
Windows 10
Creating a reference image is important because that image serves as the foundation for the devices in your
organization. In this article, you 'll learn how to create a Windows 10 reference image using the Microsoft
Deployment Toolkit (MDT). You 'll create a deployment share, configure rules and settings, and import all the
applications and operating system files required to build a Windows 10 reference image. After completing the
steps outlined in this article, you 'll have a Windows 10 reference image that can be used in your deployment
solution.

NOTE
For more information about the server, client, and network infrastructure used in this guide, see Prepare for deployment
with MDT.

For the purposes of this article, we'll use three computers: DC01, MDT01, and HV01.
DC01 is a domain controller for the contoso.com domain.
MDT01 is a contoso.com domain member server.
HV01 is a Hyper-V server that will be used to build the reference image.

Computers used in this article.

The reference image

The reference image described in this guide is designed primarily for deployment to physical devices. However,
the reference image is typically created on a virtual platform, before being automatically run through the
System Preparation (Sysprep) tool process and captured to a Windows Imaging (WIM) file. The reasons for
creating the reference image on a virtual platform are:
To reduce development time and can use snapshots to test different configurations quickly.
To rule out hardware issues. You get the best possible image, and if you've a problem, it's not likely to be
hardware related.
To ensure that you won't have unwanted applications that could be installed as part of a driver install but not
removed by the Sysprep process.
The image is easy to move between lab, test, and production.

Set up the MDT build lab deployment share

With Windows 10, there's no hard requirement to create reference images. However, to reduce the time needed
for deployment, you might want to create a reference image that contains a few base applications and all of the
latest updates. This section will show you how to create and configure the MDT Build Lab deployment share to
create a Windows 10 reference image. Because reference images will be deployed only to virtual machines
during the creation process and have specific settings (rules), you should always create a separate deployment
share specifically for this process.
Create the MDT build lab deployment share
On MDT01 :
Sign in as contoso\administrator using a password of pass@word1 (credentials from the prepare for
deployment article).
Start the MDT deployment workbench, and pin this workbench to the taskbar for easy access.
Using the Deployment Workbench, right-click Deployment Shares and select New Deployment
Share .
Use the following settings for the New Deployment Share Wizard:
Deployment share path: D:\MDTBuildLab
Share name: MDTBuildLab$
Deployment share description: MDT Build Lab
Accept the default selections on the Options page and select Next .
Review the Summary page, select Next , wait for the deployment share to be created, then select Finish .
Verify that you can access the \\MDT01\MDTBuildLab$ share.

The Deployment Workbench with the MDT Build Lab deployment share.
Enable monitoring
To monitor the task sequence as it happens, right-click the MDT Build Lab deployment share, select
Proper ties , select the Monitoring tab, and select Enable monitoring for this deployment share . This step
is optional.
Configure permissions for the deployment share
In order to read files in the deployment share and write the reference image back to it, you need to assign NTFS
and SMB permissions to the MDT Build Account (MDT_BA) for the D:\MDTBuildLab folder
On MDT01 :
1. Ensure you're signed in as contoso\administrator .
2. Modify the NTFS permissions for the D:\MDTBuildLab folder by running the following command in an
elevated Windows PowerShell prompt:

icacls "D:\MDTBuildLab" /grant '"CONTOSO\MDT_BA":(OI)(CI)(M)'

grant-smbshareaccess -Name MDTBuildLab$ -AccountName "Contoso\MDT_BA" -AccessRight Full -force

Add setup files

This section will show you how to populate the MDT deployment share with the Windows 10 operating system
source files, commonly referred to as setup files, which will be used to create a reference image. Setup files are
used during the reference image creation process and are the foundation for the reference image.
Add the Windows 10 installation files
MDT supports adding both full source Windows 10 DVDs (ISOs) and custom images that you've created. In this
case, you create a reference image, so you add the full source setup files from Microsoft.

NOTE
Due to the Windows limits on path length, we are purposely keeping the operating system destination directory short,
using the folder name W10EX64RTM rather than a more descriptive name like Windows 10 Enterprise x64 RTM.

Add Windows 10 Enterprise x64 (full source )

On MDT01 :
1. Sign in as contoso\administrator and copy the content of a Windows 10 Enterprise x64 DVD/ISO to
the D:\Downloads\Windows 10 Enterprise x64 folder on MDT01, or just insert the DVD or mount an
ISO on MDT01. The following example shows the files copied to the D:\Downloads folder, but you can
also choose to import the OS directly from an ISO or DVD.

2. Using the Deployment Workbench, expand the Deployment Shares node, and then expand MDT Build
Lab .
3. Right-click the Operating Systems node, and create a new folder named Windows 10 .
4. Expand the Operating Systems node, right-click the Windows 10 folder, and select Impor t
Operating System . Use the following settings for the Import Operating System Wizard:
Full set of source files
Source directory: (location of your source files)
Destination directory name: W10EX64RTM
5. After adding the operating system, in the Operating Systems / Windows 10 folder, double-click it and
change the name to: Windows 10 Enterprise x64 RTM Default Image . See the following example.

Depending on the DVD you used, there might be multiple editions available. For the purposes of this guide,
we are using the Windows 10 Enterprise image, but other images will also work.

Add applications
Before you create an MDT task sequence, you need to add applications and scripts you wish to install to the MDT
Build Lab share.
On MDT01 :
First, create an MDT folder to store the Microsoft applications that will be installed:
1. In the MDT Deployment Workbench, expand Deployment Shares \ MDT Build Lab \ Applications
2. Right-click Applications and then select New Folder .
3. Under Folder name , type Microsoft .
4. Select Next twice, and then select Finish .
The steps in this section use a strict naming standard for your MDT applications.
Use the "Install - " prefix for typical application installations that run a setup installer of some kind,
Use the "Configure - " prefix when an application configures a setting in the operating system.
You also add an " - x86 ", " - x64 ", or "- x86-x64 " suffix to indicate the application's architecture (some
applications have installers for both architectures).
Using a script naming standard is always recommended when using MDT as it helps maintain order and
consistency.
By storing configuration items as MDT applications, it's easy to move these objects between various solutions, or
between test and production environments.
In example sections, you 'll add the following applications:
Install - Microsoft Office 365 Pro Plus - x64
Install - Microsoft Visual C++ Redistributable 2019 - x86
Install - Microsoft Visual C++ Redistributable 2019 - x64

The 64-bit version of Microsoft Office 365 Pro Plus is recommended unless you need legacy app support.
For more information, see Choose between the 64-bit or 32-bit version of Office

Download links:
Office Deployment Tool
Microsoft Visual C++ Redistributable 2019 - x86
Microsoft Visual C++ Redistributable 2019 - x64
Download all three items in this list to the D:\Downloads folder on MDT01.

NOTE
For the purposes of this lab, we'll leave the MSVC files in the D:\Downloads folder and the Office365 files will be extracted
to a child folder. If you prefer, you can place each application in its own separate child folder, and then modify the
$ApplicationSourcePath below as needed (instead of just D:\Downloads).

NOTE
All the Microsoft Visual C++ downloads can be found on The latest supported Visual C++ downloads. Visual C++ 2015,
2017 and 2019 all share the same redistributable files.

Create configuration file: Microsoft Office 365 Professional Plus x64

1. After downloading the most current version of the Office Deployment tool from the Microsoft Download
Center using the link provided above, run the self-extracting executable file and extract the files to
D:\Downloads\Office365 . The Office Deployment Tool (setup.exe) and several sample
configuration.xml files will be extracted.
2. Using a text editor (such as Notepad), create an XML file in the D:\Downloads\Office365 directory with
the installation settings for Microsoft 365 Apps for enterprise that are appropriate for your organization.
The file uses an XML format, so the file you create must have an extension of .xml but the file can have
any filename.
For example, you can use the following configuration.xml file, which provides these configuration
settings:
Install the 64-bit version of Microsoft 365 Apps for enterprise in English directly from the Office
Content Delivery Network (CDN) on the internet.

NOTE
64-bit is now the default and recommended edition.

Use the General Availability Channel and get updates directly from the Office CDN on the internet.
Perform a silent installation. You won't see anything that shows the progress of the installation and
you won't see any error messages.
 <Configuration>
<Add OfficeClientEdition="64" Channel="Broad">
<Product ID="O365ProPlusRetail">
<Language ID="en-us" />
</Product>
</Add>
<Display Level="None" AcceptEULA="TRUE" />
<Updates Enabled="TRUE" />
</Configuration>

When you use these settings, anytime you build the reference image you'll be installing the most up-to-
date General Availability Channel version of Microsoft 365 Apps for enterprise.

TIP
You can also use the web-based interface of the Office Customization Tool to help you create your configuration.xml file.

For more information, see Configuration options for the Office Deployment Tool and Overview of the Office
Deployment Tool.
3. Ensure the configuration.xml file is in the D:\Downloads\Office365 folder. See the following example of
the extracted files plus the configuration.xml file in the Downloads\Office365 folder:

Assuming you've named the file "configuration.xml" as shown above, we'll use the command "setup.exe
/configure configuration.xml " when we create the application in MDT. This command execution will perform
the installation of Microsoft 365 Apps for enterprise using the configuration settings in the configuration.xml
file. Don't perform this step yet.

IMPORTANT
After Microsoft 365 Apps for enterprise is installed on the reference image, do NOT open any Office programs. if you
open an Office program, you're prompted to sign-in, which activates the installation of Microsoft 365 Apps for enterprise.
Even if you don't sign in and you close the Sign in to set up Office dialog box, a temporary product key is installed. You
don't want any kind of product key for Microsoft 365 Apps for enterprise installed as part of your reference image.

Additional information
 Microsoft 365 Apps for enterprise is updated on a monthly basis with security updates and other quality
updates (bug fixes), and possibly new features (depending on which update channel you're using). That
means that once you've deployed your reference image, Microsoft 365 Apps for enterprise will most
likely need to download and install the latest updates that have been released since you created your
reference image.
Note : With the installing Office Deployment Tool being used as part of the reference image, Microsoft
365 Apps for enterprise is installed immediately after the reference image is deployed to the user's
device, rather than including Office apps part of the reference image. This way the user will have the most
up-to-date version of Microsoft 365 Apps for enterprise right away and won't have to download any new
updates (which is most likely what would happen if Microsoft 365 Apps for enterprise was installed as
part of the reference image.)
When you're creating your reference image, instead of installing Microsoft 365 Apps for enterprise
directly from the Office CDN on the internet, you can install Microsoft 365 Apps for enterprise from a
location on your local network, such as a file share. To do that, you would use the Office Deployment Tool
in /download mode to download the installation files to that file share. Then you could use the Office
Deployment Tool in /configure mode to install Microsoft 365 Apps for enterprise from that location on to
your reference image. As part of that process, you'll need to point to that location in your
configuration.xml file so that the Office Deployment Tool knows where to get the Microsoft 365 Apps for
enterprise files. If you decide to do this step, the next time you create a new reference image, you'll want
to be sure to use the Office Deployment Tool to download the most up-to-date installation files for
Microsoft 365 Apps for enterprise to that location on your internal network. That way your new reference
image will have a more up-to-date installation of Microsoft 365 Apps for enterprise.
Connect to the deployment share using Windows PowerShell
If you need to add many applications, you can take advantage of the PowerShell support that MDT has. To start
using PowerShell against the deployment share, you must first load the MDT PowerShell snap-in, and then make
the deployment share a PowerShell drive (PSDrive).
On MDT01 :
1. Ensure you're signed in as contoso\Administrator .
2. Import the snap-in and create the PSDrive by running the following commands in an elevated PowerShell
prompt:

Import-Module "C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1"

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "D:\MDTBuildLab"

TIP
Use "Get-Command -module MicrosoftDeploymentToolkit" to see a list of available cmdlets

Create the install: Microsoft Office 365 Pro Plus - x64

In these steps, we assume that you've downloaded the Office Deployment Tool. You might need to modify the
path to the source folder to reflect your current environment. In this example, the source path is set to
D:\Downloads\Office365.
On MDT01 :
1. Ensure you're signed on as contoso\Administrator .
2. Create the application by running the following commands in an elevated PowerShell prompt:
 $ApplicationName = "Install - Office365 ProPlus - x64"
$CommandLine = "setup.exe /configure configuration.xml"
$ApplicationSourcePath = "D:\Downloads\Office365"
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -
ShortName $ApplicationName -CommandLine $CommandLine -WorkingDirectory
".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder
$ApplicationName -Verbose

Upon successful installation, the following text is displayed:

VERBOSE: Performing the operation "import" on target "Application".

VERBOSE: Beginning application import
VERBOSE: Copying application source files from D:\Downloads\Office365 to
D:\MDTBuildLab\Applications\Install -
Office365 ProPlus - x64
VERBOSE: Creating new item named Install - Office365 ProPlus - x64 at DS001:\Applications\Microsoft.

Name
----
Install - Office365 ProPlus - x64
VERBOSE: Import processing finished.

Create the install: Microsoft Visual C++ Redistributable 2019 - x86

NOTE
We have abbreviated "Microsoft Visual C++ Redistributable" in the $ApplicationName below as "MSVC" to avoid the path
name exceeding the maxiumum allowed length of 248 characters.

In these steps, we assume that you've downloaded Microsoft Visual C++ Redistributable 2019 - x86. You might
need to modify the path to the source folder to reflect your current environment. In this example, the source
path is set to D:\Downloads.
On MDT01 :
1. Ensure you're signed on as contoso\Administrator .
2. Create the application by running the following commands in an elevated PowerShell prompt:

$ApplicationName = "Install - MSVC 2019 - x86"

$CommandLine = "vc_redist.x86.exe /Q"
$ApplicationSourcePath = "D:\Downloads"
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -
ShortName $ApplicationName -CommandLine $CommandLine -WorkingDirectory
".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder
$ApplicationName -Verbose

Upon successful installation, the following text is displayed:

 VERBOSE: Performing the operation "import" on target "Application".
VERBOSE: Beginning application import
VERBOSE: Copying application source files from D:\Downloads to D:\MDTBuildLab\Applications\Install -
MSVC 2019 - x86
VERBOSE: Creating new item named Install - MSVC 2019 - x86 at DS001:\Applications\Microsoft.

Name
----
Install - MSVC 2019 - x86
VERBOSE: Import processing finished.

Create the install: Microsoft Visual C++ Redistributable 2019 - x64

In these steps, we assume that you've downloaded Microsoft Visual C++ Redistributable 2019 - x64. You might
need to modify the path to the source folder to reflect your current environment. In this example, the source
path is set to D:\Downloads.
On MDT01 :
1. Ensure you're signed on as contoso\Administrator .
2. Create the application by running the following commands in an elevated PowerShell prompt:

$ApplicationName = "Install - MSVC 2019 - x64"

$CommandLine = "vc_redist.x64.exe /Q"
$ApplicationSourcePath = "D:\Downloads"
Import-MDTApplication -Path "DS001:\Applications\Microsoft" -Enable "True" -Name $ApplicationName -
ShortName $ApplicationName -CommandLine $CommandLine -WorkingDirectory
".\Applications\$ApplicationName" -ApplicationSourcePath $ApplicationSourcePath -DestinationFolder
$ApplicationName -Verbose

Create the reference image task sequence

In order to build and capture your Windows 10 reference image for deployment using MDT, you 'll create a task
sequence. The task sequence will reference the operating system and applications that you previously imported
into the MDT Build Lab deployment share to build a Windows 10 reference image. After creating the task
sequence, you configure it to enable patching against the Windows Server Update Services (WSUS) server. The
Task Sequence Windows Update action supports getting updates directly from Microsoft Update, but you get
more stable patching if you use a local WSUS server. WSUS also allows for an easy process of approving the
patches that you're deploying.
Drivers and the reference image
Because we use modern virtual platforms for creating our reference images, we don't need to worry about
drivers when creating reference images for Windows 10. We use Hyper-V in our environment, and Windows
Preinstallation Environment (Windows PE) already has all the needed drivers built-in for Hyper-V.
Create a task sequence for Windows 10 Enterprise
To create a Windows 10 reference image task sequence, the process is as follows:
On MDT01 :
1. When you're using the Deployment Workbench, under Deployment Shares > MDT Build Lab right-click
Task Sequences , and create a New Folder named Windows 10 .
2. Right-click the new Windows 10 folder and select New Task Sequence . Use the following settings for the
New Task Sequence Wizard:
a. Task sequence ID: REFW10X64-001
b. Task sequence name: Windows 10 Enterprise x64 RTM Default Image
 c. Task sequence comments: Reference Build
d. Template: Standard Client Task Sequence
e. Select OS: Windows 10 Enterprise x64 RTM Default Image
f. Specify Product Key: Don't specify a product key at this time
g. Full Name: Contoso
h. Organization: Contoso
i. Internet Explorer home page: http://www.contoso.com
j. Admin Password: Don't specify an Administrator Password at this time
Edit the Windows 10 task sequence
The steps below walk you through the process of editing the Windows 10 reference image task sequence to
include the actions required to update the reference image with the latest updates from WSUS, install roles and
features, and utilities, and install Microsoft Office365 ProPlus x64.
On MDT01 :
1. In the Task Sequences / Windows 10 folder, right-click the Windows 10 Enterprise x64 RTM Default
Image task sequence, and select Proper ties .
2. On the Task Sequence tab, configure the Windows 10 Enterprise x64 RTM Default Image task sequence
with the following settings:
a. State Restore > Windows Update (Pre-Application Installation) action: Enable this action
by clicking the Options tab and clearing the Disable this step check box.
b. State Restore > Windows Update (Post-Application Installation) action: Also enable this
action.
c. State Restore : After the Tattoo action, add a new Group action (select Add then select New
Group ) with the following setting:
Name: Custom Tasks (Pre-Windows Update)
d. State Restore : After Windows Update (Post-Application Installation) action, rename
Custom Tasks to Custom Tasks (Post-Windows Update) .
Note : The reason for adding the applications after the Tattoo action but before running
Windows Update is simply to save time during the deployment. This way we can add all
applications that will upgrade some of the built-in components and avoid unnecessary
updating.
e. State Restore > Custom Tasks (Pre-Windows Update) : Add a new Install Roles and
Features action with the following settings:
a. Name: Install - Microsoft NET Framework 3.5.1
b. Select the operating system for which roles are to be installed: Windows 10
c. Select the roles and features that should be installed: .NET Framework 3.5 (includes .NET 2.0
and 3.0)

IMPORTANT
This is probably the most important step when creating a reference image. Many applications need the
.NET Framework, and we strongly recommend having it available in the image. The one thing that makes
this different from other components is that .NET Framework 3.5.1 is not included in the WIM file. It's
installed from the Sources\SxS folder on the media, and that makes it more difficult to add after the
image has been deployed.
 The task sequence after creating the Custom Tasks (Pre-Windows Update) group and adding the
Install - Microsoft NET Framework 3.5.1 action.
f. State Restore > Custom Tasks (Pre-Windows Update) : After the Install - Microsoft NET
Framework 3.5.1 action, add a new Install Application action (selected from the General
group) with the following settings:
a. Name: Microsoft Visual C++ Redistributable 2019 - x86
b. Install a Single Application: browse to Install - MSVC 2019 - x86
g. Repeat these steps (add a new Install Application ) to add Microsoft Visual C++ Redistributable
2019 - x64 and Microsoft 365 Apps for enterprise as well.
3. Select OK .
Optional configuration: Add a suspend action
The goal when creating a reference image is to automate everything. But sometimes you've a special
configuration or application setup that is too time-consuming to automate. If you need to do some manual
configuration, you can add a little-known feature called Lite Touch Installation (LTI) Suspend. If you add the
LTISuspend.wsf script as a custom action in the task sequence, it will suspend the task sequence until you select
the Resume Task Sequence shortcut icon on the desktop. In addition to using the LTI Suspend feature for manual
configuration or installation, you can also use it simply for verifying a reference image before you allow the task
sequence to continue and use Sysprep and capture the virtual machine.
A task sequence with optional Suspend action (LTISuspend.wsf) added.

The Windows 10 desktop with the Resume Task Sequence shortcut.

Edit the Unattend.xml file for Windows 10 Enterprise
When using MDT, you don't need to edit the Unattend.xml file often because most configurations are taken care
of by MDT. However if, for example, you want to configure Internet Explorer behavior, then you can edit the
Unattend.xml. Editing the Unattend.xml for basic Internet Explorer settings is easy, but for more advanced
settings, you 'll want to use the Internet Explorer Administration Kit (IEAK).

WARNING
Don't use SkipMachineOOBE or SkipUserOOBE in your Unattend.xml file. These settings are deprecated and can have
unintended effects if used.

NOTE
You also can use the Unattend.xml to enable components in Windows 10, like the Telnet Client or Hyper-V client. Normally
we prefer to do this via the Install Roles and Features action, or using Deployment Image Servicing and Management
(DISM) command-line tools, because then we can add that as an application, being dynamic, having conditions, and so
forth. Also, if you're adding packages via Unattend.xml, it's version specific, so Unattend.xml must match the exact version
of the operating system you're servicing.

Follow these steps to configure Internet Explorer settings in Unattend.xml for the Windows 10 Enterprise x64
RTM Default Image task sequence:
On MDT01 :
1. When you're using the Deployment Workbench, under Deployment Shares > MDT Build Lab > Task
Sequences right-click the Windows 10 Enterprise x64 RTM Default Image task sequence and select
Proper ties .
2. In the OS Info tab, select Edit Unattend.xml . MDT now generates a catalog file. This file generation process
will take a few minutes, and then Windows System Image Manager (Windows SIM) will start.

IMPORTANT
The ADK version 1903 has a known issue generating a catalog file for Windows 10, version 1903 or 1909 X64 install.wim.
You might see the error "Could not load file or assembly" in in the console output. To avoid this issue, install the ADK,
version 2004 or a later version. A workaround is also available for the ADK version 1903:
Close the Deployment Workbench and install the WSIM 1903 update. This will update imagecat.exe and imgmgr.exe to
version 10.0.18362.144.
Manually run imgmgr.exe (C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment
Tools\WSIM\imgmgr.exe).
Generate a catalog (Tools/Create Catalog) for the selected install.wim (ex: D:\MDTBuildLab\Operating
Systems\W10EX64RTM\sources\install.wim).
After manually creating the catalog file (ex: D:\MDTBuildLab\Operating
Systems\W10EX64RTM\sources\install_Windows 10 Enterprise.clg), open the Deployment Workbench and proceed to
edit unattend.xml.

3. In Windows SIM, expand the 4 specialize node in the Answer File pane and select the amd64_Microsoft-
Windows-IE-InternetExplorer_neutral entry.
4. In the amd64_Microsoft-Windows-IE-InternetExplorer_neutral proper ties window (right-hand
window), set the following values:
DisableDevTools: true
5. Save the Unattend.xml file, and close Windows SIM.

NOTE
If errors are reported that certain display values are incorrect, you can ignore this message or browse to
7oobeSystem\amd64_Microsoft-Windows-Shell-Setup__neutral\Display and enter the following:
ColorDepth 32, HorizontalResolution 1, RefreshRate 60, VerticalResolution 1.

6. On the Windows 10 Enterprise x64 RTM Default Image Properties, select OK .

Windows System Image Manager with the Windows 10 Unattend.xml.

Configure the MDT deployment share rules

Understanding rules is critical to successfully using MDT. Rules are configured using the Rules tab of the
deployment share's properties. The Rules tab is essentially a shortcut to edit the CustomSettings.ini file that
exists in the D:\MDTBuildLab\Control folder. This section discusses how to configure the MDT deployment
share rules as part of your Windows 10 Enterprise deployment.
MDT deployment share rules overview
In MDT, there are always two rule files: the CustomSettings.ini file and the Bootstrap.ini file. You can add
almost any rule to either. However, the Bootstrap.ini file is copied from the Control folder to the boot image, so
the boot image needs to be updated every time you change that file. For this reason, add only a minimal set of
rules to Bootstrap.ini, such as which deployment server and share to connect to - the DEPLOYROOT value. Put
the other rules in CustomSettings.ini because that file is updated immediately when you select OK.
To configure the rules for the MDT Build Lab deployment share:
On MDT01 :
1. Using the Deployment Workbench, right-click the MDT Build Lab deployment share and select
 Proper ties .
2. Select the Rules tab and replace the existing content with the following information (edit the settings as
needed to match your deployment). For example, If you don't have a WSUS server in your environment,
delete the WSUSSer ver line from the configuration:

[Settings]
Priority=Default

[Default]
_SMSTSORGNAME=Contoso
UserDataLocation=NONE
DoCapture=YES
OSInstall=Y
AdminPassword=pass@word1
TimeZoneName=Pacific Standard Time
JoinWorkgroup=WORKGROUP
HideShell=YES
FinishAction=SHUTDOWN
DoNotCreateExtraPartition=YES
WSUSServer=http://mdt01.contoso.com:8530
ApplyGPOPack=NO
SLSHARE=\\MDT01\Logs$
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=YES
SkipDomainMembership=YES
SkipUserData=YES
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=YES
SkipBitLocker=YES
SkipSummary=YES
SkipRoles=YES
SkipCapture=NO
SkipFinalSummary=YES
 The server-side rules for the MDT Build Lab deployment share.
3. Select Edit Bootstrap.ini and modify using the following information:

[Settings]
Priority=Default

[Default]
DeployRoot=\\MDT01\MDTBuildLab$
UserDomain=CONTOSO
UserID=MDT_BA
UserPassword=pass@word1

SkipBDDWelcome=YES

NOTE
For security reasons, you normally don't add the password to the Bootstrap.ini file; however, because this
deployment share is for creating reference image builds only, and should not be published to the production
network, it's acceptable to do so in this situation. Obviously if you're not using the same password (pass@word3)
that is provided in this lab, you must enter your own custom password on the Rules tab and in Bootstrap.ini.

4. On the Windows PE tab, in the Platform drop-down list, select x86 .

5. In the Lite Touch Boot Image Settings area, configure the following settings:
a. Image description: MDT Build Lab x86
b. ISO file name: MDT Build Lab x86.iso
6. On the Windows PE tab, in the Platform drop-down list, select x64 .
7. In the Lite Touch Boot Image Settings area, configure the following settings:
a. Image description: MDT Build Lab x64
b. ISO file name: MDT Build Lab x64.iso
8. Select OK .

NOTE
In MDT, the x86 boot image can deploy both x86 and x64 operating systems (except on computers based on Unified
Extensible Firmware Interface).

Update the deployment share

After the deployment share has been configured, it needs to be updated. This update-process is the one when
the Windows PE boot images are created.
1. In the Deployment Workbench, right-click the MDT Build Lab deployment share and select Update
Deployment Share .
2. Use the default options for the Update Deployment Share Wizard.

NOTE
The update process will take 5 to 10 minutes.

The rules explained

Now that the MDT Build Lab deployment share (the share used to create the reference images) has been
configured, it's time to explain the various settings used in the Bootstrap.ini and CustomSettings.ini files.
The Bootstrap.ini and CustomSettings.ini files work together. The Bootstrap.ini file is always present on the boot
image and is read first. The basic purpose for Bootstrap.ini is to provide enough information for MDT to find the
CustomSettings.ini.
The CustomSettings.ini file is normally stored on the server, in the Deployment share\Control folder, but also can
be stored on the media (when using offline media).

NOTE
The settings, or properties, that are used in the rules (CustomSettings.ini and Bootstrap.ini) are listed in the MDT
documentation, in the Microsoft Deployment Toolkit Reference / Properties / Property Definition section.

The Bootstrap.ini file

The Bootstrap.ini file is available via the deployment share's Properties dialog box, or via the
D:\MDTBuildLab\Control folder on MDT01.

[Settings]
Priority=Default
[Default]
DeployRoot=\\MDT01\MDTBuildLab$
UserDomain=CONTOSO
UserID=MDT_BA
UserPassword=pass@word1
SkipBDDWelcome=YES

So, what are these settings?

 Priority. This setting determines the order in which different sections are read. This Bootstrap.ini has
only one section, named [Default].
DeployRoot. This location is of the deployment share. Normally, this value is set by MDT, but you need
to update the DeployRoot value if you move to another server or other share. If you don't specify a value,
the Windows Deployment Wizard prompts you for a location.
UserDomain, UserID, and UserPassword. These values are used for automatic sign in to the
deployment share. Again, if they aren't specified, the wizard prompts you.

WARNING
Caution is advised. These values are stored in clear text on the boot image. Use them only for the MDT Build Lab
deployment share and not for the MDT Production deployment share that you learn to create in the next topic.

SkipBDDWelcome. Even if it's nice to be welcomed every time we start a deployment, we prefer to skip
the initial welcome page of the Windows Deployment Wizard.

NOTE
All properties beginning with "Skip" control only whether to display that pane in the Windows Deployment Wizard. Most
of the panes also require you to actually set one or more values.

The CustomSettings.ini file

The CustomSettings.ini file, whose content you see on the Rules tab of the deployment share Properties dialog
box, contains most of the properties used in the configuration.

[Settings]
Priority=Default
[Default]
_SMSTSORGNAME=Contoso
UserDataLocation=NONE
DoCapture=YES
OSInstall=Y
AdminPassword=pass@word1
TimeZoneName=Pacific Standard Time
JoinWorkgroup=WORKGROUP
HideShell=YES
FinishAction=SHUTDOWN
DoNotCreateExtraPartition=YES
WSUSServer=http://mdt01.contoso.com:8530
ApplyGPOPack=NO
SLSHARE=\\MDT01\Logs$
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=YES
SkipDomainMembership=YES
SkipUserData=YES
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=YES
SkipBitLocker=YES
SkipSummary=YES
SkipRoles=YES
SkipCapture=NO
SkipFinalSummary=YES

Priority. Has the same function as in Bootstrap.ini. Priority determines the order in which different
sections are read. This CustomSettings.ini has only one section, named [Default]. In general, if you've
multiple sections that set the same value, the value from the first section (higher priority) wins. The rare
exceptions are listed in the ZTIGather.xml file.
_SMSTSORGNAME. The organization name displayed in the task sequence progress bar window during
deployment.
UserDataLocation. Controls the settings for user state backup. You don't need to use when building and
capturing a reference image.
DoCapture. Configures the task sequence to run the System Preparation (Sysprep) tool and capture the
image to a file when the operating system is installed.
OSInstall. Must be set to Y or YES (the code just looks for the Y character) for the setup to proceed.
AdminPassword. Sets the local Administrator account password.
TimeZoneName. Establishes the time zone to use. Don't confuse this value with TimeZone, which is only
for legacy operating systems (Windows 7 and Windows Server 2003).

NOTE
The easiest way to find the current time zone name on a Windows 10 machine is to run tzutil /g in a command
prompt. You can also run tzutil /l to get a listing of all available time zone names.

JoinWorkgroup. Configures Windows to join a workgroup.

HideShell. Hides the Windows Shell during deployment. This hide-operation is especially useful for
Windows 10 deployments in which the deployment wizard will otherwise appear behind the tiles.
FinishAction. Instructs MDT what to do when the task sequence is complete.
DoNotCreateExtraPar tition. Configures the task sequence not to create the extra partition for
BitLocker. There's no need to do this configuration for your reference image.
WSUSSer ver. Specifies which Windows Server Update Services (WSUS) server (and port, if needed) to
use during the deployment. Without this option MDT will use Microsoft Update directly, which will
increase deployment time and limit your options of controlling which updates are applied.
SLSHARE. Instructs MDT to copy the log files to a server share if something goes wrong during
deployment, or when a deployment is successfully completed.
ApplyGPOPack . Allows you to deploy local group policies created by Microsoft Security Compliance
Manager (SCM).
SkipAdminPassword. Skips the pane that asks for the Administrator password.
SkipProductKey. Skips the pane that asks for the product key.
SkipComputerName. Skips the Computer Name pane.
SkipDomainMemberShip. Skips the Domain Membership pane. If set to Yes, you need to configure
either the JoinWorkgroup value or the JoinDomain, DomainAdmin, DomainAdminDomain, and
DomainAdminPassword properties.
SkipUserData. Skips the pane for user state migration.
SkipLocaleSelection. Skips the pane for selecting language and keyboard settings.
SkipTimeZone. Skips the pane for setting the time zone.
 SkipApplications. Skips the Applications pane.
SkipBitLocker. Skips the BitLocker pane.
SkipSummar y. Skips the initial Windows Deployment Wizard summary pane.
SkipRoles. Skips the Install Roles and Features pane.
SkipCapture. Skips the Capture pane.
SkipFinalSummar y. Skips the final Windows Deployment Wizard summary. Because you use
FinishAction=Shutdown, you don't want the wizard to stop in the end so that you need to select OK
before the machine shuts down.

Build the Windows 10 reference image

As previously described, this section requires a Hyper-V host. For more information, see Hyper-V requirements.
Once you've created your task sequence, you're ready to create the Windows 10 reference image. This image
creation will be performed by launching the task sequence from a virtual machine that will then automatically
perform the reference image creation and capture process.
The steps below outline the process used to boot a virtual machine using an ISO boot image created by MDT,
and then run the reference image task sequence image to create and capture the Windows 10 reference image.
1. Copy D:\MDTBuildLab\Boot\MDT Build Lab x86.iso on MDT01 to C:\ISO on your Hyper-V host (HV01).

NOTE
Remember, in MDT you can use the x86 boot image to deploy both x86 and x64 operating system images. That's
why you can use the x86 boot image instead of the x64 boot image.

On HV01 :
2. Create a new virtual machine with the following settings:
a. Name: REFW10X64-001
b. Store the virtual machine in a different location: C:\VM
c. Generation 1
d. Memory: 1024 MB
e. Network: Must be able to connect to \MDT01\MDTBuildLab$
f. Hard disk: 60 GB (dynamic disk)
g. Install OS with image file: C:\ISO\MDT Build Lab x86.iso
3. Before you start the VM, add a checkpoint for REFW10X64-001, and name it Clean with MDT Build
Lab x86 ISO .

NOTE
Checkpoints are useful if you need to restart the process and want to make sure you can start clean.

4. Start the REFW10X64-001 virtual machine and connect to it.

 NOTE
Up to this point we haven't discussed IP addressing or DHCP. In the initial setup for this guide, DC01 was
provisioned as a DHCP server to provide IP address leases to client computers. You might have a different DHCP
server on your network that you wish to use. The REFW10X64-001 virtual machine requires an IP address lease
that provides it with connectivity to MDT01 so that it can connect to the \MDT01\MDTBuildLab$ share. In the
current scenario, this connectivity is accomplished with a DHCP scope that provides IP addresses in the
10.10.10.100 - 10.10.10.200 range, as part of a /24 subnet so that the client can connect to MDT01 at
10.10.10.11.

After booting into Windows PE, complete the Windows Deployment Wizard with the following settings:
a. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Default
Image
b. Specify whether to capture an image: Capture an image of this reference computer
Location: \\MDT01\MDTBuildLab$\Captures
c. File name: REFW10X64-001.wim

The Windows Deployment Wizard for the Windows 10 reference image.

5. The setup now starts and does the following steps:
a. Installs the Windows 10 Enterprise operating system.
b. Installs the added applications, roles, and features.
c. Updates the operating system via your local Windows Server Update Services (WSUS) server.
d. Stages Windows PE on the local disk.
e. Runs System Preparation (Sysprep) and reboots into Windows PE.
f. Captures the installation to a Windows Imaging (WIM) file.
g. Turns off the virtual machine.
After some time, you 'll have a Windows 10 Enterprise x64 image that is fully patched and has run through
Sysprep, located in the D:\MDTBuildLab\Captures folder on your deployment server. The file name is
REFW10X64-001.wim.

Troubleshooting
IMPORTANT
If you encounter errors applying the image when using a BIOS firmware type, see Windows 10 deployments fail with
Microsoft Deployment Toolkit on computers with BIOS type firmware. This

If you enabled monitoring, you can check the progress of the task sequence.

If there are problems with your task sequence, you can troubleshoot in Windows PE by pressing F8 to open a
command prompt. There are several MDT log files created that can be helpful determining the origin of an error,
such as BDD.log. From the command line in Windows PE, you can copy these logs from the client to your MDT
server for viewing with CMTrace. For example: copy BDD.log \\mdt01\logs$.
After some time, you 'll have a Windows 10 Enterprise x64 image that is fully patched and has run through
Sysprep, located in the D:\MDTBuildLab\Captures folder on your deployment server. The file name is
REFW10X64-001.wim.

Related articles
Get started with the Microsoft Deployment Toolkit (MDT)
Deploy a Windows 10 image using MDT
Build a distributed environment for Windows 10 deployment
Refresh a Windows 7 computer with Windows 10
Replace a Windows 7 computer with a Windows 10 computer
Configure MDT settings
 Deploy a Windows 10 image using MDT
11/23/2022 • 28 minutes to read • Edit Online

Applies to
Windows 10
This article will show you how to take your reference image for Windows 10 (that was created), and deploy that
image to your environment using the Microsoft Deployment Toolkit (MDT).
We'll prepare for this deployment by creating an MDT deployment share that is used solely for image
deployment. Separating the processes of creating reference images from the processes used to deploy them in
production allows greater control of on both processes. We'll configure Active Directory permissions, configure
the deployment share, create a new task sequence, and add applications, drivers, and rules.
For the purposes of this article, we'll use four computers: DC01, MDT01, HV01 and PC0005.
DC01 is a domain controller
MDT01 is a domain member server
HV01 is a Hyper-V server
PC0005 is a blank device to which we'll deploy Windows 10
MDT01 and PC0005 are members of the domain contoso.com for the fictitious Contoso Corporation. HV01 used
to test deployment of PC0005 in a virtual environment.

NOTE
For details about the setup for the procedures in this article, please see Prepare for deployment with MDT.

Step 1: Configure Active Directory permissions

These steps will show you how to configure an Active Directory account with the permissions required to deploy
a Windows 10 machine to the domain using MDT. These steps assume you've The account is used for Windows
Preinstallation Environment (Windows PE) to connect to MDT01. In order for MDT to join machines into the
contoso.com domain you need to create an account and configure permissions in Active Directory.
On DC01 :
1. Download the Set-OUPermissions.ps1 script and copy it to the C:\Setup\Scripts directory on DC01 .
This script configures permissions to allow the MDT_JD account to manage computer accounts in the
contoso > Computers organizational unit.
2. Create the MDT_JD service account by running the following command from an elevated Windows
PowerShell prompt :
 New-ADUser -Name MDT_JD -UserPrincipalName [email protected] -path "OU=Service
Accounts,OU=Accounts,OU=Contoso,DC=CONTOSO,DC=COM" -Description "MDT join domain account" -
AccountPassword (ConvertTo-SecureString "pass@word1" -AsPlainText -Force) -ChangePasswordAtLogon
$false -PasswordNeverExpires $true -Enabled $true

3. Next, run the Set-OuPermissions script to apply permissions to the MDT_JD service account, enabling it
to manage computer accounts in the Contoso / Computers OU. Run the following commands from an
elevated Windows PowerShell prompt:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

Set-Location C:\Setup\Scripts
.\Set-OUPermissions.ps1 -Account MDT_JD -TargetOU "OU=Workstations,OU=Computers,OU=Contoso"

The following list is of the permissions being granted:

Scope: This object and all descendant objects
Create Computer objects
Delete Computer objects
Scope: Descendant Computer objects
Read All Properties
Write All Properties
Read Permissions
Modify Permissions
Change Password
Reset Password
Validated write to DNS host name
Validated write to service principal name

Step 2: Set up the MDT production deployment share

Next, create a new MDT deployment share. You shouldn't use the same deployment share that you used to
create the reference image for a production deployment. Perform this procedure on the MDT01 server.
Create the MDT production deployment share
On MDT01 :
The steps for creating the deployment share for production are the same as when you created the deployment
share for creating the custom reference image:
1. Ensure you're signed on as: contoso\administrator.
2. In the Deployment Workbench console, right-click Deployment Shares and select New Deployment
Share .
3. On the Path page, in the Deployment share path text box, type D:\MDTProduction and select Next .
4. On the Share page, in the Share name text box, type MDTProduction$ and select Next .
5. On the Descriptive Name page, in the Deployment share description text box, type MDT
Production and select Next .
6. On the Options page, accept the default settings and select Next twice, and then select Finish .
7. Using File Explorer, verify that you can access the \\MDT01\MDTProduction$ share.
Configure permissions for the production deployment share
To read files in the deployment share, you need to assign NTFS and SMB permissions to the MDT Build Account
(MDT_BA) for the D:\MDTProduction folder
On MDT01 :
1. Ensure you're signed in as contoso\administrator .
2. Modify the NTFS permissions for the D:\MDTProduction folder by running the following command in
an elevated Windows PowerShell prompt:

icacls "D:\MDTProduction" /grant '"CONTOSO\MDT_BA":(OI)(CI)(M)'

grant-smbshareaccess -Name MDTProduction$ -AccountName "Contoso\MDT_BA" -AccessRight Full -force

Step 3: Add a custom image

The next step is to add a reference image into the deployment share with the setup files required to successfully
deploy Windows 10. When adding a custom image, you still need to copy setup files (an option in the wizard)
because Windows 10 stores other components in the Sources\SxS folder that is outside the image and may be
required when installing components.
Add the Windows 10 Enterprise x64 RTM custom image
In these steps, we assume that you've completed the steps in the Create a Windows 10 reference image article,
so you've a Windows 10 reference image at D:\MDTBuildLab\Captures\REFW10X64-001.wim on MDT01.
1. Using the Deployment Workbench, expand the Deployment Shares node, and then expand MDT
Production ; select the Operating Systems node, and create a folder named Windows 10 .
2. Right-click the Windows 10 folder and select Impor t Operating System .
3. On the OS Type page, select Custom image file and select Next .
4. On the Image page, in the Source file text box, browse to D:\MDTBuildLab\Captures\REFW10X64-
001.wim and select Next .
5. On the Setup page, select the Copy Windows 7, Windows Ser ver 2008 R2, or later setup files
from the specified path option; in the Setup source director y text box, browse to
D:\MDTBuildLab\Operating Systems\W10EX64RTM and select Next .
6. On the Destination page, in the Destination director y name text box, type W10EX64RTM , select
Next twice, and then select Finish .
7. After adding the operating system, double-click the added operating system name in the Operating
Systems / Windows 10 node and change the name to Windows 10 Enterprise x64 RTM Custom
Image .

NOTE
The reason for adding the setup files has changed since earlier versions of MDT. MDT 2010 used the setup files to install
Windows. MDT uses DISM to apply the image; however, you still need the setup files because some components in roles
and features are stored outside the main image.
 Step 4: Add an application
When you configure your MDT Build Lab deployment share, you can also add applications to the new
deployment share before creating your task sequence. This section walks you through the process of adding an
application to the MDT Production deployment share using Adobe Reader as an example.
Create the install: Adobe Reader DC
On MDT01 :
1. Download the Enterprise distribution version of Adobe Acrobat Reader DC
(AcroRdrDC2200320282_en_US.exe) to D:\setup\adobe on MDT01.
2. Extract the .exe file that you downloaded to a .msi (ex: .\AcroRdrDC2200320282_en_US.exe -
sfx_o"d:\setup\adobe\install" -sfx_ne).
3. In the Deployment Workbench, expand the MDT Production node and navigate to the Applications
node.
4. Right-click the Applications node, and create a new folder named Adobe .
5. In the Applications node, right-click the Adobe folder and select New Application .
6. On the Application Type page, select the Application with source files option and select Next .
7. On the Details page, in the Application Name text box, type Install - Adobe Reader and select Next*.
8. On the Source page, in the Source Director y text box, browse to D:\setup\adobe\install and select
Next .
9. On the Destination page, in the Specify the name of the director y that should be created text
box, type Install - Adobe Reader and select Next .
10. On the Command Details page, in the Command Line text box, type msiexec /i AcroRead.msi /q ,
select Next twice, and then select Finish .
 The Adobe Reader application added to the Deployment Workbench.

Step 5: Prepare the drivers repository

In order to deploy Windows 10 with MDT successfully, you need drivers for the boot images and for the actual
operating system. This section will show you how to add drivers for the boot image and operating system, using
the following hardware models as examples:
Lenovo ThinkPad T420
Dell Latitude 7390
HP EliteBook 8560w
Microsoft Surface Pro
For boot images, you need to have storage and network drivers; for the operating system, you need to have the
full suite of drivers.

NOTE
You should only add drivers to the Windows PE images if the default drivers don't work. Adding drivers that are not
necessary will only make the boot image larger and potentially delay the download time.

Create the driver source structure in the file system

The key to successful management of drivers for MDT, and for any other deployment solution, is to have a good
driver repository. From this repository, you import drivers into MDT for deployment, but you should always
maintain the repository for future use.
On MDT01 :

IMPORTANT
In the steps below, it's critical that the folder names used for various computer makes and models exactly match the
results of wmic computersystem get model,manufacturer on the target system.

1. Using File Explorer, create the D:\drivers folder.

2. In the D:\drivers folder, create the following folder structure:
 a. WinPE x86
b. WinPE x64
c. Windows 10 x64
3. In the new Windows 10 x64 folder, create the following folder structure:
Dell Inc.
Latitude E7450
Hewlett-Packard
HP EliteBook 8560w
Lenovo
ThinkStation P500 (30A6003TUS)
Microsoft Corporation
Surface Laptop

NOTE
Even if you're not going to use both x86 and x64 boot images, we still recommend that you add the support structure for
future use.

Create the logical driver structure in MDT

When you import drivers to the MDT driver repository, MDT creates a single instance folder structure based on
driver class names. However, you can, and should, mimic the driver structure of your driver source repository in
the Deployment Workbench. This mimic is done by creating logical folders in the Deployment Workbench.
1. On MDT01, using Deployment Workbench, select the Out-of-Box Drivers node.
2. In the Out-Of-Box Drivers node, create the following folder structure:
a. WinPE x86
b. WinPE x64
c. Windows 10 x64
3. In the Windows 10 x64 folder, create the following folder structure:
Dell Inc.
Latitude E7450
Hewlett-Packard
HP EliteBook 8560w
Lenovo
30A6003TUS
Microsoft Corporation
Surface Laptop
The preceding folder names should match the actual make and model values that MDT reads from devices
during deployment. You can find out the model values for your machines by using the following command in
Windows PowerShell:

Get-WmiObject -Class:Win32_ComputerSystem

Or, you can use this command in a normal command prompt:

wmic csproduct get name

If you want a more standardized naming convention, try the ModelAliasExit.vbs script from the Deployment
Guys blog post, entitled Using and Extending Model Aliases for Hardware Specific Application Installation.

The Out-of-Box Drivers structure in the Deployment Workbench.

Create the selection profiles for boot image drivers
By default, MDT adds any storage and network drivers that you import to the boot images. However, you should
add only the drivers that are necessary to the boot image. You can control which drivers are added by using
selection profiles. The drivers that are used for the boot images (Windows PE) are Windows 10 drivers. If you
can’t locate Windows 10 drivers for your device, a Windows 7 or Windows 8.1 driver will most likely work, but
Windows 10 drivers should be your first choice.
On MDT01 :
1. In the Deployment Workbench, under the MDT Production node, expand the Advanced
Configuration node, right-click the Selection Profiles node, and select New Selection Profile .
2. In the New Selection Profile Wizard, create a selection profile with the following settings:
a. Selection Profile name: WinPE x86
b. Folders: Select the WinPE x86 folder in Out-of-Box Drivers.
c. Select Next , Next and Finish .
3. Right-click the Selection Profiles node again, and select New Selection Profile .
4. In the New Selection Profile Wizard, create a selection profile with the following settings:
a. Selection Profile name: WinPE x64
b. Folders: Select the WinPE x64 folder in Out-of-Box Drivers.
c. Select Next , Next and Finish .
 Creating the WinPE x64 selection profile.
Extract and import drivers for the x64 boot image
Windows PE supports all the hardware models that we have, but here you learn to add boot image drivers to
accommodate any new hardware that might require more drivers. In this example, you add the latest Intel
network drivers to the x64 boot image.
On MDT01 :
1. Download PROWinx64.exe from Intel.com (ex: PROWinx64.exe).
2. Extract PROWinx64.exe to a temporary folder - in this example to the C:\Tmp\ProWinx64 folder. a. Note :
Extracting the .exe file manually requires an extraction utility. You can also run the .exe and it will self-extract
files to the %userprofile%\AppData\Local\Temp\RarSFX0 directory. This directory is temporary and will
be deleted when the .exe terminates.
3. Using File Explorer, create the D:\Drivers\WinPE x64\Intel PRO1000 folder.
4. Copy the content of the C:\Tmp\PROWinx64\PRO1000\Winx64\NDIS64 folder to the
D:\Drivers\WinPE x64\Intel PRO1000 folder.
5. In the Deployment Workbench, expand the MDT Production > Out-of-Box Drivers node, right-click the
WinPE x64 node, and select Impor t Drivers , and use the following Driver source directory to import
drivers: D:\Drivers\WinPE x64\Intel PRO1000 .
Download, extract, and import drivers
For the Lenovo ThinkStation P500
For the ThinkStation P500 model, you use the Lenovo ThinkVantage Update Retriever software to download the
drivers. With Update Retriever, you need to specify the correct Lenovo Machine Type for the actual hardware (the
first four characters of the model name). As an example, the Lenovo ThinkStation P500 model has the
30A6003TUS model name, meaning the Machine Type is 30A6.
To get the updates, download the drivers from the Lenovo ThinkVantage Update Retriever using its export
function. You can also download the drivers by searching PC Support on the Lenovo website.
In this example, we assume you've downloaded and extracted the drivers using ThinkVantage Update Retriever
to the D:\Drivers\Lenovo\ThinkStation P500 (30A6003TUS) directory.
On MDT01 :
1. In the Deployment Workbench, in the MDT Production > Out-Of-Box Drivers > Windows 10 x64
node, expand the Lenovo node.
2. Right-click the 30A6003TUS folder and select Impor t Drivers and use the following Driver source
directory to import drivers:
D:\Drivers\Windows 10 x64\Lenovo\ThinkStation P500 (30A6003TUS)
The folder you select and all subfolders will be checked for drivers, expanding any .cab files that are
present and searching for drivers.
For the Latitude E7450
For the Dell Latitude E7450 model, you use the Dell Driver CAB file, which is accessible via the Dell TechCenter
website.
In these steps, we assume you've downloaded and extracted the CAB file for the Latitude E7450 model to the
D:\Drivers\Dell Inc.\Latitude E7450 folder.
On MDT01 :
1. In the Deployment Workbench , in the MDT Production > Out-Of-Box Drivers > Windows 10 x64
node, expand the Dell Inc. node.
2. Right-click the Latitude E7450 folder and select Impor t Drivers and use the following Driver source
directory to import drivers:
D:\Drivers\Windows 10 x64\Dell Inc.\Latitude E7450
For the HP EliteBook 8560w
For the HP EliteBook 8560w, you use HP Image Assistant to get the drivers. The HP Image Assistant can be
accessed on the HP Support site.
In these steps, we assume you've downloaded and extracted the drivers for the HP EliteBook 8650w model to
the D:\Drivers\Windows 10 x64\Hewlett-Packard\HP EliteBook 8560w folder.
On MDT01 :
1. In the Deployment Workbench , in the MDT Production > Out-Of-Box Drivers > Windows 10 x64
node, expand the Hewlett-Packard node.
2. Right-click the HP EliteBook 8560w folder and select Impor t Drivers and use the following Driver
source directory to import drivers:
D:\Drivers\Windows 10 x64\Hewlett-Packard\HP EliteBook 8560w
For the Microsoft Surface Laptop
For the Microsoft Surface Laptop model, you find the drivers on the Microsoft website. In these steps, we
assume you've downloaded and extracted the Surface Laptop drivers to the D:\Drivers\Windows 10
x64\Microsoft\Surface Laptop folder.
On MDT01 :
1. In the Deployment Workbench, in the MDT Production > Out-Of-Box Drivers > Windows 10 x64
node, expand the Microsoft node.
2. Right-click the Surface Laptop folder and select Impor t Drivers ; and use the following Driver source
directory to import drivers:
D:\Drivers\Windows 10 x64\Microsoft\Surface Laptop

Step 6: Create the deployment task sequence

This section will show you how to create the task sequence used to deploy your production Windows 10
reference image. You'll then configure the task sequence to enable patching via a Windows Server Update
Services (WSUS) server.
Create a task sequence for Windows 10 Enterprise
On MDT01 :
1. In the Deployment Workbench, under the MDT Production node, right-click Task Sequences , and
create a folder named Windows 10 .
2. Right-click the new Windows 10 folder and select New Task Sequence . Use the following settings for
the New Task Sequence Wizard:
Task sequence ID: W10-X64-001
Task sequence name: Windows 10 Enterprise x64 RTM Custom Image
Task sequence comments: Production Image
Template: Standard Client Task Sequence
Select OS: Windows 10 Enterprise x64 RTM Custom Image
Specify Product Key: Don't specify a product key at this time
Full Name: Contoso
Organization: Contoso
Internet Explorer home page: https://www.contoso.com
Admin Password: Don't specify an Administrator Password at this time
Edit the Windows 10 task sequence
1. Continuing from the previous procedure, right-click the Windows 10 Enterprise x64 RTM Custom
Image task sequence, and select Proper ties .
2. On the Task Sequence tab, configure the Windows 10 Enterprise x64 RTM Custom Image task
sequence with the following settings:
a. Preinstall: After the Enable BitLocker (Offline) action, add a Set Task Sequence Variable
action with the following settings:
a. Name: Set DriverGroup001
b. Task Sequence Variable: DriverGroup001
c. Value: Windows 10 x64\%Make%\%Model%
b. Configure the Inject Drivers action with the following settings:
Choose a selection profile: Nothing
Install all drivers from the selection profile

NOTE
The configuration above indicates that MDT should only use drivers from the folder specified by the
DriverGroup001 property, which is defined by the "Choose a selection profile: Nothing" setting, and that
MDT shouldn't use plug and play to determine which drivers to copy, which is defined by the "Install all
drivers from the selection profile" setting.

c. State Restore. Enable the Windows Update (Pre-Application Installation) action.

d. State Restore. Enable the Windows Update (Post-Application Installation) action.
3. Select OK .

The task sequence for production deployment.

Step 7: Configure the MDT production deployment share
In this section, you'll learn how to configure the MDT Build Lab deployment share with the rules required to
create a dynamic deployment process. This configuration includes commonly used rules and an explanation of
how these rules work.
Configure the rules

NOTE
The following instructions assume the device is online. If you're offline you can remove SLShare variable.

On MDT01 :
1. Right-click the MDT Production deployment share and select Proper ties .
2. Select the Rules tab and replace the existing rules with the following information (modify the domain
name, WSUS server, and administrative credentials to match your environment):

[Settings]
Priority=Default

[Default]
_SMSTSORGNAME=Contoso
OSInstall=YES
UserDataLocation=AUTO
TimeZoneName=Pacific Standard Time
AdminPassword=pass@word1
JoinDomain=contoso.com
DomainAdmin=CONTOSO\MDT_JD
DomainAdminPassword=pass@word1
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
SLShare=\\MDT01\Logs$
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xml
HideShell=YES
ApplyGPOPack=NO
WSUSServer=mdt01.contoso.com:8530
SkipAppsOnUpgrade=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipDomainMembership=YES
SkipUserData=YES
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=NO
SkipBitLocker=YES
SkipSummary=YES
SkipCapture=YES
SkipFinalSummary=NO

3. Select Edit Bootstrap.ini and modify using the following information:

 [Settings]
Priority=Default

[Default]
DeployRoot=\\MDT01\MDTProduction$
UserDomain=CONTOSO
UserID=MDT_BA
UserPassword=pass@word1
SkipBDDWelcome=YES

4. On the Windows PE tab, in the Platform drop-down list, make sure x86 is selected.
5. On the General sub tab (still under the main Windows PE tab), configure the following settings:
In the Lite Touch Boot Image Settings area:
Image description: MDT Production x86
ISO file name: MDT Production x86.iso

NOTE
Because you're going to use Pre-Boot Execution Environment (PXE) later to deploy the machines, you don't need
the ISO file; however, we recommend creating ISO files because they're useful when troubleshooting deployments
and for quick tests.

6. On the Drivers and Patches sub tab, select the WinPE x86 selection profile and select the Include all
drivers from the selection profile option.
7. On the Windows PE tab, in the Platform drop-down list, select x64 .
8. On the General sub tab, configure the following settings:
In the Lite Touch Boot Image Settings area:
Image description: MDT Production x64
ISO file name: MDT Production x64.iso
9. In the Drivers and Patches sub tab, select the WinPE x64 selection profile and select the Include all
drivers from the selection profile option.
10. In the Monitoring tab, select the Enable monitoring for this deployment share check box.
11. Select OK .

NOTE
It will take a while for the Deployment Workbench to create the monitoring database and web service.
 The Windows PE tab for the x64 boot image.
The rules explained
The rules for the MDT Production deployment share are different from those rules for the MDT Build Lab
deployment share. The biggest differences are that you deploy the machines into a domain instead of a
workgroup.
You can optionally remove the UserID and UserPassword entries from Bootstrap.ini so that users performing
PXE boot are prompted to provide credentials with permission to connect to the deployment share. Setting
SkipBDDWelcome=NO enables the welcome screen that displays options to run the deployment wizard, run
DaRT tools (if installed), exit to a Windows PE command prompt, set the keyboard layout, or configure a static IP
address. In this example, we're skipping the welcome screen and providing credentials.
The Bootstrap.ini file
This file is the MDT Production Bootstrap.ini:

[Settings]
Priority=Default

[Default]
DeployRoot=\\MDT01\MDTProduction$
UserDomain=CONTOSO
UserID=MDT_BA
UserPassword=pass@word1
SkipBDDWelcome=YES

The CustomSettings.ini file

This file is the CustomSettings.ini file with the new join domain information:
 [Settings]
Priority=Default

[Default]
_SMSTSORGNAME=Contoso
OSInstall=Y
UserDataLocation=AUTO
TimeZoneName=Pacific Standard Time
AdminPassword=pass@word1
JoinDomain=contoso.com
DomainAdmin=CONTOSO\MDT_JD
DomainAdminPassword=pass@word1
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
SLShare=\\MDT01\Logs$
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xml
HideShell=YES
ApplyGPOPack=NO
WSUSServer=http://mdt01.contoso.com:8530
SkipAppsOnUpgrade=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipDomainMembership=YES
SkipUserData=YES
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=NO
SkipBitLocker=YES
SkipSummary=YES
SkipCapture=YES
SkipFinalSummary=NO
EventService=http://MDT01:9800

Some properties to use in the MDT Production rules file are as follows:
JoinDomain. The domain to join.
DomainAdmin. The account to use when joining the machine to the domain.
DomainAdminDomain. The domain for the join domain account.
DomainAdminPassword. The password for the join domain account.
MachineObjectOU. The organizational unit (OU) to which to add the computer account.
ScanStateArgs. Arguments for the User State Migration Tool (USMT) ScanState command.
USMTMigFiles(*). List of USMT templates (controlling what to back up and restore).
EventSer vice. Activates logging information to the MDT monitoring web service.

NOTE
For more information about localization support, see the following articles:
MDT sample guide
LCID (Locale ID) codes

Optional deployment share configuration

If your organization has a Microsoft Software Assurance agreement, you also can subscribe to another Microsoft
Desktop Optimization Package (MDOP) license (at an extra cost). Included in MDOP is Microsoft Diagnostics and
Recovery Toolkit (DaRT), which contains tools that can help you troubleshoot MDT deployments, and
troubleshoot Windows itself.
Add DaRT 10 to the boot images
If you've licensing for MDOP and DaRT, you can add DaRT to the boot images using the steps in this section. If
you don't have DaRT licensing, or don't want to use it, skip to the next section, Update the Deployment Share. To
enable the remote connection feature in MDT, you need to do the following steps:

NOTE
DaRT 10 is part of MDOP 2015.
MDOP might be available as a download from your Visual Studio subscription. When searching, be sure to look for
Desktop Optimization Pack .

On MDT01 :
1. Download MDOP 2015 and copy the DaRT 10 installer file to the D:\Setup\DaRT 10 folder on MDT01
(DaRT\DaRT 10\Installers\<lang>\x64\MSDaRT100.msi).
2. Install DaRT 10 (MSDaRT10.msi) using the default settings.

3. Copy the two tools CAB files from C:\Program Files\Microsoft DaRT\v10 (Toolsx86.cab and
Toolsx64.cab ) to the production deployment share at D:\MDTProduction\Tools\x86 and
D:\MDTProduction\Tools\x64 , respectively.
4. In the Deployment Workbench, right-click the MDT Production deployment share and select
Proper ties .
5. On the Windows PE tab, in the Platform drop-down list, make sure x86 is selected.
6. On the Features sub tab, select the Microsoft Diagnostics and Recover y Toolkit (DaRT) checkbox.
 Selecting the DaRT 10 feature in the deployment share.
7. In the Windows PE tab, in the Platform drop-down list, select x64 .
8. In the Features sub tab, in addition to the default selected feature pack, select the Microsoft
Diagnostics and Recover y Toolkit (DaRT) check box.
9. Select OK .
Update the deployment share
Like the MDT Build Lab deployment share, the MDT Production deployment share needs to be updated after it
has been configured. This update-process is the one during which the Windows PE boot images are created.
1. Right-click the MDT Production deployment share and select Update Deployment Share .
2. Use the default options for the Update Deployment Share Wizard.

NOTE
The update process will take 5 to 10 minutes.

Step 8: Deploy the Windows 10 client image

These steps will walk you through the process of using task sequences to deploy Windows 10 images through a
fully automated process. First, you need to add the boot image to Windows Deployment Services (WDS) and
then start the deployment. In contrast with deploying images from the MDT Build Lab deployment share, we
recommend using the Pre-Installation Execution Environment (PXE) to start the full deployments in the
datacenter, even though you technically can use an ISO/CD or USB to start the process.
Configure Windows Deployment Services
You need to add the MDT Production Lite Touch x64 Boot image to WDS in preparation for the deployment. In
this procedure, we assume that WDS is already installed and initialized on MDT01 as described in the Prepare
for Windows deployment article.
On MDT01 :
1. Open the Windows Deployment Services console, expand the Ser vers node and then expand
MDT01.contoso.com .
2. Right-click Boot Images and select Add Boot Image .
3. Browse to the D:\MDTProduction\Boot\LiteTouchPE_x64.wim file and add the image with the
default settings.

The boot image added to the WDS console.

Deploy the Windows 10 client
At this point, you should have a solution ready for deploying the Windows 10 client. We recommend starting by
trying a few deployments at a time until you're confident that your configuration works as expected. We find it
useful to try some initial tests on virtual machines before testing on physical hardware. These tests help rule out
hardware issues when testing or troubleshooting. Here are the steps to deploy your Windows 10 image to a
virtual machine:
On HV01 :
1. Create a virtual machine with the following settings:
Name: PC0005
Store the virtual machine in a different location: C:\VM
Generation: 2
Memory: 2048 MB
Network: Must be able to connect to \MDT01\MDTProduction$
Hard disk: 60 GB (dynamic disk)
Installation Options: Install an operating system from a network-based installation server
2. Start the PC0005 virtual machine, and press Enter to start the PXE boot. The VM will now load the
Windows PE boot image from the WDS server.
 The initial PXE boot process of PC0005.
3. After Windows PE has booted, complete the Windows Deployment Wizard using the following setting:
Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Custom Image
Computer Name: PC0005
Applications: Select the Install - Adobe Reader checkbox.
4. Setup now begins and does the following steps:
Installs the Windows 10 Enterprise operating system.
Installs the added application.
Updates the operating system via your local Windows Server Update Services (WSUS) server.
Application installation
Following OS installation, Microsoft Office 365 Pro Plus - x64 is installed automatically.

Use the MDT monitoring feature

Since you've enabled the monitoring on the MDT Production deployment share, you can follow your
deployment of PC0005 via the monitoring node.
On MDT01 :
1. In the Deployment Workbench, expand the MDT Production deployment share folder.
2. Select the Monitoring node, and wait until you see PC0005.
3. Double-click PC0005, and review the information.

The Monitoring node, showing the deployment progress of PC0005.

Use information in the Event Viewer
When monitoring is enabled, MDT also writes information to the event viewer on MDT01. This information can
be used to trigger notifications via scheduled tasks when deployment is completed. For example, you can
configure scheduled tasks to send an email when a certain event is created in the event log.

The Event Viewer showing a successful deployment of PC0005.

Multicast deployments
Multicast deployment allows for image deployment with reduced network load during simultaneous
deployments. Multicast is a useful operating system deployment feature in MDT deployments, however it's
important to ensure that your network supports it and is designed for it. If you've a limited number of
simultaneous deployments, you probably don't need to enable multicast.
Requirements
Multicast requires that Windows Deployment Services (WDS) is running on Windows Server 2008 or later. In
addition to the core MDT setup for multicast, the network needs to be configured to support multicast. In
general, this configuration means involvement of the organization networking team to ensure that Internet
Group Management Protocol (IGMP) snooping is turned on and that the network is designed for multicast
traffic. The multicast solution uses IGMPv3.
Set up MDT for multicast
Setting up MDT for multicast is straightforward. You enable multicast on the deployment share, and MDT takes
care of the rest.
On MDT01 :
1. In the Deployment Workbench, right-click the MDT Production deployment share folder and select
Proper ties .
2. On the General tab, select the Enable multicast for this deployment share (requires Windows
Ser ver 2008 R2 Windows Deployment Ser vices) check box, and select OK .
3. Right-click the MDT Production deployment share folder and select Update Deployment Share .
4. After updating the deployment share, use the Windows Deployment Services console to, verify that the
multicast namespace was created.

The newly created multicast namespace.

Use offline media to deploy Windows 10

In addition to network-based deployments, MDT supports the use of offline media-based deployments of
Windows 10. You can easily generate an offline version of your deployment share - either the full deployment
share or a subset of it - by using selection profiles. The generated offline media can be burned to a DVD or
copied to a USB stick for deployment.
Offline media are useful not only when you don't have network connectivity to the deployment share, but also
when you've limited connection to the deployment share and don't want to copy 5 GB of data over the wire.
Offline media can still join the domain, but you save the transfer of operating system images, drivers, and
applications over the wire.
Create the offline media selection profile
To filter what is being added to the media, you create a selection profile. When creating selection profiles, you
quickly realize the benefits of having created a good logical folder structure in the Deployment Workbench.
On MDT01 :
1. In the Deployment Workbench, under the MDT Production / Advanced Configuration node, right-
click Selection Profiles , and select New Selection Profile .
2. Use the following settings for the New Selection Profile Wizard:
 General Settings
Selection profile name: Windows 10 Offline Media
Folders
Applications / Adobe
Operating Systems / Windows 10
Out-Of-Box Drivers / WinPE x64
Out-Of-Box Drivers / Windows 10 x64
Task Sequences / Windows 10

Create the offline media

In these steps, you generate offline media from the MDT Production deployment share. To filter what is being
added to the media, you use the previously created selection profile.
1. On MDT01, using File Explorer, create the D:\MDTOfflineMedia folder.

NOTE
When creating offline media, you need to create the target folder first. It's crucial that you don't create a subfolder
inside the deployment share folder because it will break the offline media.

2. In the Deployment Workbench, under the MDT Production / Advanced Configuration node, right-
click the Media node, and select New Media .
3. Use the following settings for the New Media Wizard:
General Settings
Media path: D:\MDTOfflineMedia
Selection profile: Windows 10 Offline Media
Configure the offline media
Offline media has its own rules, its own Bootstrap.ini and CustomSettings.ini files. These files are stored in the
Control folder of the offline media; they also can be accessed via properties of the offline media in the
Deployment Workbench.
On MDT01 :
1. Copy the CustomSettings.ini file from the D:\MDTProduction\Control folder to
D:\MDTOfflineMedia\Content\Deploy\Control . Overwrite the existing files.
2. In the Deployment Workbench, under the MDT Production / Advanced Configuration / Media
node, right-click the MEDIA001 media, and select Proper ties .
3. In the General tab, configure the following:
Clear the Generate x86 boot image check box.
ISO file name: Windows 10 Offline Media.iso
4. On the Windows PE tab, in the Platform drop-down list, select x64 .
5. On the General sub tab, configure the following settings:
In the Lite Touch Boot Image Settings area:
Image description: MDT Production x64
In the Windows PE Customizations area, set the Scratch space size to 128.
6. On the Drivers and Patches sub tab, select the WinPE x64 selection profile and select the Include all
drivers from the selection profile option.
7. Select OK .
Generate the offline media
You've now configured the offline media deployment share, however the share hasn't yet been populated with
the files required for deployment. Now everything is ready you populate the deployment share content folder
and generate the offline media ISO.
On MDT01 :
1. In the Deployment Workbench, navigate to the MDT Production / Advanced Configuration / Media
node.
2. Right-click the MEDIA001 media, and select Update Media Content . The Update Media Content
process now generates the offline media in the D:\MDTOfflineMedia\Content folder. The process
might require several minutes.
Create a bootable USB stick
The ISO that you got when updating the offline media item can be burned to a DVD and used directly (it will be
bootable), but it's often more efficient to use USB sticks instead since they're faster and can hold more data. (A
dual-layer DVD is limited to 8.5 GB.)
 TIP
In this example, the .wim file is 5.5 GB in size. However, bootable USB sticks are formatted with the FAT32 file system
which limits file size to 4.0 GB. You can place the image on a different drive (ex: E:\Deploy\Operating
Systems\W10EX64RTM\REFW10X64-001.swm) and then modify E:\Deploy\Control\OperatingSystems.xml to point to it.
Alternatively to keep using the USB you must split the .wim file, which can be done using DISM:

Dism /Split-Image /ImageFile:D:\MDTOfflinemedia\Content\Deploy\Operating Systems\W10EX64RTM\REFW10X64-

001.wim /SWMFile:E:\sources\install.swm /FileSize:3800.

Windows Setup automatically installs from this file, provided you name it install.swm. The file names for the next files
include numbers, for example: install2.swm, install3.swm.

To enable split image in MDT, the Settings.xml file in your deployment share (ex: D:\MDTProduction\Control\Settings.xml)
must have the SkipWimSplit value set to False . By default this value is set to True (
<SkipWimSplit>True</SkipWimSplit> ), so this must be changed and the offline media content updated.

Follow these steps to create a bootable USB stick from the offline media content:
1. On a physical machine running Windows 7 or later, insert the USB stick you want to use.
2. Copy the content of the MDTOfflineMedia\Content folder to the root of the USB stick.
3. Start an elevated command prompt (run as Administrator), and start the Diskpart utility by typing
Diskpar t and pressing Enter .
4. In the Diskpart utility, you can type list volume (or the shorter list vol ) to list the volumes, but you only
need to remember the drive letter of the USB stick to which you copied the content. In our example, the
USB stick had the drive letter F.
5. In the Diskpart utility, type select volume F (replace F with your USB stick drive letter).
6. In the Diskpart utility, type active , and then type exit .

Unified Extensible Firmware Interface (UEFI)-based deployments

As referenced in Windows 10 deployment scenarios and tools, Unified Extensible Firmware Interface (UEFI)-
based deployments are becoming more common. In fact, when you create a generation 2 virtual machine in
Hyper-V, you get a UEFI-based computer. During deployment, MDT automatically detects that you've an UEFI-
based machine and creates the partitions UEFI requires. You don't need to update or change your task
sequences in any way to accommodate UEFI.
The partitions when deploying an UEFI-based machine.

Related articles
Get started with the Microsoft Deployment Toolkit (MDT)
Create a Windows 10 reference image
Build a distributed environment for Windows 10 deployment
Refresh a Windows 7 computer with Windows 10
Replace a Windows 7 computer with a Windows 10 computer
Configure MDT settings
 Build a distributed environment for Windows 10
deployment
11/23/2022 • 9 minutes to read • Edit Online

Applies to
Windows 10
Perform the steps in this article to build a distributed environment for Windows 10 deployment. A distributed
environment for deployment is useful when you have a segmented network, for example one that is segmented
geographically into two branch locations. If you work in a distributed environment, replicating the deployment
shares is an important part of a deployment solution because images of 5 GB or more in size can present
bandwidth issues when deployed over the wire. Replicating this content enables clients to do local deployments.
Four computers are used in this article: DC01, MDT01, MDT02, and PC0006. DC01 is a domain controller, MDT01
and MDT02 are domain member computers running Windows Server 2019, and PC0006 is a blank device
where we'll deploy Windows 10. The second deployment server (MDT02) will be configured for a remote site
(Stockholm) by replicating the deployment share on MDT01 at the original site (New York). All devices are
members of the domain contoso.com for the fictitious Contoso Corporation.
For the purposes of this article, we assume that MDT02 is prepared with the same network and storage
capabilities that were specified for MDT01, except that MDT02 is located on a different subnet than MDT01. For
more information on the infrastructure setup for this article, see Prepare for deployment with MDT.

Computers used in this article.

HV01 is also used in this topic to host the PC0006 virtual machine.

Replicate deployment shares

Replicating the content between MDT01 (New York) and MDT02 (Stockholm) can be done in different ways. The
most common content replication solutions with Microsoft Deployment Toolkit (MDT) use either the Linked
Deployment Shares (LDS) feature or Distributed File System Replication (DFS-R). Some organizations have used
a simple robocopy script for replication of the content.

NOTE
Robocopy has options that allow for synchronization between folders. It has a simple reporting function; it supports
transmission retry; and, by default, it will only copy/remove files from the source that are newer than files on the target.

Linked deployment shares in MDT

LDS is a built-in feature in MDT for replicating content. However, LDS works best with strong connections such
as LAN connections with low latency. For most WAN links, DFS-R is the better option.
Why DFS -R is a better option
DFS-R isn't only fast and reliable, but it also offers central monitoring, bandwidth control, and a great delta
replication engine. DFS-R will work equally well whether you have 2 sites or 90. When using DFS-R for MDT, we
recommend running your deployment servers on Windows Server 2008 R2 or higher. From that version on,
you can configure the replication targets as read-only, which is exactly what you want for MDT. This way, you can
have your main deployment share centralized and replicate out changes as they happen. DFS-R will quickly pick
up changes at the central deployment share in MDT01 and replicate the delta changes to MDT02.

Set up Distributed File System Replication (DFS-R) for replication

Setting up DFS-R for replication is a quick and straightforward process: Prepare the deployment servers, create
a replication group, then configure some replication settings.
Prepare MDT01 for replication
On MDT01 :
1. Install the DFS Replication role on MDT01 by entering the following at an elevated Windows PowerShell
prompt:

Install-WindowsFeature -Name FS-DFS-Replication -IncludeManagementTools

2. Wait for installation to complete, and then verify that the installation was successful. See the following
output:

PS C:\> Install-WindowsFeature -Name FS-DFS-Replication -IncludeManagementTools

Success Restart Needed Exit Code Feature Result

------- -------------- --------- --------------
True No Success {DFS Replication, DFS Management Tools, Fi...

Prepare MDT02 for replication

On MDT02 :
1. Perform the same procedure on MDT02 by entering the following at an elevated Windows PowerShell
prompt:

Install-WindowsFeature -Name FS-DFS-Replication -IncludeManagementTools

2. Wait for installation to complete, and then verify that the installation was successful. See the following
output:

PS C:\> Install-WindowsFeature -Name FS-DFS-Replication -IncludeManagementTools

Success Restart Needed Exit Code Feature Result

------- -------------- --------- --------------
True No Success {DFS Replication, DFS Management Tools, Fi...

Create the MDTProduction folder on MDT02

On MDT02 :
1. Create and share the D:\MDTProduction folder using default permissions by entering the following at an
elevated command prompt:

mkdir d:\MDTProduction
New-SmbShare -Name "MDTProduction$" -Path "D:\MDTProduction"
2. You should see the following output:

C:\> New-SmbShare -Name "MDTProduction$" -Path "D:\MDTProduction"

Name ScopeName Path Description

---- --------- ---- -----------
MDTProduction$ * D:\MDTProduction

Configure the deployment share

When you have multiple deployment servers sharing the same content, you need to configure the Bootstrap.ini
file with information about which server to connect to based on where the client is located. In MDT that can be
done by using the DefaultGateway property.
On MDT01 :
1. Using Notepad, navigate to the D:\MDTProduction\Control folder and modify the Boostrap.ini file as
follows. Under [DefaultGateway] enter the IP addresses for the client's default gateway in New York and
Stockholm, respectively (replace 10.10.10.1 and 10.10.20.1 with your default gateways). The default
gateway setting is what tells the client which deployment share (that is, server) to use.

[Settings]
Priority=DefaultGateway, Default

[DefaultGateway]
10.10.10.1=NewYork
10.10.20.1=Stockholm

[NewYork]
DeployRoot=\\MDT01\MDTProduction$

[Stockholm]
DeployRoot=\\MDT02\MDTProduction$

[Default]
UserDomain=CONTOSO
UserID=MDT_BA
UserPassword=pass@word1
SkipBDDWelcome=YES

NOTE
The DeployRoot value needs to go into the Bootstrap.ini file, but you can use the same logic in the
CustomSettings.ini file. For example, you can redirect the logs to the local deployment server (SLSHARE), or have
the User State Migration Tool (USMT) migration store (UDDIR) local. To learn more about USMT, see Refresh a
Windows 7 computer with Windows 10 and Replace a Windows 7 computer with a Windows 10 computer.

2. Save the Bootstrap.ini file.

3. Using the Deployment Workbench, right-click the MDT Production deployment share and select
Update Deployment Share . Use the default settings for the Update Deployment Share Wizard. This
process will take a few minutes.
4. After the update is complete, use the Windows Deployment Services console on MDT01. In the Boot
Images node, right-click the MDT Production x64 boot image and select Replace Image .
5. Browse and select the D:\MDTProduction\Boot\LiteTouchPE_x64.wim boot image, and then
complete Replace Boot Image Wizard using the default settings.
 Replacing the updated boot image in WDS.

TIP
If you modify bootstrap.ini again later, be sure to repeat the process of updating the deployment share in the
Deployment Workbench and replacing the boot image in the WDS console.

Replicate the content

Once the MDT01 and MDT02 servers are prepared, you're ready to configure the actual replication.
Create the replication group
6. On MDT01, using DFS Management (dfsmgmt.msc), right-click Replication , and select New
Replication Group .
7. On the Replication Group Type page, select Multipurpose replication group , and select Next .
8. On the Name and Domain page, assign the MDTProduction name, and select Next .
9. On the Replication Group Members page, select Add , add MDT01 and MDT02 , and then select Next .
 Adding the Replication Group Members.
10. On the Topology Selection page, select the Full mesh option and select Next .
11. On the Replication Group Schedule and Bandwidth page, accept the default settings and select
Next .
12. On the Primar y Member page, select MDT01 and select Next .
13. On the Folders to Replicate page, select Add , enter D:\MDTProduction as the folder to replicate,
select OK , and then select Next .
14. On the Local Path of MDTProduction on the Other Members page, select MDT02 , and select Edit .
15. On the Edit page, select the Enabled option, type in D:\MDTProduction as the local path of folder,
select the Make the selected replicated folder on this member read-only check box, select OK ,
and then select Next .
16. On the Review Settings and Create Replication Group page, select Create .
17. On the Confirmation page, select Close .
Configure replicated folders
18. On MDT01 , using DFS Management, expand Replication and then select MDTProduction .
19. In the middle pane, right-click the MDT01 member and select Proper ties .
20. On the MDT01 (MDTProduction) Proper ties page, configure the following and then select OK :
a. In the Staging tab, set the quota to 20480 MB .
b. In the Advanced tab, set the quota to 8192 MB . In this scenario the size of the deployment share
is known, but you might need to change the values for your environment. A good rule of thumb is
to get the size of the 16 largest files and make sure they fit in the staging area. Below is a Windows
PowerShell example that calculates the size of the 16 largest files in the D:\MDTProduction
deployment share:
 (Get-ChildItem D:\MDTProduction -Recurse | Sort-Object Length -Descending | Select-Object -
First 16 | Measure-Object -Property Length -Sum).Sum /1GB

21. In the middle pane, right-click the MDT02 member and select Proper ties .
22. On the MDT02 (MDTProduction) Proper ties page, configure the following and then select OK :
a. In the Staging tab, set the quota to 20480 MB .
b. In the Advanced tab, set the quota to 8192 MB .

NOTE
It will take some time for the replication configuration to be picked up by the replication members (MDT01 and
MDT02). The time for the initial sync will depend on the WAN link speed between the sites. After that, delta
changes are replicated quickly.

23. Verify that MDT01 and MDT02 are members of the MDTProduction replication group, with MDT01 being
primary as follows using an elevated command prompt:

C:\> dfsradmin membership list /rgname:MDTProduction /attr:MemName,IsPrimary

MemName IsPrimary
MDT01 Yes
MDT02 No

Verify replication
On MDT02 :
1. Wait until you start to see content appear in the D:\MDTProduction folder.
2. Using DFS Management, expand Replication , right-click MDTProduction , and select Create Diagnostics
Repor t .
3. In the Diagnostics Report Wizard, on the Type of Diagnostics Repor t or Test page, choose Health
repor t and select Next .
4. On the Path and Name page, accept the default settings and select Next .
5. On the Members to Include page, accept the default settings and select Next .
6. On the Options page, accept the default settings and select Next .
7. On the Review Settings and Create Repor t page, select Create .
8. Open the report in Internet Explorer, and if necessary, select the Allow blocked content option.
The DFS Replication Health Report.

If there are replication errors you can review the DFS event log in Event Viewer under Applications and
Ser vices Logs .

Configure Windows Deployment Services (WDS) in a remote site

Like you did in the previous article for MDT01, you need to add the MDT Production Lite Touch x64 Boot image
to Windows Deployment Services on MDT02. For the following steps, we assume that WDS has already been
installed on MDT02.
1. On MDT02, using the WDS console, right-click Boot Images and select Add Boot Image .
2. Browse to the D:\MDTProduction\Boot\LiteTouchPE_x64.wim file and add the image with the default
settings.

Deploy a Windows 10 client to the remote site

Now you should have a solution ready for deploying the Windows 10 client to the remote site: Stockholm, using
the MDTProduction deployment share replica on MDT02. You can test this deployment with the following
optional procedure.

For demonstration purposes, the following procedure uses a virtual machine (PC0006) hosted by the Hyper-
V server HV01. To use the remote site server (MDT02) the VM must be assigned a default gateway that
matches the one you entered in the Boostrap.ini file.

1. Create a virtual machine with the following settings:

a. Name: PC0006
b. Location: C:\VMs
c. Generation: 2
d. Memory: 2048 MB
 e. Hard disk: 60 GB (dynamic disk)
f. Install an operating system from a network-based installation server
2. Start the PC0006 virtual machine, and press Enter to start the Pre-Boot Execution Environment (PXE) boot.
The VM will now load the Windows PE boot image from the WDS server.
3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows Deployment
Wizard using the following settings:
a. Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Custom Image
b. Computer Name: PC0006
c. Applications: Select the Install - Adobe Reader
4. Setup will now start and perform the following steps:
a. Install the Windows 10 Enterprise operating system.
b. Install applications.
c. Update the operating system using your local Windows Server Update Services (WSUS) server.

Related articles
Get started with the Microsoft Deployment Toolkit (MDT)
Create a Windows 10 reference image
Deploy a Windows 10 image using MDT
Refresh a Windows 7 computer with Windows 10
Replace a Windows 7 computer with a Windows 10 computer
Configure MDT settings
 Refresh a Windows 7 computer with Windows 10
11/23/2022 • 5 minutes to read • Edit Online

Applies to
Windows 10
This article will show you how to use MDT Lite Touch Installation (LTI) to upgrade a Windows 7 computer to a
Windows 10 computer using the online computer refresh process. The computer refresh scenario is a
reinstallation of an updated operating system on the same computer. You can also use this procedure to reinstall
the same OS version. In this article, the computer refresh will be done while the computer is online. MDT also
supports an offline computer refresh. For more info on that scenario, see the USMTOfflineMigration property on
the MDT resource page.
For the purposes of this article, we'll use three computers: DC01, MDT01, and PC0001.
DC01 is a domain controller for the contoso.com domain.
MDT01 is domain member server that hosts your deployment share.
PC0001 is a domain member computer running a previous version of Windows that is going to be refreshed
to a new version of Windows 10, with data and settings restored. The example used here is a computer
running Windows 7 SP1.
Both DC01 and MDT01 are running Windows Server 2019; however any supported version of Windows Server
can be used. For more information on the setup for this article, see Prepare for deployment with MDT.

The computers used in this article.

The computer refresh process

A computer refresh isn't the same as an in-place upgrade because a computer refresh involves exporting user
data and settings then wiping the device before installing a fresh OS and restoring the user's data and settings.
For a computer refresh with MDT, you use the User State Migration Tool (USMT), which is part of the Windows
Assessment and Deployment Kit (ADK) for Windows 10, to migrate user data and settings. To complete a
computer refresh, you will:
1. Back up data and settings locally, in a backup folder.
2. Wipe the partition, except for the backup folder.
3. Apply the new operating system image.
4. Install other applications.
5. Restore data and settings.
During the computer refresh, USMT uses a feature called Hard-Link Migration Store. When you use this feature,
the files are linked in the file system, which allows for fast migration, even when there's many files.
 NOTE
In addition to the USMT backup, you can enable an optional full Windows Imaging (WIM) backup of the machine by
configuring the MDT rules. If you do this, a .wim file is created in addition to the USMT backup. The .wim file contains the
entire volume from the computer and helpdesk personnel can extract content from it if needed. Please note that this is a
data WIM backup only. Using this backup to restore the entire computer is not a supported scenario.

Multi-user migration
By default, ScanState in USMT backs up all profiles on the machine, including local computer profiles. If you have
a computer that has been in your environment for a while, it likely has several domain-based profiles on it,
including those of former users. You can limit which profiles are backed up by configuring command-line
switches to ScanState (added as rules in MDT).
For example, the following line configures USMT to migrate only domain user profiles and not profiles from the
local SAM account database: ScanStateArgs=/ue:*\* /ui:CONTOSO\*

NOTE
You also can combine the preceding switches with the /uel switch, which excludes profiles that have not been accessed
within a specific number of days. For example, adding /uel:60 will configure ScanState (or LoadState) not to include profiles
that haven't been accessed for more than 60 days.

Support for additional settings

In addition to the command-line switches that control which profiles to migrate, XML templates control exactly
what data is being migrated. You can control data within and outside the user profiles.
Multicast
Multicast is a technology designed to optimize simultaneous deployment to multiple devices. If you have a
limited number of simultaneous deployments, you should disable multicast which was configured in a previous
procedure in this guide. Disabling multicast will speed up deployment there are only a few computers. You'll
need to update the deployment share after changing this setting.

Refresh a Windows 7 SP1 client

In this section, we assume that you've already performed the prerequisite procedures in the following articles,
so that you have a deployment share named MDTProduction$ on MDT01:
Prepare for deployment with MDT
Create a Windows 10 reference image
Deploy a Windows 10 image using MDT
It's also assumed that you have a domain member client computer named PC0001 in your environment running
Windows 7, 8.1 or 10 that is ready for a refresh to the latest version of Windows 10. For demonstration
purposes, we'll be refreshing a Windows 7 SP1 PC to Windows 10, version 1909.
Upgrade (refresh) a Windows 7 SP1 client
 IMPORTANT
Domain join details specified in the deployment share rules will be used to rejoin the computer to the domain during the
refresh process. If the Windows 7 client is domain-jonied in a different OU than the one specified by MachineObjectOU,
the domain join process will initially fail and then retry without specifying an OU. If the domain account that is specified
(ex: MDT_JD ) has permissions limited to a specific OU then the domain join will ultimately fail, the refresh process will
proceed, and the client computer object will be orphaned in Active Directory. In the current guide, computer objects
should be located in Contoso > Computers > Workstations. Use the Active Directory Users and Computers console to
review the location of computer objects and move them if needed. To diagnose MDT domain join errors, see
ZTIDomainJoin.log in the C:\Windows\Temp\DeploymentLogs directory on the client computer.

1. On PC0001, sign in as contoso\Administrator and start the Lite Touch Deploy Wizard by opening
\\MDT01\MDTProduction$\Scripts\Litetouch.vbs .
2. Complete the deployment guide using the following settings:
Select a task sequence to execute on this computer: Windows 10 Enterprise x64 RTM Custom
Image
Computer name: <default>
Specify where to save a complete computer backup: Don't back up the existing computer

NOTE
Skip this optional full WIM backup that we are choosing not to perform. The USMT backup will still run.

Select one or more applications to install: Install - Adobe Reader

3. Setup starts and performs the following actions:

Backs up user settings and data using USMT.
Installs the Windows 10 Enterprise x64 operating system.
 Installs any added applications.
Updates the operating system using your local Windows Server Update Services (WSUS) server.
Restores user settings and data using USMT.
4. You can monitor progress of the deployment using the deployment workbench on MDT01. See the
following example:

5. After the refresh process completes, sign in to the Windows 10 computer and verify that user accounts,
data and settings were migrated.

Related articles
Get started with the Microsoft Deployment Toolkit (MDT)
Prepare for deployment with MDT
Create a Windows 10 reference image
Deploy a Windows 10 image using MDT
Build a distributed environment for Windows 10 deployment
Replace a Windows 7 computer with a Windows 10 computer
Configure MDT settings
 Replace a Windows 7 computer with a Windows 10
computer
11/23/2022 • 4 minutes to read • Edit Online

Applies to
Windows 10
A computer replace scenario for Windows 10 is similar to a computer refresh for Windows 10. However,
because you're replacing a device, you can't store the backup on the old computer. Instead you need to store the
backup to a location where the new computer can read it. The User State Migration Tool (USMT) will be used to
back up and restore data and settings.
For the purposes of this article, we'll use four computers: DC01, MDT01, PC0002, and PC0007.
DC01 is a domain controller for the contoso.com domain.
MDT01 is domain member server that hosts your deployment share.
PC0002 is an old computer running Windows 7 SP1 that will be replaced by PC0007.
PC0007 is a new computer will have the Windows 10 OS installed prior to data from PC0002 being
migrated. Both PC0002 and PC0007 are members of the contoso.com domain.
For more details on the setup for this article, see Prepare for deployment with MDT.

The computers used in this article.

HV01 is also used in this topic to host the PC0007 virtual machine for demonstration purposes, however
typically PC0007 is a physical computer.

Prepare for the computer replace

To prepare for the computer replace, you need to create a folder in which to store the backup and a backup only
task sequence to run on the old computer.
Configure the rules on the Microsoft Deployment Toolkit (MDT ) Production share
On MDT01 :
1. Open the Deployment Workbench, under Deployment Shares right-click MDT Production , select
Proper ties , and then select the Rules tab.
2. Change the SkipUserData=YES option to NO , and select OK .
3. Right-click on MDT Production and select Update Deployment Share . Then select Next , Next , and
Finish to complete the Update Deployment Share Wizard with the default settings.
Create and share the MigData folder
On MDT01 :
1. Create and share the D:\MigData folder by running the following three commands in an elevated
Windows PowerShell prompt:
 New-Item -Path D:\MigData -ItemType directory
New-SmbShare -Name MigData$ -Path D:\MigData -ChangeAccess EVERYONE
icacls D:\MigData /grant '"MDT_BA":(OI)(CI)(M)'

Create a backup only (replace ) task sequence

2. In Deployment Workbench, under the MDT Production deployment share, select the Task Sequences
node and create a new folder named Other .
3. Right-click the Other folder and select New Task Sequence . Use the following settings for the New Task
Sequence Wizard:
Task sequence ID: REPLACE-001
Task sequence name: Backup Only Task Sequence
Task sequence comments: Run USMT to back up user data and settings
Template: Standard Client Replace Task Sequence
4. In the Other folder, double-click Backup Only Task Sequence , and then in the Task Sequence tab,
review the sequence. Notice that it only contains a subset of the normal client task sequence actions.

The Backup Only Task Sequence action list.

Perform the computer replace

During a computer replace, the following are the high-level steps that occur:
1. On the computer you're replacing, a special replace task sequence runs the USMT backup and, if you
configured it, runs the optional full Windows Imaging (WIM) backup.
2. On the new computer, you perform a standard bare-metal deployment. At the end of the bare-metal
deployment, the USMT backup from the old computer is restored.
Run the replace task sequence
On PC0002 :
1. Sign in as CONTOSO\Administrator and verify that you have write access to the \\MDT01\MigData$
share.
2. Run \\MDT01\MDTProduction$\Scripts\LiteTouch.vbs .
3. Complete the Windows Deployment Wizard using the following settings:
a. Select a task sequence to execute on this computer: Backup Only Task Sequence
Specify where to save your data and settings: Specify a location
Location: \\MDT01\MigData$\PC0002

NOTE
If you are replacing the computer at a remote site you should create the MigData folder on MDT02 and
use that share instead.

b. Specify where to save a complete computer backup: Don't back up the existing computer
The task sequence will now run USMT (Scanstate.exe) to capture user data and settings of the computer.

The new task sequence running the Capture User State action on PC0002.
4. On MDT01 , verify that you have a USMT.MIG compressed backup file in the
D:\MigData\PC0002\USMT folder.
 The USMT backup of PC0002.
Deploy the replacement computer
To demonstrate deployment of the replacement computer, HV01 is used to host a virtual machine: PC0007.
On HV01 :
1. Create a virtual machine with the following settings:
Name: PC0007
Location: C:\VMs
Generation: 2
Memory: 2048 MB
Hard disk: 60 GB (dynamic disk)
Install an operating system from a network-based installation server
2. Start the PC0007 virtual machine, and press Enter to start the Pre-Boot Execution Environment (PXE)
boot. The VM will now load the Windows PE boot image from MDT01 (or MDT02 if at a remote site).

The initial PXE boot process of PC0007.

3. After Windows Preinstallation Environment (Windows PE) has booted, complete the Windows
Deployment Wizard using the following settings:
Select a task sequence to execute on this computer:
Windows 10 Enterprise x64 RTM Custom Image
Computer Name: PC0007
Move Data and Settings: Don't move user data and settings.
User Data (Restore) > Specify a location: \\MDT01\MigData$\PC0002
Applications: Adobe > Install - Adobe Reader
4. Setup now starts and does the following actions:
Partitions and formats the disk.
Installs the Windows 10 Enterprise operating system.
Installs the application.
Updates the operating system via your local Windows Server Update Services (WSUS) server.
Restores the USMT backup from PC0002.
You can view progress of the process by clicking the Monitoring node in the Deployment Workbench on MDT01.

Related articles
Get started with the Microsoft Deployment Toolkit (MDT)
Create a Windows 10 reference image
Deploy a Windows 10 image using MDT
Build a distributed environment for Windows 10 deployment
Refresh a Windows 7 computer with Windows 10
Configure MDT settings
 Perform an in-place upgrade to Windows 10 with
MDT
11/23/2022 • 3 minutes to read • Edit Online

Applies to
Windows 10
The simplest path to upgrade PCs that are currently running Windows 7, Windows 8, or Windows 8.1 to
Windows 10 is through an in-place upgrade.

TIP
In-place upgrade is the preferred method to use when migrating from Windows 10 to a later release of Windows 10, and
is also a preferred method for upgrading from Windows 7 or 8.1 if you do not plan to significantly change the device's
configuration or applications. MDT includes an in-place upgrade task sequence template that makes the process really
simple.

In-place upgrade differs from computer refresh in that you can't use a custom image to perform the in-place
upgrade. In this article, we'll add a default Windows 10 image to the production deployment share specifically to
perform an in-place upgrade.
Three computers are used in this article: DC01, MDT01, and PC0002.
DC01 is a domain controller for the contoso.com domain
MDT01 is a domain member server
PC0002 is a domain member computer running Windows 7 SP1, targeted for the Windows 10 upgrade

The computers used in this article.

NOTE
For details about the setup for the procedures in this article, please see Prepare for deployment with MDT.

If you have already completed all the steps in Deploy a Windows 10 image using MDT, then you already
have a production deployment share and you can skip to Add Windows 10 Enterprise x64 (full source).

Create the MDT production deployment share

On MDT01 :
1. Ensure you're signed on as: contoso\administrator.
2. In the Deployment Workbench console, right-click Deployment Shares and select New Deployment
Share .
3. On the Path page, in the Deployment share path text box, type D:\MDTProduction and select Next .
4. On the Share page, in the Share name text box, type MDTProduction$ and select Next .
5. On the Descriptive Name page, in the Deployment share description text box, type MDT Production
and select Next .
6. On the Options page, accept the default settings and select Next twice, and then select Finish .
7. Using File Explorer, verify that you can access the \\MDT01\MDTProduction$ share.

Add Windows 10 Enterprise x64 (full source)

If you have already have a Windows 10 reference image in the MDT Build Lab deployment share, you can
use the deployment workbench to copy and paste this image from the MDT Build Lab share to the MDT
Production share and skip the steps in this section.

On MDT01 :
1. Sign in as contoso\administrator and copy the content of a Windows 10 Enterprise x64 DVD/ISO to the
D:\Downloads\Windows 10 Enterprise x64 folder on MDT01, or just insert the DVD or mount an ISO on
MDT01.
2. Using the Deployment Workbench, expand the Deployment Shares node, and then expand MDT
Production .
3. Right-click the Operating Systems node, and create a new folder named Windows 10 .
4. Expand the Operating Systems node, right-click the Windows 10 folder, and select Impor t Operating
System . Use the following settings for the Import Operating System Wizard:
Full set of source files
Source directory: (location of your source files)
Destination directory name: W10EX64RTM
5. After adding the operating system, in the Operating Systems / Windows 10 folder, double-click it and
change the name to: Windows 10 Enterprise x64 RTM Default Image .

Create a task sequence to upgrade to Windows 10 Enterprise

On MDT01 :
1. Using the Deployment Workbench, select Task Sequences in the MDT Production node, then create a
folder named Windows 10 .
2. Right-click the new Windows 10 folder and select New Task Sequence . Use the following settings for the
New Task Sequence Wizard:
Task sequence ID: W10-X64-UPG
Task sequence name: Windows 10 Enterprise x64 RTM Upgrade
Template: Standard Client Upgrade Task Sequence
Select OS: Windows 10 Enterprise x64 RTM Default Image
Specify Product Key: Don't specify a product key at this time
Organization: Contoso
Admin Password: Don't specify an Administrator password at this time

Perform the Windows 10 upgrade

To initiate the in-place upgrade, perform the following steps on PC0002 (the device to be upgraded).
On PC0002 :
1. Start the MDT deployment wizard by running the following command:
\\MDT01\MDTProduction$\Scripts\LiteTouch.vbs
2. Select the Windows 10 Enterprise x64 RTM Upgrade task sequence, and then select Next .
3. Select one or more applications to install (will appear if you use custom image): Install - Adobe Reader
4. On the Ready tab, select Begin to start the task sequence. When the task sequence begins, it automatically
initiates the in-place upgrade process by invoking the Windows setup program (Setup.exe) with the
necessary command-line parameters to perform an automated upgrade, which preserves all data, settings,
apps, and drivers.
After the task sequence completes, the computer will be fully upgraded to Windows 10.

Related articles
Windows 10 deployment scenarios
Microsoft Deployment Toolkit downloads and resources
 Configure MDT settings
11/23/2022 • 2 minutes to read • Edit Online

One of the most powerful features in Microsoft Deployment Toolkit (MDT) is its extension capabilities; there's
virtually no limitation to what you can do in terms of customization. In this article, you learn about configuring
customizations for your environment. For the purposes of this article, we'll use four machines: DC01, MDT01,
HV01, and PC0001. DC01 is a domain controller, MDT01 is a Windows Server 2012 R2 Standard server, and
PC0001 is a Windows 10 Enterprise x64 client used for the MDT simulation environment. OR01 has Microsoft
System Center 2012 R2 Orchestrator installed. MDT01, OR01, and PC0001 are members of the domain
contoso.com for the fictitious Contoso Corporation. For more information on the setup for this article, see
Deploy Windows 10 with the Microsoft Deployment Toolkit.

The computers used in this article.

In this section
Set up MDT for BitLocker
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Simulate a Windows 10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use web services in MDT
Use Orchestrator runbooks with MDT

Related articles
Get started with the Microsoft Deployment Toolkit (MDT)
Create a Windows 10 reference image
Deploy a Windows 10 image using MDT
Build a distributed environment for Windows 10 deployment
Refresh a Windows 7 computer with Windows 10
Replace a Windows 7 computer with a Windows 10 computer
 Set up MDT for BitLocker
11/23/2022 • 6 minutes to read • Edit Online

This article will show you how to configure your environment for BitLocker, the disk volume encryption built
into Windows 10 Enterprise and Windows 10 Pro, using MDT. BitLocker in Windows 10 has two requirements in
regard to an operating system deployment:
A protector, which can either be stored in the Trusted Platform Module (TPM) chip, or stored as a password.
Technically, you can also use a USB stick to store the protector, but it's not a practical approach as the USB
stick can be lost or stolen. We, therefore, recommend that you instead use a TPM chip and/or a password.
Multiple partitions on the hard drive.
To configure your environment for BitLocker, you'll need to do the following actions:
1. Configure Active Directory for BitLocker.
2. Download the various BitLocker scripts and tools.
3. Configure the operating system deployment task sequence for BitLocker.
4. Configure the rules (CustomSettings.ini) for BitLocker.

NOTE
Even though it is not a BitLocker requirement, we recommend configuring BitLocker to store the recovery password in
Active Directory. For more information about this feature, see Backing Up BitLocker and TPM Recovery Information to AD
DS. If you have access to Microsoft BitLocker Administration and Monitoring (MBAM), which is part of Microsoft Desktop
Optimization Pack (MDOP), you have additional management features for BitLocker.

NOTE
Backing up TPM to Active Directory was supported only on Windows 10 version 1507 and 1511.

For the purposes of this article, we'll use DC01, a domain controller that is a member of the domain
contoso.com for the fictitious Contoso Corporation. For more information on the setup for this article, see
Deploy Windows 10 with the Microsoft Deployment Toolkit.

Configure Active Directory for BitLocker

To enable BitLocker to store the recovery key and TPM information in Active Directory, you need to create a
Group Policy for it in Active Directory. For this section, we're running Windows Server 2012 R2, so you don't
need to extend the Schema. You do, however, need to set the appropriate permissions in Active Directory.

NOTE
Depending on the Active Directory Schema version, you might need to update the Schema before you can store BitLocker
information in Active Directory.

In Windows Server version from 2008 R2 and later, you have access to the BitLocker Drive Encryption
Administration Utilities features, which will help you manage BitLocker. When you install the features, the
BitLocker Active Directory Recovery Password Viewer is included, and it extends Active Directory Users and
Computers with BitLocker Recovery information.
The BitLocker Recovery information on a computer object in the contoso.com domain.
Add the BitLocker Drive Encryption Administration Utilities
The BitLocker Drive Encryption Administration Utilities are added as features via Server Manager (or Windows
PowerShell):
1. On DC01, log on as CONTOSO\Administrator , and, using Server Manager, select Add roles and
features .
2. On the Before you begin page, select Next .
3. On the Select installation type page, select Role-based or feature-based installation , and select Next .
4. On the Select destination ser ver page, select DC01.contoso.com and select Next .
5. On the Select ser ver roles page, select Next .
6. On the Select features page, expand Remote Ser ver Administration Tools , expand Feature
Administration Tools , select the following features, and then select Next :
a. BitLocker Drive Encryption Administration Utilities
b. BitLocker Drive Encryption Tools
c. BitLocker Recovery Password Viewer
7. On the Confirm installation selections page, select Install , and then select Close .
Selecting the BitLocker Drive Encryption Administration Utilities.
Create the BitLocker Group Policy
Following these steps, you enable the backup of BitLocker and TPM recovery information to Active Directory.
You also enable the policy for the TPM validation profile.
1. On DC01, using Group Policy Management, right-click the Contoso organizational unit (OU), and select
Create a GPO in this domain, and Link it here .
2. Assign the name BitLocker Policy to the new Group Policy.
3. Expand the Contoso OU, right-click the BitLocker Policy , and select Edit . Configure the following policy
settings: Computer Configuration / Policies / Administrative Templates / Windows Components / BitLocker
Drive Encryption / Operating System Drives
a. Enable the Choose how BitLocker-protected operating system drives can be recovered
policy, and configure the following settings:
a. Allow data recovery agent (default)
b. Save BitLocker recovery information to Active Directory Domain Services (default)
c. Don't enable BitLocker until recovery information is stored in AD DS for operating system
drives
b. Enable the Configure TPM platform validation profile for BIOS-based firmware
configurations policy.
c. Enable the Configure TPM platform validation profile for native UEFI firmware
configurations policy.

NOTE
If you consistently get the error "Windows BitLocker Drive Encryption Information. The system boot information has
changed since BitLocker was enabled. You must supply a BitLocker recovery password to start this system." after
encrypting a computer with BitLocker, you might have to change the various "Configure TPM platform validation profile"
Group Policies, as well. Whether or not you need to do this will depend on the hardware you are using.

Set permissions in Active Directory for BitLocker

In addition to the Group Policy created previously, you need to configure permissions in Active Directory to be
able to store the TPM recovery information. In these steps, we assume you've downloaded the Add-
TPMSelfWriteACE.vbs script to C:\Setup\Scripts on DC01.
1. On DC01, start an elevated PowerShell prompt (run as Administrator).
2. Configure the permissions by running the following command:

cscript C:\Setup\Scripts\Add-TPMSelfWriteACE.vbs

Running the Add-TPMSelfWriteACE.vbs script on DC01.

Add BIOS configuration tools from Dell, HP, and Lenovo

If you want to automate enabling the TPM chip as part of the deployment process, you need to download the
vendor tools and add them to your task sequences, either directly or in a script wrapper.
Add tools from Dell
Dell Command | Configure provides a Command Line Interface and a Graphical User Interface.
Add tools from HP
The HP tools are part of HP System Software Manager. The executable file from HP is named
BiosConfigUtility.exe. This utility uses a configuration file for the BIOS settings. Here's a sample command to
enable TPM and set a BIOS password using the BiosConfigUtility.exe tool:

BIOSConfigUtility.EXE /SetConfig:TPMEnable.REPSET /NewAdminPassword:Password1234

And the sample content of the TPMEnable.REPSET file:

English
Activate Embedded Security On Next Boot
*Enable
Embedded Security Activation Policy
*No prompts
F1 to Boot
Allow user to reject
Embedded Security Device Availability
*Available

Add tools from Lenovo

The Lenovo tools are a set of VBScripts available as part of the Lenovo BIOS Setup using Windows Management
Instrumentation Deployment Guide. Lenovo also provides a separate download of the scripts. Here's a sample
command to enable TPM using the Lenovo tools:

cscript.exe SetConfig.vbs SecurityChip Active

Configure the Windows 10 task sequence to enable BitLocker
When configuring a task sequence to run any BitLocker tool, either directly or using a custom script, it's helpful if
you also add some logic to detect whether the BIOS is already configured on the machine. In the following task
sequence, we're using a sample script (ZTICheckforTPM.wsf) from the Deployment Guys web page to check the
status on the TPM chip. You can download this script from the Deployment Guys Blog post, Check to see if the
TPM is enabled.
In the following task sequence, we added five actions:
Check TPM Status. Runs the ZTICheckforTPM.wsf script to determine if TPM is enabled. Depending on
the status, the script will set the TPMEnabled and TPMActivated properties to either true or false.
Configure BIOS for TPM. Runs the vendor tools (in this case, HP, Dell, and Lenovo). To ensure this
action is run only when necessary, add a condition so the action is run only when the TPM chip isn't
already activated. Use the properties from the ZTICheckforTPM.wsf.

NOTE
It is common for organizations to wrap these tools in scripts to get additional logging and error handling.

Restar t computer. Self-explanatory, reboots the computer.

Check TPM Status. Runs the ZTICheckforTPM.wsf script one more time.
Enable BitLocker. Runs the built-in action to activate BitLocker.

Related articles
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Simulate a Windows 10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use web services in MDT
Use Orchestrator runbooks with MDT
 Configure MDT deployment share rules
11/23/2022 • 2 minutes to read • Edit Online

In this article, you'll learn how to configure the MDT rules engine to reach out to other resources, including
external scripts, databases, and web services, for additional information instead of storing settings directly in the
rules engine. The rules engine in MDT is powerful: most of the settings used for operating system deployments
are retrieved and assigned via the rules engine. In its simplest form, the rules engine is the CustomSettings.ini
text file.

Assign settings
When using MDT, you can assign setting in three distinct ways:
You can pre-stage the information before deployment.
You can prompt the user or technician for information.
You can have MDT generate the settings automatically.
In order to illustrate these three options, let's look at some sample configurations.

Sample configurations
Before adding the more advanced components like scripts, databases, and web services, consider the commonly
used configurations below; they demonstrate the power of the rules engine.
Set computer name by MAC Address
If you have a small test environment, or simply want to assign settings to a limited number of machines, you can
edit the rules to assign settings directly for a given MAC Address. When you have many machines, it makes
sense to use the database instead.

[Settings]
Priority=MacAddress, Default
[Default]
OSInstall=YES
[00:15:5D:85:6B:00]
OSDComputerName=PC00075

In the preceding sample, you set the PC00075 computer name for a machine with a MAC Address of
00:15:5D:85:6B:00.
Set computer name by serial number
Another way to assign a computer name is to identify the machine via its serial number.

[Settings]
Priority=SerialNumber, Default
[Default]
OSInstall=YES
[CND0370RJ7]
OSDComputerName=PC00075

In this sample, you set the PC00075 computer name for a machine with a serial number of CND0370RJ7.
Generate a computer name based on a serial number
You also can configure the rules engine to use a known property, like a serial number, to generate a computer
name on the fly.

[Settings]
Priority=Default
[Default]
OSInstall=YES
OSDComputerName=PC-%SerialNumber%

In this sample, you configure the rules to set the computer name to a prefix (PC-) and then the serial number. If
the serial number of the machine is CND0370RJ7, the preceding configuration sets the computer name to PC-
CND0370RJ7. Note
Be careful when using the serial number to assign computer names. A serial number can contain more than 15
characters, but the Windows setup limits a computer name to 15 characters.
Generate a limited computer name based on a serial number
To avoid assigning a computer name longer than 15 characters, you can configure the rules in more detail by
adding VBScript functions, as follows:

[Settings]
Priority=Default
[Default]
OSInstall=YES
OSDComputerName=PC-#Left("%SerialNumber%",12)#

In the preceding sample, you still configure the rules to set the computer name to a prefix (PC-) followed by the
serial number. However, by adding the Left VBScript function, you configure the rule to use only the first 12
serial-number characters for the name.
Add laptops to a different organizational unit (OU ) in Active Directory
In the rules, you find built-in properties that use a Windows Management Instrumentation (WMI) query to
determine whether the machine you're deploying is a laptop, desktop, or server. In this sample, we assume you
want to add laptops to different OUs in Active Directory. Note that ByLaptopType isn't a reserved word; rather,
it's the name of the section to read.

[Settings]
Priority=ByLaptopType, Default
[Default]
MachineObjectOU=OU=Workstations,OU=Contoso,DC=contoso,DC=com
[ByLaptopType]
Subsection=Laptop-%IsLaptop%
[Laptop-True]
MachineObjectOU=OU=Laptops,OU=Contoso,DC=contoso,DC=com

Related articles
Set up MDT for BitLocker
Configure MDT for UserExit scripts
Simulate a Windows 10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use web services in MDT
Use Orchestrator runbooks with MDT
 Configure MDT for UserExit scripts
11/23/2022 • 2 minutes to read • Edit Online

In this article, you'll learn how to configure the MDT rules engine to use a UserExit script to generate computer
names based on a prefix and the computer MAC Address. MDT supports calling external VBScripts as part of the
Gather process; these scripts are referred to as UserExit scripts. The script also removes the colons in the MAC
Address.

Configure the rules to call a UserExit script

You can call a UserExit by referencing the script in your rules. Then you can configure a property to be set to the
result of a function of the VBScript. In this example, we have a VBScript named Setname.vbs (provided in the
book sample files, in the UserExit folder).

[Settings]
Priority=Default
[Default]
OSINSTALL=YES
UserExit=Setname.vbs
OSDComputerName=#SetName("%MACADDRESS%")#

The UserExit=Setname.vbs calls the script and then assigns the computer name to what the SetName function in
the script returns. In this sample, the %MACADDRESS% variable is passed to the script

The Setname.vbs UserExit script

The Setname.vbs script takes the MAC Address passed from the rules. The script then does some string
manipulation to add a prefix (PC) and remove the semicolons from the MAC Address.

Function UserExit(sType, sWhen, sDetail, bSkip)

UserExit = Success
End Function
Function SetName(sMac)
Dim re
Set re = new RegExp
re.IgnoreCase = true
re.Global = true
re.Pattern = ":"
SetName = "PC" & re.Replace(sMac, "")
End Function

The first three lines of the script make up a header that all UserExit scripts have. The interesting part is the lines
between Function and End Function. Those lines add a prefix (PC), remove the colons from the MAC Address,
and return the value to the rules by setting the SetName value.

NOTE
The purpose of this sample isn't to recommend that you use the MAC Address as a base for computer naming, but to
show you how to take a variable from MDT, pass it to an external script, make some changes to it, and then return the
new value to the deployment process.
Related articles
Set up MDT for BitLocker
Configure MDT deployment share rules
Simulate a Windows 10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use web services in MDT
Use Orchestrator runbooks with MDT
 Simulate a Windows 10 deployment in a test
environment
11/23/2022 • 2 minutes to read • Edit Online

This article will walk you through the process of creating a simulated environment on which to test your
Windows 10 deployment using MDT. When working with advanced settings and rules, especially those like
database calls, it's most efficient to be able to test the settings without having to run through a complete
deployment. Luckily, MDT enables you to perform a simulated deployment by running the Gather process by
itself. The simulation works best when you're using a domain-joined client.

Test environment
A Windows 10 client named PC0001 will be used to simulate deployment. The client is joined to the
contoso.com domain and has access to the Internet to required download tools and scripts.
It's assumed that you've performed (at least) the following procedures so that you have an MDT service
account and an MDT production deployment share:
Prepare for deployment with MDT
Create a Windows 10 reference image
Deploy a Windows 10 image using MDT

Simulate deployment
On PC0001 :
1. Sign as contoso\Administrator .
2. Copy the following to a PowerShell script named gather.ps1 and copy it to a directory named C:\MDT on
PC0001.

# Check for elevation

If (-NOT ([Security.Principal.WindowsPrincipal]
[Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(`
[Security.Principal.WindowsBuiltInRole] "Administrator"))
{
Write-Warning "Oupps, you need to run this script from an elevated PowerShell prompt!`nPlease
start the PowerShell prompt as an Administrator and re-run the script."
Write-Warning "Aborting script..."
Break
}
cls
if (Test-Path -Path "C:\MININT") {Write-Host "C:\MININT exists, deleting...";Remove-Item C:\MININT -
Recurse}
cscript.exe ZTIGather.wsf /debug:true
# Optional, comment out if you want the script to open the log in CMTrace
& "C:\MDT\CMTrace" C:\MININT\SMSOSD\OSDLOGS\ZTIGather.log

3. Download and install the free Configuration Manager Toolkit on PC0001 so that you have access to the
Configuration Manager Trace (cmtrace.exe) tool.
4. Using Local Users and Groups (lusrmgr.msc), add the contoso\MDT_BA user account to the local
Administrators group.
 5. Sign off, and then sign on to PC0001 as contoso\MDT_BA .
6. Open the \\MDT01\MDTProduction$\Scripts folder and copy the following files to C:\MDT :
a. ZTIDataAccess.vbs
b. ZTIGather.wsf
c. ZTIGather.xml
d. ZTIUtility.vbs
7. From the \\MDT01\MDTProduction$\Control folder, copy the CustomSettings.ini file to C:\MDT .
8. In the C:\MDT folder, create a subfolder named X64 .
9. From the \\MDT01\MDTProduction$\Tools\X64 folder, copy the Microsoft.BDD.Utility.dll file to
C:\MDT\X64 .

The C:\MDT folder with the files added for the simulation environment.
10. Type the following at an elevated Windows PowerShell prompt:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process -Force

Set-Location C:\MDT
.\Gather.ps1

When prompted, press R to run the gather script.

11. Review the ZTIGather.log in the C:\MININT\SMSOSD\OSDLOGS folder using CMTrace. Note
Warnings or errors regarding the Wizard.hta are expected. If the log file looks okay, you're ready to try a
real deployment.
The ZTIGather.log file from PC0001.

Related articles
Set up MDT for BitLocker
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use web services in MDT
Use Orchestrator runbooks with MDT
 Use the MDT database to stage Windows 10
deployment information
11/23/2022 • 3 minutes to read • Edit Online

This article is designed to teach you how to use the MDT database to pre-stage information on your Windows
10 deployment in a Microsoft SQL Server 2012 SP1 Express database, rather than include the information in a
text file (CustomSettings.ini). You can use this process, for example, to add the client machines you want to
deploy, specify their computer names and IP addresses, indicate applications to be deployed, and determine
many more settings for the machines.

Database prerequisites
MDT can use either SQL Server Express or full SQL Server. However, since the deployment database isn't large,
even in large enterprise environments, we recommend using the free SQL Server 2012 SP1 Express database in
your environment.

NOTE
Be sure to enable Named Pipes when configuring the SQL Server 2012 SP1 Express database. Although it is a legacy
protocol, Named Pipes has proven to work well when connecting from Windows Preinstallation Environment (Windows
PE) to the SQL Server database.

Create the deployment database

The MDT database is by default created and managed from the Deployment Workbench. In these steps, we
assume you have installed SQL Server 2012 SP1 Express on MDT01.

NOTE
Since SQL Server 2012 SP1 Express runs by default on a separate instance (SQLEXPRESS), the SQL Server Browser service
must be running, and the firewall configured to allow traffic to it. Port 1433 TCP and port 1434 UDP need to be opened
for inbound traffic on MDT01.

1. On MDT01, using Deployment Workbench, expand the MDT Production deployment share, expand
Advanced Configuration , right-click Database , and select New Database .
2. In the New DB Wizard, on the SQL Ser ver Details page, enter the following settings and select Next :
a. SQL Server Name: MDT01
b. Instance: SQLEXPRESS
c. Port: <blank>
d. Network Library: Named Pipes
3. On the Database page, select Create a new database ; in the Database field, type MDT and select Next .
4. On the SQL Share page, in the SQL Share field, type Logs$ and select Next . Select Next again and then
select Finish .
Figure 8. The MDT database added to MDT01.

Configure database permissions

After creating the database, you need to assign permissions to it. In MDT, the account you used to run the
deployment is used to access the database. In this environment, the network access account is MDT_BA.
1. On MDT01, start SQL Server Management Studio.
2. In the Connect to Ser ver dialog box, in the Ser ver name list, select MDT01\SQLEXPRESS and select
Connect .
3. In the Object Explorer pane, expand the top-level Security node, right-click Logins , and select New
Login .

Figure 9. The top-level Security node.

4. On the Login - New page, next to the Login name field, select Search , and search for
CONTOSO\MDT_BA . Then in the left pane, select User Mapping . Select the MDT database, and assign
the following roles:
a. db_datareader
b. db_datawriter
 c. public (default)
5. Select OK , and close SQL Server Management Studio.

Figure 10. Creating the login and settings permissions to the MDT database.

Create an entry in the database

To start using the database, you add a computer entry and assign a description and computer name. Use the
computer's MAC Address as the identifier.
1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, expand Advanced
Configuration , and expand Database .
2. Right-click Computers , select New , and add a computer entry with the following settings:
a. Description: New York Site - PC00075
b. MacAddress: <PC00075 MAC Address in the 00:00:00:00:00:00 format>
c. Details Tab / OSDComputerName: PC00075
Figure 11. Adding the PC00075 computer to the database.

Related articles
Set up MDT for BitLocker
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Simulate a Windows 10 deployment in a test environment
Assign applications using roles in MDT
Use web services in MDT
Use Orchestrator runbooks with MDT
 Assign applications using roles in MDT
11/23/2022 • 2 minutes to read • Edit Online

This article will show you how to add applications to a role in the MDT database and then assign that role to a
computer. For the purposes of this article, the application we're adding is Adobe Reader XI. In addition to using
computer-specific entries in the database, you can use roles in MDT to group settings together.

Create and assign a role entry in the database

1. On MDT01, using Deployment Workbench, in the MDT Production deployment share, expand Advanced
Configuration and then expand Database .
2. In the Database node, right-click Role , select New , and create a role entry with the following settings:
a. Role name: Standard PC
b. Applications / Lite Touch Applications:
c. Install - Adobe Reader XI - x86

Figure 12. The Standard PC role with the application added

Associate the role with a computer in the database

After creating the role, you can associate it with one or more computer entries.
1. Using Deployment Workbench, expand MDT Production , expand Advanced Configuration , expand
Database , and select Computers .
2. In the Computers node, double-click the PC00075 entry, and add the following setting:
Roles: Standard PC
Figure 13. The Standard PC role added to PC00075 (having ID 1 in the database).

Verify database access in the MDT simulation environment

When the database is populated, you can use the MDT simulation environment to simulate a deployment. The
applications aren't installed, but you can see which applications would be installed if you did a full deployment
of the computer.
1. On PC0001, log on as CONTOSO\MDT_BA .
2. Modify the C:\MDT\CustomSettings.ini file to look like below:
 [Settings]
Priority=CSettings, CRoles, RApplications, Default
[Default]
_SMSTSORGNAME=Contoso
OSInstall=Y
UserDataLocation=AUTO
TimeZoneName=Pacific Standard Time
AdminPassword=P@ssw0rd
JoinDomain=contoso.com
DomainAdmin=CONTOSO\MDT_JD
DomainAdminPassword=P@ssw0rd
MachineObjectOU=OU=Workstations,OU=Computers,OU=Contoso,DC=contoso,DC=com
SLShare=\\MDT01\Logs$
ScanStateArgs=/ue:*\* /ui:CONTOSO\*
USMTMigFiles001=MigApp.xml
USMTMigFiles002=MigUser.xml
HideShell=YES
ApplyGPOPack=NO
SkipAppsOnUpgrade=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipDomainMembership=YES
SkipUserData=NO
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=NO
SkipBitLocker=YES
SkipSummary=YES
SkipCapture=YES
SkipFinalSummary=NO
EventService=http://MDT01:9800
[CSettings]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
[CRoles]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
[RApplications]
SQLServer=MDT01
Instance=SQLEXPRESS
Database=MDT
Netlib=DBNMPNTW
SQLShare=Logs$
Table=RoleApplications
Parameters=Role
Order=Sequence

3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands.
Press Enter after each command:
 Set-Location C:\MDT
.\Gather.ps1

Figure 14. ZTIGather.log displaying the application GUID belonging to the Adobe Reader XI application that
would have been installed if you deployed this machine.

Related articles
Set up MDT for BitLocker
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Simulate a Windows 10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Use web services in MDT
Use Orchestrator runbooks with MDT
 Use web services in MDT
11/23/2022 • 3 minutes to read • Edit Online

In this article, you'll learn how to create a simple web service that generates computer names and then
configure MDT to use that service during your Windows 10 deployment. Web services provide a powerful way
to assign settings during a deployment. Web services are web applications that run code on the server side, and
MDT has built-in functions to call these web services. Using a web service in MDT is straightforward, but it does
require that you've enabled the Web Server (IIS) role on the server. Developing web services involves some
coding, but for most web services used with MDT, you can use the free Microsoft Visual Studio Express 2013 for
Web.

Create a sample web service

In these steps, we assume you have installed Microsoft Visual Studio Express 2013 for Web on PC0001 (the
Windows 10 client) and downloaded the MDT Sample Web Service from the Microsoft Download Center and
extracted it to C:\Projects.
1. On PC0001, using Visual Studio Express 2013 for Web, open the C:\Projects\MDTSample\ MDTSample.sln
solution file.
2. On the ribbon bar, verify that Release is selected.
3. In the Debug menu, select the Build MDTSample action.
4. On MDT01, create a folder structure for E:\MDTSample\bin .
5. From PC0001, copy the C:\Projects\MDTSample\obj\Release\MDTSample.dll file to the E:\MDTSample\bin
folder on MDT01.
6. From PC0001, copy the following files from C:\Projects\MDTSample file to the E:\MDTSample folder on
MDT01:
a. Web.config
b. mdtsample.asmx
Figure 15. The sample project in Microsoft Visual Studio Express 2013 for Web.

Create an application pool for the web service

This section assumes that you've enabled the Web Server (IIS) role on MDT01.
1. On MDT01, using Server Manager, install the IIS Management Console role (available under Web Server
(IIS) / Management Tools).
2. Using Internet Information Services (IIS) Manager, expand the MDT01 (CONTOSO\Administrator) node. If
prompted with the Do you want to get star ted with Microsoft Web Platform? question, select the Do
not show this message check box and then select No .
3. Right-click Application Pools , select Add Application Pool , and configure the new application pool with
the following settings:
a. Name: MDTSample
b. .NET Framework version: .NET Framework 4.0.30319
c. Manage pipeline mode: Integrated
d. Select the Star t application pool immediately check box.
e. Select OK .

Figure 16. The new MDTSample application.

Install the web service

1. On MDT01, using Internet Information Services (IIS) Manager, expand Sites , right-click Default Web
Site , and select Add Application . Use the following settings for the application:
a. Alias: MDTSample
b. Application pool: MDTSample
c. Physical Path: E:\MDTSample
 Figure 17. Adding the MDTSample web application.
2. In the Default Web Site node, select the MDTSample web application, and in the right pane, double-
click Authentication . Use the following settings for the Authentication dialog box:
a. Anonymous Authentication: Enabled
b. ASP.NET Impersonation: Disabled

Figure 18. Configuring Authentication for the MDTSample web service.

Test the web service in Internet Explorer

1. On PC0001, using Internet Explorer, navigate to: http://MDT01/MDTSample/mdtsample.asmx .
2. Select the GetComputerName link.
 Figure 19. The MDT Sample web service.
3. On the GetComputerName page, type in the following settings, and select Invoke :
a. Model: Hewlett-Packard
b. SerialNumber: 123456789

Figure 20. The result from the MDT Sample web service.

Test the web service in the MDT simulation environment

After verifying the web service using Internet Explorer, you're ready to do the same test in the MDT simulation
environment.
1. On PC0001, edit the CustomSettings.ini file in the C:\MDT folder to look like the following:

[Settings]
Priority=Default, GetComputerName
[Default]
OSInstall=YES
[GetComputerName]
WebService=http://mdt01/MDTSample/mdtsample.asmx/GetComputerName
Parameters=Model,SerialNumber
OSDComputerName=string
 Figure 21. The updated CustomSettings.ini file.
2. Save the CustomSettings.ini file.
3. Using an elevated Windows PowerShell prompt (run as Administrator), run the following commands.
Press Enter after each command:

Set-Location C:\MDT
.\Gather.ps1

4. Review the ZTIGather.log in the C:\MININT\SMSOSD\OSDLOGS folder.

Figure 22. The OSDCOMPUTERNAME value obtained from the web service.

Related articles
Set up MDT for BitLocker
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Simulate a Windows 10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use Orchestrator runbooks with MDT
 Use Orchestrator runbooks with MDT
11/23/2022 • 5 minutes to read • Edit Online

This article will show you how to integrate Microsoft System Center 2012 R2 Orchestrator with MDT to replace
the existing web services that are used in deployment solutions. MDT can integrate with System Center 2012 R2
Orchestrator, which is a component that ties the Microsoft System Center products together, as well as other
products from both Microsoft and third-party vendors. The difference between using Orchestrator and "normal"
web services, is that with Orchestrator you have a rich drag-and-drop style interface when building the solution,
and little or no coding is required.

NOTE
If you are licensed to use Orchestrator, we highly recommend that you start using it. To find out more about licensing
options for System Center 2012 R2 and Orchestrator, visit the System Center 2012 R2 website.

Orchestrator terminology
Before diving into the core details, here's a quick course in Orchestrator terminology:
Orchestrator Ser ver. This is a server that executes runbooks.
Runbooks. A runbook is similar to a task sequence; it's a series of instructions based on conditions.
Runbooks consist of workflow activities; an activity could be Copy File, Get User from Active Directory, or
even Write to Database.
Orchestrator Designer. This is where you build the runbooks. In brief, you do that by creating an empty
runbook, dragging in the activities you need, and then connecting them in a workflow with conditions and
subscriptions.
Subscriptions. These are variables that come from an earlier activity in the runbook. So if you first execute
an activity in which you type in a computer name, you can then subscribe to that value in the next activity. All
these variables are accumulated during the execution of the runbook.
Orchestrator Console. This is the Microsoft Silverlight-based web page you can use interactively to
execute runbooks. The console listens to TCP port 81 by default.
Orchestrator web ser vices. These are the web services you use in the Microsoft Deployment Toolkit to
execute runbooks during deployment. The web services listen to TCP port 82 by default.
Integration packs. These provide additional workflow activities you can import to integrate with other
products or solutions, like the rest of Active Directory, other System Center 2012 R2 products, or Microsoft
Exchange Server, to name a few.
Note
To find and download additional integration packs, see Integration Packs for System Center 2012 - Orchestrator.

Create a sample runbook

This section assumes you have Orchestrator 2012 R2 installed on a server named OR01. In this section, you
create a sample runbook, which is used to log some of the MDT deployment information into a text file on
OR01.
1. On OR01, using File Explorer, create the E:\Logfile folder, and grant Users modify permissions (NTFS).
2. In the E:\Logfile folder, create the DeployLog.txt file. Note
 Make sure File Explorer is configured to show known file extensions so the file isn't named
DeployLog.txt.txt.

Figure 23. The DeployLog.txt file.

3. Using System Center 2012 R2 Orchestrator Runbook Designer, in the Runbooks node, create the 1.0
MDT folder.

Figure 24. Folder created in the Runbooks node.

4. In the Runbooks node, right-click the 1.0 MDT folder, and select New / Runbook .
5. On the ribbon bar, select Check Out .
6. Right-click the New Runbook label, select Rename , and assign the name MDT Sample .
7. Add (using a drag-and-drop operation) the following items from the Activities list to the middle pane:
a. Runbook Control / Initialize Data
b. Text File Management / Append Line
8. Connect Initialize Data to Append Line .
 Figure 25. Activities added and connected.
9. Right-click the Initialize Data activity, and select Proper ties
10. On the Initialize Data Proper ties page, select Add , change Parameter 1 to OSDComputerName ,
and then select Finish .

Figure 26. The Initialize Data Properties window.

11. Right-click the Append Line activity, and select Proper ties .
12. On the Append Line Proper ties page, in the File text box, type E:\Logfile\DeployLog.txt .
13. In the File encoding drop-down list, select ASCII .
14. In the Append area, right-click inside the Text text box and select Expand .
 Figure 27. Expanding the Text area.
15. In the blank text box, right-click and select Subscribe / Published Data .

Figure 28. Subscribing to data.

16. In the Published Data window, select the OSDComputerName item, and select OK .
17. After the {OSDComputerName from "Initialize Data"} text, type in has been deployed at and,
once again, right-click and select Subscribe / Published Data .
18. In the Published Data window, select the Show common Published Data check box, select the
Activity end time item, and select OK .
 Figure 29. The expanded text box after all subscriptions have been added.
19. On the Append Line Proper ties page, select Finish .

Test the demo MDT runbook

After the runbook is created, you're ready to test it.
20. On the ribbon bar, select Runbook Tester .
21. Select Run , and in the Initialize Data Parameters dialog box, use the following setting and then select
OK :
OSDComputerName: PC0010
22. Verify that all activities are green (for more information, see each target).
23. Close the Runbook Tester .
24. On the ribbon bar, select Check In .

Figure 30. All tests completed.

Use the MDT demo runbook from MDT

1. On MDT01, using the Deployment Workbench, in the MDT Production deployment share, select the Task
 Sequences node, and create a folder named Orchestrator .
2. Right-click the Orchestrator node, and select New Task Sequence . Use the following settings for the New
Task Sequence Wizard:
a. Task sequence ID: OR001
b. Task sequence name: Orchestrator Sample
c. Task sequence comments: <blank>
d. Template: Custom Task Sequence
3. In the Orchestrator node, double-click the Orchestrator Sample task sequence, and then select the Task
Sequence tab.
4. Remove the default Application Install action.
5. Add a Gather action and select the Gather only local data (do not process rules) option.
6. After the Gather action, add a Set Task Sequence Variable action with the following settings:
a. Name: Set Task Sequence Variable
b. Task Sequence Variable: OSDComputerName
c. Value: %hostname%
7. After the Set Task Sequence Variable action, add a new Execute Orchestrator Runbook action with the
following settings:
a. Orchestrator Server: OR01.contoso.com
b. Use Browse to select 1.0 MDT / MDT Sample .
8. Select OK .

Figure 31. The ready-made task sequence.

Run the orchestrator sample task sequence

Since this task sequence just starts a runbook, you can test the task sequence on the PC0001 client that you
used for the MDT simulation environment. Note
Make sure the account you're using has permissions to run runbooks on the Orchestrator server. For more
information about runbook permissions, see Runbook Permissions.
1. On PC0001, log on as CONTOSO\MDT_BA .
2. Using an elevated command prompt (run as Administrator), type the following command:

cscript \\MDT01\MDTProduction$\Scripts\Litetouch.vbs

3. Complete the Windows Deployment Wizard using the following information:

a. Task Sequence: Orchestrator Sample
b. Credentials:
a. User Name: MDT_BA
b. Password: P@ssw0rd
c. Domain: CONTOSO
4. Wait until the task sequence is completed and then verify that the DeployLog.txt file in the E:\Logfile
folder on OR01 was updated.

Figure 32. The ready-made task sequence.

Related articles
Set up MDT for BitLocker
Configure MDT deployment share rules
Configure MDT for UserExit scripts
Simulate a Windows10 deployment in a test environment
Use the MDT database to stage Windows 10 deployment information
Assign applications using roles in MDT
Use web services in MDT