This blog will discuss the famous reboots you could encounter when using Autopilot. I will also show you what happens 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!
1. The Issue
To better understand 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 notice that we are enrolling 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 ensured we knew 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, we noticed the same error 0x20004 code again in the system event log. Sorry for the dutch words… but I guess you know what “Opnieuw Opstarten” means.
Now that we have examined the IME and system logs, let’s examine some other event logs. When you encounter CloudExperienceHost errors, the Shell-Core event log is always the place to start digging!
As shown above, this event log tells 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 unsure what could be triggering it. Let’s start troubleshooting!
2. Troubleshooting
So, I decided to perform another Autopilot enrollment to hopefully spot something more useful. This time, I decided 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 RebootRequiredURIs
I decided to check out the WUfB deployment rings because it mentioned 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 could cause the same issue. As shown below, the “BusinessReadyUpdatesOnly” is configured for 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
Of course, my first idea to fix it didn’t work. Let me explain what I tried to do. I wrote a PowerShell script and uploaded it to Intune so I could be sure it would be pushed to the device when enrolling it 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 that the idea of creating a scheduled task to bypass the “NT servicetrusted installer” permission issue is great, but it won’t work during OOBE. 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 also ensure 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 had 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! After the apps were installed successfully, we were prompted by 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 greatly 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!
- 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 goes 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 pre-provisioning a device! After installing the required KB5016629 update, it looks like you can pre-provision your device without being afraid of a broken Autopilot device!
Conclusion
It’s always good to have a good understanding of what could be causing a reboot during Autopilot! When Autopilot triggers the reboot, it normally just reboots and continues to the Account ESP stage.
Many 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 wait until the latest insider preview fix arrives in the regular Windows 11 build?
We tried for a long time to get that implicit ManagePreviewBuilds setting removed but couldn’t get it done. It’s there for a very fringe scenario, i.e. an Insider build that wants to leave the Insider rings and join the “normal” ring, but that’s maybe 0.01% of machines out there. And there’s no logic to see “am I already out of the Insider rings” before telling the OS “leave Insider” and no logic in the OS to say “if I’m already not in Insider, it’s silly to reboot.” Hence the mess you see.
The other possible workaround is to just not use the rings setting, manually setting the “other” WUfB settings via custom OMA-URI policies.
Always nice to have michiel niehaus responding on a blog about autopilot… and especially when its my blog :)… an honor :).
Doesnt sound like a difficult thing to remove but then again i am not working at ms :p… its a shame we should need to turn back to using the csp instead of the wufb rings to solve it… luckily with the latest insider previews the esp is still alive after the reboot… (even when it doesn need to reboot)
Once again I find your blog detailing the exact same issue we’re having right now. I am in the process of testing Windows 11 and I run into the same issue where the computer reboots half way through self deploying mode, and ends up being unusable.
But even after having tried both your options to fix this, it still doesn’t work. I have verified that the registry key doesn’t exist (and your script also confirms that when I run it). For now, I am out of suggestions, and keep crawling the internet for anything useful, but I think I might as well wait for the 22H2 release and hope that it’s fixed there.
Cheers,
Pär
Oh, and another thing I tried after reading Michael Niehaus’ post, was to exclude WUfB from these computers. But that didn’t help either…
Hi. Did you also searched for that same event log as I did for the managepreviewbuild? It should mention which uri has triggered the reboot
Do you happen to have the security baselines configured? As these also could trigger a reboot due to the virtualization-based security
Hi! Sorry for not replying sooner, but I’ve been busy with my main work… 🙂
You are absolutely right; this doesn’t seem to have anything to do with managepreviewbuild. When checking the DeviceManagement-Enterprise-Diagnostics-Provider logs, I find 3 entries that triggers a reboot:
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/RequirePlatformSecurityFeatures
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags
I will try to find a workaround for this, but if you have any suggestions, I’m happy to hear them. 🙂
/Pär
There are a few more policies that MS have identified that cause reboots:
https://docs.microsoft.com/en-us/mem/autopilot/policy-conflicts
For these we’ve found that assigning them as user not device based policies helps with pre-provisioning/self-deploying. Bit of a pain as they are a part of the security baselines.
Hi .. True there are indeed more policies that cause this behavior…but its always fun when it works/was fixed on windows 10 and goes again broken in windows 11 😉
Fantastic article Rudy, while this wasn’t the root cause of my unsolicited Autopilot reboots I do appreciate the depth of your troubleshooting and navigating your way to a resolution nice work !!
Just as an FYI I have been testing Autopilot on Windows 11 22H3 and started getting a prompt in Device Setup stage that my device is automatically going to get signed out/rebooted with a 10 minute countdown.
Root cause is an Endpoint security/Attack Surface Reduction/Device Control policy. Regardless of whether this policy is configured for Audit or Enforce mode if it is assigned to a Device group you will experience this issue that breaks the Autopilot process.
“Fix” is to target this to a User group instead.