Introduction
Microsoft Deployment Toolkit (MDT) is a free-to-use collection of tools to automate desktop, laptop, and server deployments. MDT can be used to create a base reference image, also known as a golden image, or a complete deployment solution.

I have recently built an MDT environment within VMware with the latest versions of Windows ADK and MDT and faced multiple issues that resulted in a lot of troubleshooting. This blog describes the challenges I’ve encountered building the MDT environment.

Resources
The following resources are used in building and testing the MDT environment:

Windows Server 2022 Standard edition

• 2vcpu
• 4GB Ram
• 50GB primary disk
• 100GB Data disk

Windows 10 x64 22H2 Enterprise edition

• 2vcpu
• 4GB Ram
• 48GB primary disk
• TPM enabled
• UEFI

Windows 10 x64 22H2 Enterprise edition

• 2vcpu
• 4GB Ram
• 48GB primary disk
• TPM disabled
• Legacy BIOS

Windows 11 x64 22H2 Enterprise edition

• 2vcpu
• 4GB Ram
• 48GB primary disk
• TPM enabled
• UEFI

Windows ADK for Windows 11, version 22H2:
https://go.microsoft.com/fwlink/?linkid=2196127

Windows ADK PE add-on for Windows 11, version 22H2:
https://go.microsoft.com/fwlink/?linkid=2196224

Microsoft Deployment Toolkit, version 8456:
https://www.microsoft.com/en-us/download/confirmation.aspx?id=54259

Configuration issues
Several issues occurred during the installation and configuration of MDT. Some of them failed during the task sequence, while others prevented the task sequence from starting at all.

ADK for Windows 11 does not support x86
Windows ADK for Windows 11, version 22H2, does no longer include x86 WinPE and will not create the x86 directory within the ADK installation directory. Opening the WinPE settings within the Deployment Share properties will show the following error:

You’ll have to manually create an empty x86 WinPE directory to resolve the crash of the Deployment Workbench.

1. Navigate to the Windows ADK installation directory:
   C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment
2. Create a new folder, name it: x86
3. Create a new folder in the x86 folder, name it: WinPE_OCs

Script error at the start of Task Sequence
Another side effect of using Windows ADK for Windows 11 is that HTML (HTA) applications stop working as the default legacy scripting engine that previously included MSHTML has changed starting with Windows 11. This change is the cause of your task sequence providing a script error directly after PXE booting.

This script error can be fixed by adding the following registry value in WinPE:

1. Navigate to C:\Program Files\Microsoft Deployment Toolkit\Templates
2. Copy Unattend_PE_x64.xml to a backup location, just in case
3. Edit Unattend_PE_x64.xml
4. Replace the Unattend_PE_x64.xml content with:<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
<Display>
<ColorDepth>32</ColorDepth>
<HorizontalResolution>1024</HorizontalResolution>
<RefreshRate>60</RefreshRate>
<VerticalResolution>768</VerticalResolution>
</Display>
<RunSynchronous>
<RunSynchronousCommand wcm:action="add">
<Description>Lite Touch PE</Description>
<Order>1</Order>
<Path>reg.exe add "HKLM\Software\Microsoft\Internet Explorer\Main" /t REG_DWORD /v JscriptReplacement /d 0 /f</Path>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
<Description>Lite Touch PE</Description>
<Order>2</Order>
<Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
</RunSynchronousCommand>
</RunSynchronous>
</component>
</settings>
</unattend>
5. Update the Deployment Share and choose for Completely regenerate boot images

PXE Boot issue on UEFI devices
PXE boot on UEFI devices may stop your PXE attempt at “Starting PXE over IPV4”. This is a known issue that can be resolved by disabling NetBIOS over TCP/IP.

1. Open Network and Internet Settings on your MDT server
2. Click on Change adapter options
3. Open properties of your network adapter
4. Open Internet Protocol Version 4 (TCP/IPv4)
5. Click on Advanced and navigate to WINS
6. Disable NetBIOS over TCP/IP under NetBIOS Setting
   

   Disable NetBIOS over TCP/IP to prevent PXE boot issues

Enable Bitlocker waiting for activation
Enabling Bitlocker and storing the recovery key in your Active Directory is a default step in the Task Sequence of MDT. The task sequence was completed successfully, but the recovery key was not stored in Active Directory.

“Bitlocker waiting for activation” is displayed when checking the Bitlocker encryption status on the recently installed client. This error occurred due to a pre-check failure in the Enable Bitlocker Task Sequence step.

ZTIBDE.log is showing following error:
FAILURE: False: Verify %OSSKU% is defined. The “verify %OSSKU% is defined

You must remove the pre-check of this Task Sequence step in order to successfully activate Bitlocker Drive Encryption:

