We implemented the Windows Autopilot for existing devices scenario with Windows 10 1809 to enable an interesting scenario:  Using ConfigMgr (or other deployment tools, e.g. MDT) to take an existing Windows 7 or 8.1 machine, wipe it, load Windows 10, and then take it through the Windows Autopilot user-driven experience (now supporting both Azure AD join and Active Directory Join).

To support this scenario, ConfigMgr includes a built-in task sequence template that performs the necessary steps.  You can create that using the built-in wizard:

The end result is a reasonably-simple task sequence:

Interpreting that, it means that the device boots to Windows PE, formats the drive, applies Windows 10, boots into Windows 10, then syspreps the OS and reboots.  After that reboot, there’s no more ConfigMgr or task sequence; Windows Autopilot takes over, reading the AutopilotConfigurationFile.json file (copied in the “Apply Windows Autopilot configuration” step) to determine the Autopilot profile settings (since the device isn’t registered with Autopilot).  Why boot into Windows 10, then immediately sysprep it and reboot into it again?  That’s to enable you to add other “stuff” in that first Windows 10 boot, e.g. applying patches, installing apps, etc. (If you aren’t doing anything like that, it’s rather pointless – see my Speeding Up blog for more details about that.)

Alright, so what’s the problem with Windows 10 1903?  There was a simple change in behavior related to Windows Autopilot:  When you run “sysprep /generalize”, the C:\Windows\Provisioning\Autopilot folder is deleted (on the premise that there’s no need to include that stuff in an image, which is why you would typically run “sysprep /generalize.”  So if that “Apply Windows Autopilot configuration” step copies the file and then the “Prepare Windows for Capture” step runs “sysprep /generalize” which deletes what you just copied, you can probably guess what happens:  Instead of going through the Autopilot process, Windows 10 just boots into standard OOBE experience.  That’s broken.  (If you are already using the “Speeding Up” task sequence, you won’t run into this issue, because it doesn’t run “sysprep /generalize.”)

How do you know it’s broken?  If you see this screen in OOBE (or any other screen that you have disabled in the Windows Autopilot profile), then you know the JSON file isn’t working:

To work around this issue (again, if you are using Windows 10 1903 with ConfigMgr’s built-in “Windows Autopilot existing device” task sequence template), you can edit the task sequence to disable the “Prepare Windows for Capture” step and add a new “Run command line” step that runs “c:\windows\system32\sysprep\sysprep.exe /oobe /reboot”:

With that change in place, the AutopilotConfigurationFile.json file won’t be deleted, and then you should see the expected OOBE experience.  And as a side effect, you’ll find that the task sequence is now faster (by 20 minutes or more) because it doesn’t need to generalize and then specialize the OS.

So how do you know the change worked?  Instead of seeing a EULA screen, the device should boot up, have you choose the language, locale, and keyboard, and then go straight to the Azure AD authentication screen:

You could also check (if you are paranoid) that the AutopilotConfigurationFile.json file is present in the C:\Windows\Provisioning\Autopilot.  (Is it just me, or does it seem silly to anyone else that the file name says that it’s a file?  Isn’t the pretty obvious already?)

We’re looking at other possible permanent changes to address this, but until then this workaround should work fine (and save you time).