MDT image capture fails when there are pending file renames

A bug in MDT? Yes, and it looks like it’s been there for a while (going back to Windows 8 at least). Here’s the basic scenario:

• Use a standard client task sequence to install Windows 10. In my case, I used Windows 10 20H2, and made absolutely no task sequence customizations — just recapturing the exact same OS image that I laid down.
• Specify to capture an image.

In this scenario, there can be pending file renames that are noticed by LTISysprep (for a printer driver and “legacy” Edge update in my case):

Since those can cause sysprep issues, the LTISysprep script initiates a reboot to clear those up, then it runs again without any issues. But the next step in the process is to finish setting up Windows PE:

Hmm, so what happened here? Well, the first “Apply Windows PE” step staged the Windows PE boot files on the FAT32 boot volume (UEFI system). At that point, it had drive letter E: assigned to that volume. But when LTISysprep rebooted the system, that drive letter assignment disappeared, so the drive letter was no longer valid and the BCDEdit command failed.

So how do you fix this one? Option #1 is to just insert a reboot step before the first “Apply Windows PE” step, to clear up any pending file rename operations before LTISysprep notices (and hope that some of them don’t come back, because LTISysprep could still find one or more after the reboot, but it has logic to reboot at most once because those recurring stragglers won’t cause any issues).

Option #2 is a little more involved: Get LTIApply to re-assign the drive letter. That requires making a script change, moving this logic:

to a location a little higher, above the “if” statement:

The frustrating part of this: It’s an inconsistent problem, because you won’t always see pending file renames — sometimes there are none and everything works great.

So what’s the reason for this particular split anyway, having two LTISysprep steps? Well, back in earlier Windows releases you could run sysprep.exe and still have network access to grab the Windows PE files, but at some point that changed (I believe with Windows 8). So, the first step makes sure all the files are copied locally to their correct locations, then the second LTISysprep execution just does the BCD edits. But there is one other reason too: Sysprep will fail if there are any BCD edits made that cause the currently-running OS to not be the primary one in the BCD. It’s always something. But in the process of making the needed changes to handle these scenarios, combined with the “pending file renames” logic, introduced this odd bug.