Microsoft Deployment Toolkit

MDT build 8456 needs an update for Windows 10 2004

By on • ( 16 Comments )

There is a new update available for MDT to address an issue that arises from Windows 10 2004 and the corresponding ADK release:

https://support.microsoft.com/en-us/help/4564442/windows-10-deployments-fail-with-microsoft-deployment-toolkit

The issue would only be encountered if you are using non-UEFI devices (physical or VMs).  Due to a change in underlying API behaviors, MDT then could not determine if the device was booted using UEFI, so it interpreted the situation as “all devices are UEFI.”  There were some workaround posted, but those aren’t recommended as there are multiple places in the MDT process where the “IsUEFI” variable is re-calculated, so you can run into a variety of “gotcha’s.”

This update requires you to manually update the Microsoft.BDD.Utility.dll files in the MDT installation path (so it’s picked up for new deployment shares) as well as in all existing deployment shares.  As boot images contain these DLLs, you need to update those too (update them, update WDS, update your media, etc.).

Categories: Microsoft Deployment Toolkit

16 replies »

      • The directions for installing the update do not appear to be entirely correct. I did what was stated and after completely regenerating the boot image, the old version of the dll was still injected. In my case I have my deployment share on a different volume (D: drive) and MDT is installed on the c: drive I found it is actually injecting the DLLs from the x86 and x64 folders at d:\deploymentshare\tools. After replacing the DLLs at those locations and regenerating the boot images, the new DLL was present and the my issue was resolved.

        Liked by 1 person

  2. This is probably not directly related, but I spent my Sunday trying to troubleshoot DISM that came with latest ADK for 2004 built. I need to vent. 🙂 .
    It appears that DISM /SPLIT-FFU feature doesn’t work. And even dism /split-ffu /? output provides inconsistent information. In the example for ‘DISM /SPLIT-FFU’ it shows “DISM.exe /SPLIT-IMAGE …”.

    There has to be a bug in DISM.exe, right?

    Like

  3. it feels like it is much easier to capture a custom company image as a single FFU with all partitions including WinRE rather than dealing with WIM files and scripts to create separate partitions on target computers. The bug is not with the documentation. The DISM /SPLIT-FFU feature doesn’t work period.
    It might have been designed for the phone, but it is pretty well documented by Microsoft official docs as a way to capture and apply Windows 10 images – https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/wim-vs-ffu-image-file-formats

    Like

    • Not a fan of sector-based images as they aren’t very flexible. Not sure why it’s broken though. I don’t see any bugs about it, so best to open a support case.

      Like

  4. Given the time consuming nature of building a new MDT server with 75 packages, drivers and scripts, do you think it’s more efficient to copy packages from a server running MDT version 6.3.8450, deploying 1709, to a server running MDT version 6.3.8456, deploying 1909? Or should we upgrade the existing servers MDT\ADK\ADKPE \WISM? Both servers are 2016.
    Thanks,
    RG Small

    Like

    • Personally, I’d upgrade it in place by installing the new ADK and MDT versions. Have a good backup of your deployment share just in case. The 8450 to 8456 upgrade is fairly minor overall. If you’re really paranoid, ROBOCOPY the entire deployment share to the new server and then install the new versions on the copy (you’ll need to tweak CustomSettings.ini and perhaps a couple of other configuration files with the new UNC), using the old server as a backup.

      Liked by 1 person

  5. Hi,
    Thank you for your post … and comments (because we have to copy the dll twice.

    I have a problem with WSUS with the new ADK, all updates found are tagged SKIP in my Build task.
    Start Search…
    SKIP – f36bfc14-dc6c-48eb-a76e-c21828bb4ff6 – 2020-06 Mise . jour de s.curit. pour Adobe.Flash.Player sous Windows 10 Version 2004 sur syst.mes x64 (KB4561600) – 21 MB
    Scan complete, ready to install updates. Count = 0
    Do you enabled these step in your build task ?
    Do you verify it ?

    Thank you for your help.

    Ludovic.

    Like

    • We did investigate this and determined that the updates are defined with a “user input required” attribute set, so MDT skips them (since prompting for user input would potentially hang the task sequence).

      Like

      • Thanks Michel!
        I have struggled with my MDT installation to create updated wim’s for deployment of updated stand alone klients. Now I know i don’t have to find where it goes wrong when the update, that worked fine with 1909, is skipped when using 2004.
        Will this be fixed, will MDT update my installation automatically in a near future?

        Like

      • We are trying to get Windows Update to fix the issue. But if you want to work around it, you can change the ZTIWindowsUpdate.wsf script. Look for these lines and comment out the middle one:

        If item.InstallationBehavior.CanRequestUserInput then
        bInstall = FALSE ‘ Do NOT install anything that can Request User Input!
        End if

        Like

  6. That worked like a charm. Thanks a lot Michael.
    Run the task sequence without any problems at all.

    Like