UPDATE 01/10/2019: I just got back from my holiday and I got confirmation back from Microsoft support that there is a better workaround for this issue. This means that if you followed the steps which I described earlier in this blog post the following step are required to improve the sysprep behaviour.
First of all make sure that the step to copy the Generalize.xml is disabled as you can see in the picture below.
The next step would be to disable the ‘original’ Prepare Windows for Capture task and to create a new ‘Run Command Line’ taks with the same name and which will run the following command ‘c:\windows\system32\sysprep\sysprep.exe /oobe /reboot’.
All of the above steps will make sure that the offline autopilot profile won’t be removed during the sysprep process, even better, it will improve your task sequence with about 20 minutes!
Again Microsoft is telling us that this is not the final solution so again it’s a workaround it’s however fully supported as I was told by Microsoft Support.
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.
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/
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.