---

UPDATE 02/11/2020: It has been a while but today this Microsoft case has been closed. After a lot of testing a digging around the earlier update I posted didn’t seem to work, as the ConfigMgr client wasn’t fully removed. So offline Autopilot did work but when Azure AD Joining the device I noticed that my client still had a ConfigMgr agent on the device (while I did run the step ‘Prepare Config Manager Client’ step… the result within Microsoft Endpoint Manager (aka Intune) is shown below.

This prevented the OOBE from continuing and in the end it showed me an error during the first step in ESP. If you hit this issue, there is a simple resolution, instead of running the default steps provided within ConfigMgr, you can run the PowerShell script below as the latest step in the task sequence which will ‘in one go’ uninstall the ConfigMgr client and execute a sysprep without the generalize cmdlet. This first of all speeds up the sysprep action, but more important won’t remove the offline autopilot file.

#Uninstall SCCM Client Variables
$UninstallPath = “C:\Windows\ccmsetup”
$UninstallerName = “ccmsetup.exe”
$UninstallerArguments = “/Uninstall”

#Uninstall SCCM Client action
Start-Process -FilePath “$UninstallPath\$UninstallerName” -ArgumentList $UninstallerArguments -Wait -PassThru

#Remove register key
$registryPath = “HKLM:\SOFTWARE\Microsoft\DeviceManageabilityCSP”
Remove-Item $registryPath -Force

#Sysprep Variables
$sysprepPath = “c:\windows\system32\sysprep”
$sysprepName = “sysprep.exe”
$sysprepArguments = “/oobe /reboot”

#sysprep execution
Start-Process -FilePath “$sysprepPath\$sysprepName” -ArgumentList $sysprepArguments

The above has been confirmed fully supported by Microsoft as you also don’t make any changes to the generalize.xml sysprep file.

Now if you want to wait until Microsoft comes with a fix there is news! And more important you actually don’t have to wait that long as this fix is currently in development for 1903 as well as 1909. This fix will include a change in the sysprep process which will actually skip the removal of the autopilot file (and if you’re using the insider build you can already see this in your generalize.xml file that the offline autopilot directory ins’ t wiped anymore).

I hope this latest update will bring you a better 100% supported solution and save you from a lot of headaches which I had :-).

---

Microsoft has released Windows 10 1903 for a while now and we’re seeing that customers start moving their ‘clean’ Modern Workplace deployments from 1809 to 1903 within MDT or SCCM. This is a good sign as there were a some bugs within the autopilot phase starting with the first release of Windows 10 1903 and luckily these are solved with the latest Windows 10 updates.

There however can also be a big change in the deployment when you are using MDT or SCCM to deploy your new Modern Workplace image to existing computers which aren’t yet known with Autopilot. You will face this change in behavior when you’re using an OSD which deploys the operating system within Windows PE with the autopilot json file, restarts in Windows 10, installs applications and other tasks which you want to execute and ends with a Sysprep action.

In any normal circumstance you would expect Windows 10 to load the autopilot profile from the offline JSON file which we uploaded during the OSD, however within Windows 10 1903 the sysprep process will cleanup these files, this behaviour is correct and expected within 1903 as this was confirmed a bug within 1809 by Microsoft.
In the images below I’ve marked the differences between the two generalize.xml files related to Autopilot the first image is from 1809 and the second one is from 1903 (I was quite surprised when I compared the files and noticed that the structure and the sorting was completly changed within the 1903 version.

As you can see in the second image four lines have been added within the generalize.xml of Windows 10 1903, which triggers sysprep to remove the autopilot profile which you have put into the C:\Windows\Provisioning\Autopilot folder during OSD, basically it’s undoing the file copy. I took me a lot of headaches before I noticed it was the actual sysprep process which was causing this as it was working within Windows 10 1809. Now I did knew what was causing it I realized there were two solutions.

Solution #1:
When the OSD is only using WinPE and won’t boot into Windows (meaning no app installation and other settings by the ConfigMgr agent) the Autopilot profile can be copied. After the Windows system has been installed during WinPE and the autopilot file is copied not sysprep action is executed and therefore the file will stay. Michael Niehaus has made a nice blog about this one last year: which can be found here: https://blogs.technet.microsoft.com/mniehaus/2018/10/25/speeding-up-windows-autopilot-for-existing-devices/

Solution #2:
So solution #1 was not applicable as within my situation I needed to pre-install applications like Office Pro Plus, Printix and some others to speed up the Out-of-box-experience in Windows 10. If I use Intune for the app deployments which we are doing during the OSD it takes more than an hour for the device to be fully installed and ready to use, therefore using an OSD with applications speeds up the whole process.
The next thing what came across my mind was using the SMSTSPostAction variable, which would copy the Offline AutoPilot profile to to the C:\Windows\Provisioning\Autopilot\ folder after the OSD and therefore sysprep was finished. The problem however with the SMSTSPostAction variable is that it cannot handle unexpected reboots of applications… lucky as I was some of the apps have unexpected reboots (like the fabulous HP Hotkeys :-)). So still no resolution, which got me thinking what if we can change the sysprep process to only skip the removal of the Autopilot files during the OSD the problem is fixed! At that time I had no idea that the command: sysprep.exe /generalize /oobe /shutdown was refering to a generalize.xml file. But after a few minutes of digging I understood the process, opened the generalize.xml file and understood what was removing the autopilot profile during the sysprep process.
I opened the original generalize.xml file (which I retrieved via DISM) and removed exactly the text shown in the image below from the c:\windows\system32\sysprep\ActionFiles\generalize.xml file.

When finished I saved the file somewhere safe so it can be used in the next step within a ConfigMgr package, as now we need the generalize.xml file without the lines mentioned above to be copied over during the OSD same as we do for the offline autopilot profile. As you can see I used two steps, the first one which copies over the autopilot profile, the second once which replaced the sysprep Gernalize.xml file.

This will resolve the offline autopilot profile deployment issue for Windows 10 1903 when using an OSD deployment with applications etc.
Currently I still have a case open with Microsoft and I’ve asked if the solution above can be implemented within production and if it’s still a supported scenario, once I have feedback about that point I will update this blog.