Last Updated on April 5, 2023 by rudyooms

This blog will be about the famous reboots you could encounter when using Autopilot. In this blog, I am going to show you what would happen when you target a WUfB to a device group and try to enroll a Windows 11 device with Autopilot for pre-provisioned deployments.

Of course, I will also show you how to fix it on your own until Microsoft comes up with a solution!

I will divide this blog into multiple parts

1. The Issue
2. Troubleshooting
3. The Fix
4. How to NOT Implement the Fix
5. How to Implement the Fix Option 1
6. How to Implement the Fix Option 2
7. How to Implement the Fix Option 3
8. Windows 11 22000.856
9. Conclusion

1. The Issue

To get a better understanding of what is happening I decided to record it.

Please Note: I ordered an Elgato HD60 S to make sure the next recording would be a little bit better

When taking a good look at what’s happening in the youtube video you will have noticed that we are enrolling a Windows 11 with Autopilot for pre-provisioned deployments. After the ESP device phase finished installing the required apps Windows suddenly rebooted! Which normally shouldn’t be an issue if it continues the ESP!.

While the ESP was busy installing the apps, I made sure we were aware of the time frame. After the unexpected reboot, I logged in with my local admin account which was created during Autopilot to check out the System event logs and the Intune Management Extension log first.

As shown above (picture is clickable), when looking at the system event log first, you will notice the CloudExperienceHostBroker.exe triggered the reboot (0x20004). It’s always about the CloudExperienceHost I guess!

We could also open the Intune Management Extension log to find out if this error is also logged inside the IME log. As shown below, again the same error 0x20004 code we also noticed in the system event log. Sorry for the dutch words… but I guess you know what “Opnieuw Opstarten” means.

Now we have taken a look at the IME and system log, let’s check out some other event logs. When you are stumbling upon these kinds of CloudExperienceHost errors, the Shell-Core event log is always the place to start digging!

As shown above, this event log is telling us that the CommercialOOBE_ESP requires a reboot by the subcategory DeviceSetup.RebootCoalescing, ErrorCode 0.

Okay, so we now know that the CloudExperienceHost is responsible for the “reboot” but we are still not sure what could be triggering it. Let’s start some troubleshooting!

2. Troubleshooting

So I decided to perform another Autopilot enrollment to hopefully spot something more useful. This time I decide to monitor the DeviceManagement-Enterprise-Diagnostics provider for event 2800.

As shown below even while the device was still busy installing the apps the URI ./device/vendor/MSFT/Policy/Config/Update/ManagePreviewBuilds already triggered a reboot?

I was like huh? This issue should have been fixed some time ago (15-11-2021)

I guess it doesn’t count for Windows 11 somehow? But looking back at the picture and taking a look at the Timestamp, the device was still busy installing apps… and it didn’t reboot at that point… Almost if it “scheduled” the necessary reboot after it would finish the device phase

That’s kinda weird, so I decided to take another look at the DeviceManagement event log

Again the same RebootRequired and RebootCoalescing notification we got earlier. Coalescing….that’s a nice word? I am dutch, so I needed to translate it

To blend or come together: Okay… good to know that it was a combined reboot but I am also pretty sure I have read that specific word, somewhere else! After some searching, I stumbled upon this sentence.

“There will be a coalesced reboot at the end of the device setup phase of ESP, and the computer will have its new name after that reboot before they sign-in”

Of course…. Michael Niehaus Renaming Autopilot-deployed Hybrid Azure AD Join devices – Out of Office Hours (oofhours.com)

Okay, when NOT using Autopilot for pre-provisioning deployments, I am fine with it but this time I am not. I guess this reboot isn’t because of the computer name change but more about the Update/ManagePreviewBuilds RebootRequiredURI

I decided to check out the WUfB deployment rings because it was mentioning the Update URI. As shown below…

At first sight, it looks like there is nothing wrong with it as it is using the servicing channel: Retail Channel, and NOT the pre-release build:

