Sysprep change in Windows 10 1903 & Autopilot


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.

OSD Example for Offline Autopilot including application installation.

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.

Windows 10 1809 – C:\Windows\System32\sysprep\ActionFiles\generalize.xml
Windows 10 1903 – C:\Windows\System32\sysprep\ActionFiles\generalize.xml

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.

Lines to be removed from c:\windows\system32\sysprep\actionfiles\generalize.xml

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.

Offline Autopilot copy action
Replace generalize.xml to skip the autopilot profile removal after a sysprep.

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.

5 thoughts on “Sysprep change in Windows 10 1903 & Autopilot

  1. Erwin Klaver says:

    Hi Pim,

    Great article,

    If you use Windows 10 1909 the generalize.xml is also different from 1903. You have to remove the following:

    Like

    1. Pim Jacobs says:

      Hi Matthias, the case is still open with Microsoft support and engineers are still looking for a better way to bypass this scenario. So to give you an exact answer, no I didn’t got an answer. However the insider build of 20H1 includes a change in the generalize.xml which makes sure the file isn’t deleted anymore. So even if you did change the file in the end the file would be replaced with one of the feature updates. Hope this answers your question.

      Like

    2. Pim Jacobs says:

      Hi Matthias,
      I got a response back today from Microsoft support and updated the blog post, I hope this update helps you in your further process! Still happy to answer questions if you have some :-).

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s