Monday, 30 October 2017 10:37

The Case of Mysterious MDT Boot Loop

Written by
Rate this item
(4 votes)


I haven't blogged the last couple of days because I was busy answering questions on TechNet. A couple of posts ago I talked about the importance of spending some quality time on TechNet as it may bring interesting cases to your attention. Today, I would like to highlight one of these cases in hopes that someone from the Microsoft Deployment Toolkit Team team is out there listening.

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...


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"
		TestAndFail RunBCDBootEx( sDestinationDrive & "\windows", " "), 5616,"Verify BCDBootEx"
	End if
End if


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.

Read 26216 times Last modified on Thursday, 02 November 2017 09:39

Recent Posts

  • Windows 10 21H2 Built-In Apps: What to Keep
    The development of the Windows 10, version 21H2 is finished and the update will soon be available for download from…
    Written on Wednesday, 20 October 2021 11:41
  • Group Policy Changes in Windows 10 21H2
    As Windows 10, version 21H2 update development winds down, Microsoft is now preparing for the final release of the Windows…
    Written on Wednesday, 20 October 2021 07:20
  • Group Policy Changes in Windows 10 20H1 Preview
    As Windows 10 Vibranium Update (20H1) development winds down, Microsoft is now beginning the phase of checking in the final…
    Written on Tuesday, 14 January 2020 04:51
  • An alternative ESU MAK Activation Solution
    This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s…
    Written on Wednesday, 04 December 2019 21:04
  • The Case of Missing UE-V Templates
    My customers often deal with unexpected Windows behavior and this case is no different. This particular one is especially interesting…
    Written on Tuesday, 03 September 2019 12:20
  • The Case of Changing Default Printer
    While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s…
    Written on Wednesday, 14 August 2019 20:36