1. Open your Deployment Share data location on the MDT server
2. Navigate to the Scripts folder
3. Copy ZTIBde.wsf to a backup location, just in case
4. Edit ZTIBde.wsf
5. Search for the section below and completely remove it'//---------------------------------------------------------------------------- '// Check to see if BDE is supported in this OS '//---------------------------------------------------------------------------- '// Check to see if we are running Vista or later and exit if we are not '//If iOSCVMajor < 6 Then '//oLogging.CreateEntry "Bitlocker is not supported on this version of Windows", LogTypeInfo '//Main = iRetVal '//Exit Function '// Check to see if the SKU supportes Bitlocker '//ElseIf not oUtility.IsHighEndSKU then '//oLogging.CreateEntry "Bitlocker is only supported on Windows Enterprise or Windows Ultimate or Windows Server", LogTypeInfo '//Main = iRetVal '//Exit Function '//Else '//oLogging.CreateEntry "We are running a OS that supports BitLocker", LogTypeInfo '//End if
6. Save ZTIBde.wsf and re-run the task sequence; now Bitlocker will encrypt and store the key in Active Directory.

Creating Reference Image Execute Sysprep failed
Creating a reference image, including the latest Windows Updates and custom applications, was running fine until the Sysprep step. Sysprep constantly crashed with the following error: FAILURE ( 6192 ): ERROR – Sysprep did not complete successfully.

It took me a couple of days to find the cause of this crash due to the lack of proper error details in the logfiles.

I’ve been using a custom NIC for my VMWare client (VMXNet3) to improve network performance. The VMXNet3 driver is injected in the early stage of the task sequence.

Sysprep removed the injected driver and was therefore not able to sysprep the reference image. The issue was resolved after using the default VMware E1000 NIC, which is available in WinPE.

Creating Reference Image on UEFI “can not find script LTIBootstrap.vbs”
The following error appears only on UEFI VMs at the execute sysprep step when sysprepping and capturing within VMware. This does not happen on legacy BIOS VMs.

The task sequence should reboot and get back into WinPE, but it is booting back into Windows. This bug is caused by a pending Windows reboot. The sysprep step will reboot the VM, but MDT already set up the VM to reboot into WinPE, so the pending Windows reboot is still there.

This error can be fixed by adding a Restart Computer step just before the Imaging step in State Restore.

Loading time .WIM file through PXE
Loading the Litetouch.WIM file through PXE used to take approx. 1 minute. From one day to another it started to take up to 3.5 hours to load.

This issue has been resolved by disabling Variable Window Extension and setting a maximum block size in Windows Deployment Services (WDS), by default this was set to 0 in my WDS settings:

1. Open WDS
2. Open your WDS server properties
3. Navigate to TFTP
4. Set Maximum Block Size to 16384
5. Uncheck Enable Variable Window Extension
   

   Set the maximum block size and uncheck Enable Variable Window Extension to resolve slow loading of the WIM file

Secure Boot issue on Server 2022
Microsoft’s KB5022842 will break Secure Boot of Windows Server 2022 hosted on VMware ESXi 6.7 U3 or VMware ESXi 7.0.X. VMware patched this issue on ESXi 7.0 U3.

KB5022842 will prevent Windows Server 2022 from booting. Microsoft has released a new update on March 14 (KB5023705) that resolves this issue. A workaround if you can’t install KB5023705 is to disable secure boot on your Windows Server 2022 VM.

Deployment failure on BIOS based systems
MDT Task Sequence fails on BIOS-based systems as the BIOS firmware is incorrectly identified as UEFI.

Error:
Failure (5616) 15299 Verify BCDBootEx
LiteTouch deployment failed, Return Code = 2147467259 0x80004005
Failed to run the action: Install Operating system
Unknown error (error: 000015F0, Source: Unknown)

Microsoft has patched this issue with KB4564442. Download the patch here:
https://download.microsoft.com/download/3/0/6/306AC1B2-59BE-43B8-8C65-E141EF287A5E/KB4564442/MDT_KB4564442.exe

Conclusion
MDT version 8456 in combination with Windows ADK for Windows 11 has its challenges. It may take time to set up, and you’ll be facing odd issues implementing MDT. I’ve listed all issues that occurred during my MDT installation and configuration in this blog.

Following task sequences have been deployed after resolving the issues described in this blog:

• Successfully deployed a Task Sequence on Windows 10 (BIOS and UEFI) and Windows 11
• Creating a Reference Image on Windows 10 (BIOS and UEFI) and Windows 11
• Successfully performed a sysprep and capture of a custom Windows 10 and Windows 11 client

If you want more information about MDT or have any questions, don’t hesitate to contact me at [email protected]