It’s something that I hadn’t tried in a while: Capturing a custom Windows 11 image using MDT. But there were a few posts on Reddit commenting about challenges doing so, so I thought I’d try it. First off, you should make sure that you have MDT fully updated; Johan’s guide is a good start:
The main points from that:
- Make sure to use the Windows 11 24H2 ADK; don’t use the May 2022 Windows ADK for Windows 11 22H2 (build 10.1.25398). There was an update released this month for the 24H2 ADK, so using that new version (build 10.1.26100.2454) is good. (I went through this whole process with both the 10.1.26100.1 and 10.1.26100.2454 ADK/Windows PE versions, both worked fine.)
- Make sure you’ve applied the MDT 8456 hotfix. See https://support.microsoft.com/en-us/topic/windows-10-deployments-fail-with-microsoft-deployment-toolkit-on-computers-with-bios-type-firmware-70557b0b-6be3-81d2-556f-b313e29e2cb7. That replaces the Microsoft.BDD.Utility.dll so it is able to properly detect UEFI. (There was a change in Windows PE that required additional rights to do this; the modified version enables those rights.)
- Edit or replace the Unattend_PE_x64.xml file in the C:\Program Files\Microsoft Deployment Toolkit\Templates folder. See the changes in this example: https://github.com/DeploymentResearch/DRFiles/blob/master/Scripts/Deploying%20Windows%2011%2024H2%20Using%20MDT/MDT%208456%20Fix%20for%20Windows%20ADK%2022H2/Unattend_PE_x64.xml.
- Make sure you have a “dummy” x86 folder structure so that MDT doesn’t generate an error when trying to access x86 (which is no longer supported with Windows 11 — it’s 64-bit only).
A few general tips that I would add:
- Use a Hyper-V UEFI (Gen 2) VM for doing this so you can avoid the need for injecting extra drivers, and allocate a full 4GB to the VM without using dynamic memory (since Windows PE can struggle to initialize with small amounts of initial RAM).
- Don’t enable BitLocker or any other encryption mechanism when building and capturing an image (unless you like frustration).
- Expect the image to get bigger. Even if you change nothing (no apps, no updates, etc.), it’s likely that the resulting WIM file will grow by at least a gigabyte over the source WIM that you started with. If you’re going through this exercise just to get the latest patches installed, grab the latest monthly ISO from https://my.visualstudio.com (requires a subscription) because it’s faster and easier, and Microsoft goes through more effort to get the image as small as possible (which is still quite large, over 4GB).
- Don’t modify the unattend.xml to use CopyProfile. Microsoft doesn’t do much (if anything) to test it, so over time it seems to cause more and more issues — find another way to customize the user profile, ideally when you deploy the image, not before you capture it.
OK, so what else can go wrong? Two common issues:
- New UWP/MSIX apps or app updates are installed. Sysprep will fail if there are any apps installed that aren’t also provisioned in the OS; the root problem is described at https://learn.microsoft.com/en-us/troubleshoot/windows-client/setup-upgrade-and-drivers/sysprep-fails-remove-or-update-store-apps. That can happen from store updates (if the machine is able to access the internet and is online long enough to detect updated apps) or from Windows updates that add apps, e.g. the Copilot app that Johan’s blog points out.
- Pending file deletions. I’ve seen this happen more than once in my own VMs: something (an update, an app, Windows itself, hard to say) tries to delete an in-use file and can’t, so it creates a registry entry to cause the file to be deleted on the next reboot. The LTISysprep.wsf script detects this and automatically reboots the computer, which should take care of that. But there’s a bug in the LTISysprep.wsf script that causes the staging of Windows PE to fail after that reboot because the system (boot) volume no longer has a drive letter attached and the script doesn’t re-add that drive letter.
Johan’s post addresses the first item if the only updated or new app is the Copilot app (which will happen if you use 24H2 media updated in November or later), but if you are unlucky (something that gets more and more likely the longer your task sequence runs, assuming your device has internet access to communicate with the store) you could run into more apps that cause the same problem. You can check the C:\Windows\system32\sysprep\panther\Setupact.log to see what app is causing the problem, then add it to the PowerShell script that Johan specified. (I have cheated in the past and just removed all apps from the built-in Administrator account using “Get-AppxPackage | Remove-AppxPackage”, but that’s probably not the greatest idea overall. And it’s surprisingly hard to write a PowerShell script that says “check all installed apps to see if they are newer than the provisioned apps.”)
So how do you address the second issue above with pending deletions? Notice that Johan’s example task sequence has a “Restart computer” step after the script that removes the Copilot app:
In most cases, that should also take care of processing those deletions.
So here’s what my edited task sequence looks like:
I didn’t add the “Suspend” step because I didn’t need to do anything manually. (If you are thinking about manually setting up the OS and then running a “Sysprep and Capture” task sequence, I wouldn’t recommend it — that encourages bad habits. Minimize or eliminate the manual tasks, and use the LTISuspend.wsf script to pause the task sequence so you can do any required tasks. And I’d typically suggest having the app removal and reboot steps after the suspend step, just in case your manual activities either cause an issue or cause a delay that lets other things get updated.)
And the final result (with those warnings coming from Windows PE trying to connect to the deployment share before the network was ready, not a fatal issue since it retried and succeeded):
Out of Office Hours 