Run an MDT task sequence during Autopilot, revisited

In my previous post on the subject, everything worked well: I could take an MDT task sequence, package it up as an Intune Win32 app, and deploy it during an Autopilot provisioning process. After that, I moved on to installing Windows updates during the process, and that’s when things when wrong: after rebooting to complete the Windows update process, Autopilot and OOBE were completely broken, and the device was effectively useless. I worked around that by deferring the reboot until after the Autopilot provisioning process was complete, but it was still a mystery, especially since others weren’t seeing the same issue.

A short time later, Raymond Huis in ‘t Veld and I exchanged some messages, and he got to the bottom of the problem: It wasn’t the Windows update process at all, it was a side effect of the MDT task sequence: If anything initiated a reboot after the MDT task sequence executed, it would break the Autopilot process. It just so happened that I added the Windows update app after the MDT task sequence app, and that triggered the issue.

So what was the actual issue? The MDT LiteTouch.wsf script that drives the MDT task sequence contains some cleanup logic that removes the Autologon registry values. Guess what drives OOBE on Windows 11 after reboots? Autologon registry values, which cause Windows to automatically log back in as DefaultUser0 (with a randomly-generated password). Without those, OOBE is completely broken after any reboot process.

OK, so how do you fix that? Well, you have to keep MDT from modifying those Autologon registry values. The only simple way to do that is to modify the LiteTouch.wsf script to keep it from doing that. Given that there are two places in the LiteTouch.wsf script that touch the Autologon entries, that requires a couple tweaks:

• Disabling the LTICleanup.wsf execution.
• Setting the BootPE task sequence variable to “True”.

The MDTIntune.ps1 script has been modified to make those changes. With those in place, we can generate a new .intunewin file with the MDT media content:

Since that also addressed the issue seen with the UpdateOS script, I updated that too to change the default reboot mechanism back to using a “soft” reboot via a return code. I’ll create a new post for that one shortly.

So now everything works as expected.