Due to code changes in Windows ADK 10 v2004 the MDT utility (Microsoft.BDD.Utility.dll) that detects BIOS or UEFI firmware types no longer works correctly, and detects BIOS-based machines as UEFI-based machines.
Update June 3, 2020: Microsoft released a hotfix for this issue. Basically a new version of Microsoft.BDD.Utility.dll: With this hotfix you don't need the below workaround: https://support.microsoft.com/en-us/help/4564442/windows-10-deployments-fail-with-microsoft-deployment-toolkit
Note: This issue happens for ConfigMgr (SCCM) too, but has been addressed in the HFRU for ConfigMgr 1910, as well as in ConfigMgr 2002. Also Windows 10 v2004 has this code change (see Symptom #2 later in this post).
Symptom #1
Bare metal deployments will fail with the following error:
FAILURE ( 5616 ): 15299: Verify BCDBootEx
Litetouch deployment failed, Return Code = -2147467259 0x80004005
Failed to save environment to (80070057)
Symptom #2
Not related to ADK 2004, but the same code change was done in Windows 10 v2004 too. The Apply Windows PE (BCD) action may fail during build and capture of a Windows 10 v2004 reference image, and cause either the following error after reboot, or just an endless loop showing "Loading files…":
Status: 0xc0000001
Info: An unexpected error has occurred
The Fix
Until an official fix is available, this temporary workaround gets the job done. Simply copy the below script to your deployment share scrips folder, and add it to your standard client task sequence in two locations:
- #1 Prior to the actions that formats the drive in the Preinstall / New Computer only node.
- #2 After the Apply Local GPO Package action.
Note: If using the separate sysprep and capture task sequence instead of a build and capture task sequence, add the script after the Set Phase action (see screenshot further down in this post). Thanks Sean Smith for providing that info.
https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/FixUEFIDetection.wsf
Name: Fix UEFI Detection
Command Line: cscript.exe "%SCRIPTROOT%\FixUEFIDetection.wsf"
Troubleshooting
The script creates its own log file: FixUEFIDetection.log that can be used for troubleshooting. Or, simply add a pause before the script runs in the task sequence, and run it interactively via F8. Here is what I use to pause a task sequence (to resume, just exit the command prompt):
Action: Run Command Line
Name: Pause with Command prompt
Command Line: cmd /c start "cmd" /wait cmd
I had the issue persist after the hotfix as well, might be for a couple of reasons…using an SSD that was previously UEFI maybe tripped up MDT? And a workstation so old the SATA mode can only be ATA, not sure. But using this workaround resolved it for re-imaging these older systems with new life via an SSD. Thanks heaps.
Using S2019 with MDT 6.3.8456.1000, migrated from a working 2012R2 setup.
Hi All,
The fix given in Symptom #2 got fixed after including the Fix UEFI Detection step as mentioned in the fix. I had the same issue in Windows Server 20222 image capture task sequence. It works for me!
Thank you so much! Even with Microsoft's 'hotfix', I was still experiencing the boot-loop issue (symptom #2). After adding the 'FixUEFIDetection.wsf' script to the first and second locations (as you described) in the task sequence, the boot-loop issue was resolved. I've been configuring MDT on a variety of host OSs, ADK versions, MDT versions, and there always seems to be an endless barrage of issues (resolve one error, and on to the next one). Microsoft deserves to be chastised on releasing half-ass 'solutions' such as this, and you deserved to be thanked. Typical Microsoft problems where they can't get their… Read more »
Thank you very much. I have been looking for the source of this problem for over a week. Thanks again!!
Tack för lösningen!
This is still a bug in the latest ADK.
Hi Scott,
Yes indeed. Thanks for the update.
Peace to all of you,
I had the same issue. I have created a base windows 11 image using on task sequence. Created a second task sequence to capture the image after I have installed company apps
The virtual machine gets stuck at loading files.
Turn off the VM (reference machine I wanted to capture) edit settings and had it start using the LiteTouchPE_x64.
Start the VM machine and it automatically continued the process of creating a wim file
Hello,
I would like to thank you for your help.
All my problems have been resolved!
System admin from Paris
Hey Johan, thanks for the very informative article and for updating it with the hotfix information. I, too, was wracking my brains why I kept seeing a "Formatting UEFI" message on BIOS boot machines. Even after re-generating the boot image in the MDT console. Then it dawned on me: A reminder for those who use WDS to boot over the network– Please also import the boot image into WDS. WDS does not pick up the newly-generated boot image from MDT, obviously. 🙂
Good catch, and thanks for sharing it
/ Johan
thanks! needed this fix even with the hotfix. Not for all devices, but some new specialized laptops (kano).
Hello Johan, I've hit a snag trying to deploy Win10 (20H2) build to a Dell OptiPlex 7070. We are running MDT 2013 and ADK 2004 and the WinPE add-on 2004. I installed the UEFI MDT patch. I have the latest Dell driver .cab imported to the server. I've updated the deployment share and re-generated the boot images at least 3 times. The image deploys fine and after the first reboot, the task sequence fails to resume with the error Unable to find definition file:BDD_WelcomeZ_ENU.xml. I've attached a screenshot of the error. Once I hit ok, it bumps me out to… Read more »
I haven't seen that specific error, but MDT 2013 is definitely not supported to deploy Windows 10 20H2. You will probably have better luck with MDT 8456 + the BIOS/EUFI.
I would recommend spinning up a separate VM, install MDT 8456 with hotfix, and ADK 2004 with ADK 2004 WinPE Addon. Create a new deployment share, and see if the problem goes away.
/ Johan
Hello Johan. I've worked IT for 30 years but only recently stood up a WDS/MDT server for the first time and hit this bug. I applied the MS patch but the problem persisted. So I backed that out and applied your fix. My deployment get through the first stage now but then I have an unbootable disk. Any thoughts on where I went wrong?
As long as the deployment share have the real hotfix, and you have re-generated the boot image there is no need for my intermediate fix. Please reach out to me on LinkedIn (I'm easy to find), and I can follow-up with you offline.
I have the same problem. After first reboot no boot device found. Partitions are created correctly. With real hotfix detection doesn't work correctly and it is still detecting UEFI true
I have not seen that, but at the same time, I do very little BIOS-based deployment these days. More or less every computer is setup for UEFI. If the temporary workaround fixes the problem, great, but it would be amazing if you could file a bug with Microsoft, so hopefully fix the problem the proper way.
/ Johan
Thank you for respond. i see what can i do. problematic computer is hp 6000 pro sff. i dont have much time to solve this right now, because start of semester
this pc – oldest classroom: https://support.hp.com/us-en/document/c01865797
Guys I am having almost the same problem, I am unable to capture a 20H2 image using Hyper-V with the latest MDT and ADK+WinPE. the process went fine but stuck in a loading file boot loop.
I have successfully captured a 20H2 image via the build and capture task sequence. Make sure you added the hotfix files to both the MDT installation directory, as well as your deployment share(s). You also need to re-generate the boot image(s).
/ Johan
Hi Johan, thank you for the solution, I tried using the script and it didnt work for me. Here is the error I got. Failure Litetouch deployment failed, Retum Code -2147467259 Ox8000400S Failed to run the action: Fix uEFl Detection. Incorrect function. (Error. 00000001: Source: Window•s) The execution of the groik (Preinstall) has failed and the execution has been aborted. An action failed. Operation aborted (Error. 80004004; Source: Windows) Failed to run the last action: Fix UEFI Detection. Execution of task sequence failed. I saw from comments that there is a hotfix for MDT fixes the issue. Can someone provide… Read more »
The error you see are most likely from a typo in the command line in the TS. Please provide a screenshot, with that action selected.
But, its indeed better to use the now available hotfix which you find here: https://download.microsoft.com/download/3/0/6/306AC1B2-59BE-43B8-8C65-E141EF287A5E/KB4564442/MDT_KB4564442.exe
Quality Microsoft QA work with recent MDT releases. First WISM needed a slapdash hotfix, now BDD breaks in 8456. What's next, a hotfix to be able to properly partition and format a disk?
Thank You for the solution!!
Sweet jeebus, thank you for this! Been banging my head against the wall for the better part of a day figuring I had screwed up somewhere.
Working for me now with the June 2020 Hotfix. Thanks for posting this
Thanks for confirming
Genius, thanks ever so much.
Fantastic stuff. I've been pulling my hair out here – I found your post early on but the hotfix was out. Applied that and updated the deployment share. No luck! That's after forcing a MBR (BIOS only) step in the task sequence. I have lots of old BIOS machines so can't manage with UEFI only.
I kept coming back to the same few posts online. In the end, tried with your script in there too, and it's progressed!
Perhaps I've not installed the hotfix correctly? It's straightforward but maybe December has taken its toll on my brain.
The hotfix need to be added to all deployment shares, and the boot image(s) will have to be updated. If you are still struggling, reach out to me on LinkedIn, and I'll see what I can do to help.
Just wanted to say thanks for this.
Had this issue today when imaging some older laptops. Saved me a lot of time
Thanks Johan, this script fixed it for me.
I am deploying Server 2016 DataCenter GUI with Litetouch. However the fix doesn't work. Would you know why?
I have applied the fix to the server 2019 task sequences and they are working.
That's a bit odd, since for Windows Server 2016, the hotfix from Microsoft only applies to WinPE. Drop me a message on LinkedIn, and I'll follow up with you offline.
thank you so much!!
We skipped v2004, and I found this post when I ran into this problem building the image for v20H2. I first applied the hotfix from Microsoft, and it still detected my Generation 1 Hyper-V VM as UEFI. I undid the hot fix and tried your fix, it failed as well.
I ended up manually setting the IsUEFI Task Sequence Variable to False. That got me past the first stage, it formatted BIOS correctly, but after sysprep, it did that loop thing.
So I added the Set Task Sequence step right before Imaging, just like your script call.
Thanks for the update. I've been quite successful with the UEFI hotfix for 20H2 deployments. Just remember that it needs to be added to both your deployment share (not just the install directory), and also the boot image.
I have just run into this issue trying to create a reference image for Win 10 20H2. I've used MS hotfix to replace the DLLs in both the deployment share and regenerated the boot images, but I am still in the reboot loop.
I will try Rob's suggestion and see if that works.
Thanks Johan your fix worked for Win10 v2009 Image capture! Please keep up the good work, a very valuable resource for OSD folks. 🙂
Hello Johan,
What Drivers do you usually use for your reference image?
Hi Kendall,
I don't add any drivers to the reference image. They are injected at deployment time.
So I applied the hotfix, but seems like it made it worse in my case. Before the hotfix I had to mount my capture iso and boot from that when I wanted to capture, was caught in a loading loop otherwise, after the hotfix instead of rebooting before going into PE and capture my VM bluescreens and reboots, getting into the error that something went wrong and I should reinstall the OS. Followed the guidelinkes from the link to see if I missed something, but followed it like it were described.
The hotfix is just an update of the utility dll and should not affect that as long as you update that iso. That being said, I strongly recommend using a build and capture process, instead of a capture only process. Its so much more reliable.
Thanks for the link to the patch;)
You did not encounter a problem that on Vmware ESXi virtual machines during deployment refuse to see the hard drive … even if you integrate the drivers into WinPE Boot Image through MDT?
I tried different versions of SCSI controllers, HDD does not help anything. There were no such problems on WinPE Windows 8.1.
I have not seen any issues like that in VMware ESXi. What ESXi version are you on, and what guest OS did you setup the VM to use?
I found what was the problem. Is to upgrade the virtual hardware is not suitable. You need to create a virtual machine from scratch.
Hi Johan! I have been trying to do a build and capture of Windows 10 2004 with MDT 8456 and HypoerV, and with the help of this solution I was able to get it done, thanks!. BUT I noticed that when the Install Update step is running som updates are found, i.e Silverlight, and Windows Defender update, but all are set to be SKIP'ped in the log files…. Have you seen this behaviour and maybe have a clue on how to remediate it? I am updating towards Microsoft Update, and not using a WSUS server. Thanks!
Sorry, nothing I have seen
Hi Johan! No problem… I figured it out though. One way or another, it looks to me that Windows 10 2004 updates are flagged as if they are set up to Request user input…. So when I comment out line 298 in ZTIWindowsUpdate.wsf the updates are detected and installed as they are supposed to be…. What do you know 🙂
I apologize to all. I figured I would share the good news. Johan's script works great for captures if you place the script near the top of a standard "sysprep and capture" task sequence, within the "Capture Image" folder. I put his script below "Set Phase" task and above "Configure" task. Ran like a charm!!!! Thanks for the awesome fix! At this point, I guess the other posts are pointless.
Thanks for the update, I'm stealing you screenshot and will update the post. Obviously giving you credit for the find. Again, thanks.
Sounds good. Glad I could help and contribute.
Sorry…last post for now. The first attempt failed so I moved the task below "Apply Windows PE (BCD) and above "Restart computer". It errored out saying it was looking for a LTICleanup.wsf script file?
I took a stab at it and testing now. I also attempted to upload a screenshot, but it did not work out so well. I put your WSF code underneath "Capture Image" folder –> below "Execute Sysprep" and above the "Apply Windows PE (BCD)" task. I have a pretty vanilla capture and sysprep task sequence for reference.
Johan,
I am trying to capture a Win 10 2004 WIM, but not sure where the best place to put this script would be. Any guidance? I see that your screenshots are for deployment task sequences, but I never saw a capture and sysprep task sequence screenshot.
I never use the separate capture and sysprep task sequence so I didn't bother testing that one (sorry). I always used the full build an capture task sequence 🙂
Johan, you are simply the best. Thank you!
🙂 Thanks
Is it the same issue when deploying servers (2019 and 2016) with MDT and ADK 2004?
Windows Server 2016 and 2019 does not have the issue in full Windows, but the WinPE phase has the same issue.
Ran into this yesterday and been hunting for a fix, will give this a try – thanks!
In full OS after Gather step Microsoft.BDD.Utility.dll kicks in again and set IsUEFI = true
So if you build ref images on gen1 VM (BIOS) you also have to set IsUEFI = false in full OS
I did it with a powershell script:
Not sure if BIOS/UEFI detection is awesome but it works
$TSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$boottype = (Select-String 'Detected boot environment' C:\Windows\Panther\setupact.log -AllMatches ).line -replace '.*:\s+'
if ($boottype -eq 'EFI')
{$TSEnv.Value("IsUEFI") = "true"}
else
{$TSEnv.Value("IsUEFI") = "false"}
Thanks, I updated the script with similar logic to correctly detect UEFI/BIOS in full Windows.
Tack för lösningen Johan!
Great post – thank you – it saves me time