I was expecting the Windows Insider setting to be configured like this!

Luckily it wasn’t! But then again, when enrolling Windows 10 with Autopilot the unexpected reboot didn’t occur! That’s odd! Maybe a combination? I know at first hand that device targeted Win32 Apps also could trigger a suppressed reboot at the end of the device setup because of a possible soft reboot return code it could receive.

So to be 100% sure it wasn’t the Win32Apps or the MS 365 Apps I decided to remove them all from the required apps during ESP and also removed all of the assignments so only the Company Portal Online (USER targeted) was left

After trying to reenroll the Windows 11 device again with Autopilot and still experiencing the same reboot we can be pretty sure the Win32 apps are NOT triggering it 😊 I guess we need to start taking another look at the WUfB ring!

Just like the Online version of the Company Portal we are using, I decided to do the same for the WUfB ring. Target at users not at devices!

As shown above, I decided to remove “All devices” from the assignment and added “All Users” instead.

Please Note: This WUfB example above, is definitely not the way to configure WUfB! But as it was my own demo/test tenant, all users were fine with me

After another Autopilot enrollment, I was amazed to see Autopilot ending up at its “sealing” screen instead of rebooting and ending up with a local login prompt. That’s weird! So changing the WUfB assignment to users will fix the Windows 11 reboot issue!

Please Note: When using AutoPatch, there is a “slight” change that you could also stumble upon the same issue. As shown below: The “BusinessReadyUpdatesOnly” is configured to all

3. Fixing it manually?

After changing the assignment we are now 100% sure the unexpected reboot is happening because of the Update/ManagePreviewBuilds RebootRequiredURIs!

Luckily I stumbled upon the needed registry key a while ago while I was writing a blog about the remediation error -201628112?

So I decided to open the registry to check out this key: HKLM:\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs

My first and maybe a very stupid idea was to just remove the ManagePreviewBuild URI from this section.

Trying to delete the registry key just gave me some permissions denied errors. Even the system didn’t have permission to change it! So using psexec wasn’t going to work. The only thing left was changing the ownership, because the “TrustedInstaller” was the only one with enough permissions to remove that registry value.

After removing this registry key manually I reenrolled my Windows 11 device again with Autopilot for pre-provisioned deployments.

AND YES, YES, YES!!! My stupid idea worked! The device didn’t reboot and ended up with a nice Seal screen!

4. How to NOT Implement the Fix

My first idea to fix it, of course, didn’t work. Let me explain what I tried to do. I wrote a PowerShell script and uploaded it to Intune so I can be sure it will be pushed to the device when enrolling the device with Autopilot.

This PowerShell script will create a scheduled task that is going to run as the “NT service\Trusted Installer”. This scheduled task will launch a PowerShell session and will execute the encoded command.

This encoded command is nothing more than just a removal of that specific registry key!

Okay, okay… it was my first idea!!!!... while trying to fix it this way I noticed that running the PowerShell script from Intune gave me some issues, let me explain them!

Issue 1:

I noticed that after I started the Autopilot pre-provisioning, getting that PowerShell script from Intune and automatically executing it was just a little bit too late!. At that point, Windows was already aware of the Requiredreboot URI!!!!!

Issue 2:

Being too late is one but when testing this script I also noticed the idea to create a scheduled task to bypass the “NT service\trusted installer” permission issue is great but it won’t work during OOBE. Because trying to start the scheduled task with Powershell or with schtasks, puts the task in a queued status!.

It will only be executed when manually right-clicking the task in the GUI and pressing “Run”. Please Note: I need to dig into this.. as I don’t understand yet why it doesn’t execute in the OOBE)

5. How to Implement the Fix Option 1

After testing out my first idea, I first changed the PowerShell script a little bit because the idea to run a scheduled task in the OOBE screen wasn’t going to work!

https://call4cloud.nl/wp-content/uploads/2022/04/remove2.zip

