top of page

MDT Installation - From Zero to PXE in 45 minutes

Manual installation and configuration of Microsoft Deployment Toolkit (MDT), ADK, WDS and DHCP were covered (here). If you are not familiar with MDT I recommend following those articles.

After following all that, it's likely your hoping for an easier option, it just happens you are in luck......

With a little prep, it's possible to start network deployments of Windows 10 in as little as 45 minutes with a fully deployed and configured MDT, DHCP and WDS server. 

To start with, install Server 2019 the following server configuration will suffice.

MDT Server requirements:

VM or Physical Server 

Windows Server 2019 or above, not tested on 2012 or 2016.
C:\ 60Gb min
D:\ 60Gb 
2048Mb RAM, 4096Mbs preferred
2 * Cores


Download  ADK and ADK PE to C:\Media\ADK\ and C:\Media\ADKPE\ respectively.

Download MDT x64 to C:\Media\MDT\


Copy sources\sxs\* from the Server 2019 DVD to C:\Media\SXS\

Copy the Windows 10 iso to C:\Media\Win10\

C:\Media will have the following file\folder structure.

         |         |    adksetup.exe
         |         |    UserExperienceManifest.xml
         |         |
         |         |───Installers
         |                        ...................
         |          |    adkwinpesetup.exe
         |          |    UserExperienceManifest.xml
         |          |
         |          |───Installers
         |            MicrosoftDeploymentToolkit_x64.msi

Grab the script AutoMDTDeployoment.ps1 downloadable from, save to C:\Media.

Elevate the command prompt and run the following:

powershell.exe -executionpolicy bypass -file C:\Media\AutoMDTDeployment.ps1

or elevate PowerShell_ise open the script and press F8.

The script will take about 45 minutes to run, once completed power on a client and pxe to deploy Windows 10 via a MDT Task Sequence.


Note - There are limitations with drivers in its current configuration, if Windows 10 doesn't natively support the network adapter and mass storage devices, the deployment will fail. Follow MDT part 6 to resolve any driver issues.

The following section has the relevant screenshots and script extracts to provide support and to validate that the correct settings are applied.

DHCP and WDS are installed with the following.

Install-WindowsFeature -Name DHCP,RSAT-DHCP,WDS,WDS-AdminPack

A DHCP scope created based on the answers provided.


Add-DhcpServerv4Scope -ComputerName $hostn `
                          -Name $scopeName `
                          -StartRange $DHCPStart `
                          -EndRange $DHCPEnd `
                          -SubnetMask $DHCPSub `
                          -Description "MDT Client Deployment Scope" `
                          -State Active 

Set-DhcpServerv4OptionValue -ComputerName $hostn -OptionId 001 -Value 0x2 -ScopeId $scopeID.ScopeId -Force
Set-DhcpServerv4OptionValue -ComputerName $hostn -OptionId 003 -value $DefGate -ScopeId $scopeID.ScopeId
Set-DhcpServerv4OptionValue -ComputerName $hostn -OptionId 006 -value $dnsServer -ScopeId $scopeID.ScopeId -Force
Set-DhcpServerv4OptionValue -ComputerName $hostn -OptionId 015 -value $dnsName -ScopeId $scopeID.ScopeId -Force
Set-DhcpServerv4Optionvalue -ComputerName $hostn -OptionId 066 -Value $IPAddress -ScopeId $scopeID.ScopeId
Set-DhcpServerv4Optionvalue -ComputerName $hostn -OptionId 067 -Value "boot\x64\bootmgfw.efi" -ScopeId $scopeID.ScopeId

Note - Installing DHCP alongside an existing DHCP server on the same network is bad news, it will get messy. 

WDS is activated with the following command.

wdsutil.exe /Initialize-Server /Server:$hostn /reminst:$wdsDrv /standalone

Note - Remove the '/standalone' switch if the server is part of the domain.

MDT generates a boot image and its imported into WDS.

Update-MDTDeploymentShare -path "DS002:" -Force -Verbose

Import-WdsBootImage -NewImageName "Lite Touch Windows PE (x64)" -NewFileName "LiteTouchPE_x64.wim" -Path $mdtRoot\boot\LiteTouchPE_x64.wim 

Windows 10 folders created for 'Operating Systems' and 'Task Sequences'.

The Windows 10 iso is mounted.

Mount-DiskImage -ImagePath (Get-ChildItem C:\Media\Win10 -Filter *.iso).FullName

$psISO = (psdrive | where {$_.Free -eq "0"}).Name[0]

and then imported into MDT.

