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).
Categories: Windows Autopilot
Hi Michael, did you ever try to logon to the logon page shown above? I’ve changed my task sequence, however it looks like the device is recognized as co-managed and therefore not able to do the MDM steps / AAD Join, the prepare configmgr step is still there which uninstall the agent, so maybe it’s related to some registry settings which aren’t removed by bypassing the generalize.xml step?
The original OS was Windows 7, so no co-management and no issues joining and signing in.
We are currently looking to move from SCCM managed workstations to Intune management via autopilot. I’m wondering if we can use this task sequence to get the drive wiped, OS upgraded and then setup for Intune via autopilot but without any SCCM client on the workstations after the reimage?
Basically, I see “Setup Windows and Configuration Manager” and “Prepare Configuration Manager Client” steps in the task sequence near the end, can these be modified to not actually install the SCCM client? I’m hoping to have a purely Azure managed machine at the end, SCCM is just used to kick off the task sequence, prepares the drive and copies the require JSON file.
That’s effectively what the “Windows Autopilot for existing devices” task sequence (and the one that I published to “make it faster”) does. ConfigMgr puts Windows 10 on the device and sets it up to boot, but then it gets out the way and lets Autopilot provision the device.
Follow up question. Once this process is run through and say a machine is solely being managed by “Autopilot for existing devices” process, will that machine from then on be recognized as owned by that Azure tenant? Similar to how if you had imported the machines hash for a white glove deployment? Is it now “registered” with your intune subscription so subsequent reimages will be auto-piloted?
Thanks, trying to wrap my head around the process to see if it can work for us. 🙂
LikeLiked by 1 person
You should enable the profile option to “Convert device to Autopilot” and make sure the device ends up in a group that has that profile assigned. When Intune sees the device is in a group that has a profile assigned, it will reach out to the device, grab the hash, and register the device with Autopilot, then assign the profile to it.
Has anyone used autopilot to reimage an existing machine, on a different domain?