Monday, 30 October 2017 10:37

The Case of Mysterious MDT Boot Loop

Written by
Rate this item
(2 votes)

image

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

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.

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

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

Recent Posts