Import-MDTOperatingSystem -path "DS002:\Operating Systems\Windows 10" -SourceFile "$psISO`:\sources\install.wim" -DestinationFolder "Windows 10" -Verbose

The OperatingSystems.xml is parsed for the imported Windows images.

$gcOSImage = (Get-Content "$mdtRoot\Control\OperatingSystems.xml" -Delimiter / | Select-String "<ImageName>")-replace("</","")-replace("ImageIndex><ImageName>","")

In the first instance Enterprise will be selected, if its not available Pro is selected and the Task Sequence is created.

if ($gcOSImage -match "Windows 10 Enterprise" )

{ Import-MDTTaskSequence -path "DS002:\Task Sequences\Windows 10 Gold Image" -Name "Windows 10 Enterprise Gold Image" -Template "Client.xml" -Comments "" -ID $tsID -Version "1.0" -OperatingSystemPath "DS002:\Operating Systems\Windows 10\Windows 10 Enterprise in Windows 10 install.wim" -FullName "Windows User" -OrgName "Contoso" -HomePage "about:blank" }

Win10_PE Selection profile created for Network and Mass Storage drivers.

New-Item -path "DS002:\Selection Profiles" -enable "True" -Name "Win10PE_Drivers" -Comments "Only add Network and Storage drivers to this profile" -Definition "<SelectionProfile />" -ReadOnly "False" -Verbose

Right click and properties on the Deployment Share, select Rules.

CustomSettings and are updated to control deployment wizard behaviour.

$cuSet = "$mdtRoot\Control\CustomSettings.ini"

Set-Content -Path $cuSet -Value "[Settings]"
Add-Content -Path $cuSet -Value "Priority=Model,ByVMType,ByLaptopType,ByDesktopType,DefaultGateway,Default"
Add-Content -Path $cuSet -Value "Properties=MyCustomProperty"

To update the 'Windows PE' tab for x64 platforms the xml files were updated directly.

Updates to $mdtRoot\Control\Settings.xml were reverted unless made in Workbench or updated the template xml at "C:\Program Files\Microsoft Deployment Toolkit\Templates\settings.xml" .

$mdtSetSrc = "C:\Program Files\Microsoft Deployment Toolkit\Templates\"

$gcSettings = Get-Content $mdtSetSrc\Settings.xml 

$mdtRoot = "D:\DeploymentShare\"

$gcSettings = Get-Content $mdtRoot\Control\Settings.xml

$gcSettings.Replace('Boot.x64.ScratchSpace>32</Boot.x64.ScratchSpace','Boot.x64.ScratchSpace>512</Boot.x64.ScratchSpace') | 
Out-File $mdtSetSrc\Settings.xml -Force

Likewise, the selection profile referenced during boot media creation was changed to the Win10PE_Drivers selection profile.

Enabling the 'Monitoing' tab with Enable-MDTMonitorService -EventPort 9800 -DataPort 9801 wasn't possible, again reverted to updating the xml files directly.

$gcSettings = Get-Content $mdtSetSrc\Settings.xml 
$gcSettings.Replace('<MonitorHost>',"`<MonitorHost>$hostn")  |  Out-File $mdtSetSrc\Settings.xml -Force

A non-privilege service account is created with a random password for access the MDT Shares.

$mdtUser = "MDTUser"
$pwl = 14
$sysWeb = Add-Type -AssemblyName system.web
$randPass = [System.Web.Security.Membership]::GeneratePassword($pwl,0)

$svcPass = ConvertTo-SecureString $randPass -AsPlainText -Force 

New-LocalUser    -Name $mdtUser `
                     -Description "MDT Service Account" `
                     -FullName $mdtUser `
                     -Password $svcPass `
                     -AccountNeverExpires `

MDTUser is set READ Share and File permissions access to the MDT Root Share, MODIFY Share and File permissions to the Logs and Captures shares.

New-SmbShare -ReadAccess $mdtuser -Path $mdtRoot -Name $mdtShRoot -Description $mdtShRtDes

New-SmbShare -ChangeAccess $mdtUser -Path $mdtLogs -Name $mdtShLogs -Description "Logs Share"

New-SmbShare -ChangeAccess $mdtUser-Path $mdtCap -Name $mdtShCap -Description "Capture Share" 

$aclMdtRoot = Get-Acl $MdtRoot
$arMdtRoot = New-Object System.Security.AccessControl.FileSystemAccessRule("$mdtUser","READ","$inherCnIn,$inherObIn","None","Allow")
Set-Acl $MdtRoot $aclMdtRoot

Time permitting, driver support within the Task Sequence will be added and those VMWare advocates placated.

As always, thanks for reading, comments would be gratefully appreciated.

bottom of page