A few days ago, I came across a thread on the MDT forum in which a user detailed issues with USB-based installations utilizing what I consider – not surprisingly given my history - the best free deployment solution for Windows 10, Microsoft Deployment Toolkit. On some systems, after layering down the image and completing the processing of the Post-Install phase, MDT would initiate a reboot and then end up in Windows PE again.

The user verified BIOS settings, ensuring that Windows Boot Manager was set to be the first boot device. He then looked at the BDD.log but didn't see any clues. Figuring that perhaps the BIOS firmware might somehow be the cause of the problem, he updated the firmware on all models experiences issues, but that didn't fix the problem either. He went through a couple of additional troubleshooting steps, including updating drivers, testing different USB sticks and even using vanilla Windows 10 image. With troubleshooting options exhausted, that left either MDT 8443 or some general ADK 1703 issue to blame.

The next step, therefore, was to engage Microsoft Premier Support. After several weeks of looking into the issue, the support team provided a workaround and told the user to modify the LTIApply.wsf script and to remove the optional parameter which specifies the UEFI firmware type on a GPT-based system. Crossing his fingers, the administrator modified the script as showcased below...

Before:

If oEnvironment.Item("OSCurrentVersion") <> "" then
	oUtility.GetMajorMinorVersion( oEnvironment.Item("OSCurrentVersion"))
	If ((oUtility.VersionMajor = 6 and oUtility.VersionMinor >= 2) or oUtility.VersionMajor >= 10 )then
		TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " /s " & left(oBootDrive.Drive,2) & " /f UEFI"), 5616, "Verify BCDBootEx"
	Else
		TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " "), 5616,"Verify BCDBootEx"
	End if
End if

After:

If oEnvironment.Item("OSCurrentVersion") <> "" then
	oUtility.GetMajorMinorVersion( oEnvironment.Item("OSCurrentVersion"))
	TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " "), 5616,"Verify BCDBootEx"
End if

... ran a deployment and to his immense satisfaction, the issue was gone. As to why the issue occurred remains a mystery to this day. Most likely it is related to computer's firmware because the alteration of the LTIAppy.wsf script doesn't do much: according to Microsoft's documentation, BCDBoot.exe defaults to UEFI on UEFI/GPT-based systems and creates the \Efi\Microsoft\Boot directory and copies all required boot-environment files to this directory anyway.

Anyone from Microsoft Deployment Toolkit product team out there?

Update: I followed up with Michael Niehaus on this issue. According to him, a new MDT update will be released soon containing the fix (and others), based on feedback from the Windows boot team. The root cause appears to be a combination of how vendor's firmware and MDT interact. Changes are based on engineering recommendations and the product team has verified that they work.