As shown above I decided to take another road to try to fix it. I am making sure I am downloading the Set-ACL.exe from my own website to the programdata folder. With this tool, it’s very easy to change the owner of that registry key. After changing the Owner, I am also making sure the administrators group will have full access to that same key.

After the ownership and permissions are changed, it will delete that specific RebootRequired key if it exists. After deleting the registry key it will restore the ownership.

Please Note: You will NEED to run this script BEFORE starting the pre-provisioning by using Shift-F10(if you are NOT blocking SHIFT+F10)

6. How to Implement the Fix Option 2

Running the PowerShell script to fix it manually, each time a device needs to be provisioned could be easily forgotten. To make sure I wasn’t going to forget to apply this fix each time I decided to alter my install.wim file a little bit.

Some time ago I already wrote a blog about how you could add an additional KB update to your Windows installation medium by using DISM

Why not do the exact same thing? This time we aren’t going to add a KB update to the installation medium but we are making sure that the registry key doesn’t even exist when installing a new device with my Windows 11 installation USB stick!

I plugged in my USB Stick with the Windows 11 installation files on it and made sure I created a temporary folder (mountnew) on my hard drive.

Let’s mount the Install.wim file from the USB Stick (D:) by running this command

Dism /Mount-Wim /WimFile:D:\sources\install.wim /index:6 /MountDir:C:\Mountnew

After we mounted the install.wim file to our temporary folder we could also “load” the registry that’s inside the system32\config folder by running this command

reg load HKLM\OFFLINE C:\Mountnew\Windows\System32\Config\Software

When the Software part is loaded you could open the registry and open the OFFLINE key as shown below

After we have opened the RebootRequiredURI’s registry key, we took over the ownership and deleted that key!

When you are done deleting that key you need to make sure you UNLOAD the OFFLINE registry by running this command

Reg unload hklm\offline

When we have UNLOADED the registry, let’s unmount the image with DISM to make sure our changes are committed and saved!

DISM /unmount-image /mountdir:c:\mountnew /commit

After my image was unmounted I reinstalled the device again! After the apps were installed successfully it prompted us with the good old “sealing” screen!

7. How to Implement the Fix Option 3

As mentioned before, when using Windows Autopatch you could also stumble upon this issue. So did Adam Gross

He used and rewrote my initial script but improved it a lot by obtaining additional privileges to delete those reg keys!

SeTakeOwnershipPrivilege

SeRestorePrivilege

Go get it while it’s hot!!! (could also be used to remove additional rebootrequireduri’s)

Toolbox/Remove-AutopilotRebootKeys.ps1 at master · AdamGrossTX/Toolbox · GitHub

8. Windows 11 22000.856

Damn…!!!! I guess the 2022-08 Update  (KB5016629) must be one of the best updates that were delivered since the KB5007253 (the one that fixed the Intel TPM attestation issues!)

Why? ??? Let me show you why!

1. It brings back the possibility to enroll devices with Autopilot pre-provisioning without the requirement to delete the Intune object first!

2. it fixes the required missing frameworks for your Microsoft Store apps after your device went through a remote Wipe!

Microsoft Store Apps not working after performing a Wipe (call4cloud.nl)

3. Last but not least!… it fixes the issue I showed you in this blog when you are pre-provisioning a device! When you have installed the required KB5016629 update, it looks like you can pre-provision your device without being afraid of a broken Autopilot device!

Conclusion

Having a good understanding of what could be causing a reboot during Autopilot is always good! When the reboot is triggered by Autopilot itself, normally it just reboots and will continue to the Account ESP stage.

A lot of people are complaining about a reboot during Autopilot…. but not me! Why? As it will solve the necessary Bitlocker DHA reboot to be compliant before the user logs in. I am explaining that part in another blog

Requiring Online Microsoft Store Apps and the Autopilot ESP (call4cloud.nl)

Looking back to the Windows 11 bug, when not using the insider preview we don’t need that key to be there! A simple fix (for now) is just to delete that key… or just wait until the fix from the latest insider preview arrives in the regular Windows 11 build?