If you’ve ever run into an Autopilot Unexpected Reboot right after Device setup, before the account setup even starts, you’re not alone. This post explains why it happens, how Windows Autopilot decides to trigger it, and what you can do to avoid or troubleshoot the reboot issue.
Introduction
When you deploy a Windows device with Autopilot, you expect the experience to be seamless. However, sometimes, just as the Device Setup phase of Autopilot finishes, the device unexpectedly reboots.
This Autopilot unexpected reboot interrupts the expected flow, sending the user back to the sign-in, requiring a second authentication. Even IT admins are caught off guard, and users start asking why they have to sign in twice.
This is the classic symptom of what Windows refers to as a coalesced reboot, a planned, consolidated restart triggered by specific Intune policy changes during Autopilot provisioning. Microsoft support teams see the Autopilot unexpected reboot often enough that they published a troubleshooting guide about it. But what is really happening under the hood, and how can you stop this from breaking your device onboarding experience? Let’s dive in.
What Really Triggers an Autopilot Unexpected Reboot
The device is not making a random decision when it restarts during Autopilot. The Autopilot unexpected reboot is triggered by specific Windows logic. At the core are two key pieces: the RebootRequiredURIs and the RebootRequired registry key. The first one: RebootRequiredURIs, contains a list of policy URIs that demand a restart. We can find those RebootRequiredURIs when opening the microsoft\provisioning\syncml\RebootRequiredURIs registry key.
The second piece is the RebootRequired registry key, which serves as the flag that actually causes the system to reboot. This one, we can find in almost the same key: microsoft\provisioning\omadm\syncml\rebootrequired.
In the next section, I’ll walk through how Windows checks these keys during provisioning, how and when the reboot flag is set, and how Autopilot and ESP know to restart the device.. So, how does Windows actually use these keys during provisioning? Let’s break it down.
How Windows Decides a Reboot Is Needed
When a device receives a new policy during Autopilot (Intune Enrollment), the SyncML engine (omadmclient.exe) processes each policy node.
Under the hood, coredpus.dll (initialize function) checks if any of the incoming policy URIs match those listed inHKLM\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs.
We can spot this when looking at Procmon:
If there is a match, Windows logs an event. You will see Event 2800 in the DeviceManagement Enterprise Diagnostics Provider log, showing that the following URI has triggered a reboot. (The funny.. even with this message logged, it does NOT mean the device will reboot… believe me… if not.. well, continue on reading)
At the same time, the OMADMClient creates a persistent registry key:HKLM\SOFTWARE\Microsoft\Provisioning\OMADM\SyncML\RebootRequired.
This RebootRequired key signals to the rest of the setup process that at least one applied policy requires a restart to take effect. This is what triggers a coalesced reboot, the system restarts, and only then do those particular policy changes become active. It is not about batching every single change, but about ensuring that settings that truly require a reboot are handled correctly.
How Autopilot and ESP Execute the Unexpected Reboot
With the RebootRequired flag set, control passes to the Enrollment Status Page and the CloudExperienceHost frontend. These components, working together with windows.management.service.dll, check for the presence of the RebootRequired registry key.
Please Note: If you want to learn more about how I use the IDA tool to disassemble this code, check out this Patch N Rant video
If the key exists, ESP immediately initiates a coalesced reboot, that is, the Autopilot unexpected reboot that interrupts the expected single sign-in flow. You will see this restart happen right after device setup and before account setup, just as the user is about to create their Windows Hello PIN (If configured). This behavior is also logged in the Shell Core event log (for example, event 62407, mentioning ‘DeviceSetup RebootCoalescing’).
If you are troubleshooting Autopilot unexpected reboots, the next step is understanding what causes these policies to trigger during device setup. The answer lies in how your policies are assigned.
Why Device vs. User Policy Assignment Matters
These Autopilot unexpected reboots occur only when the reboot-required policy is assigned to a device group. Device-assigned policies are evaluated and applied during the device setup phase of Autopilot. This means that if a policy matches a URI in RebootRequiredURIs, the reboot is triggered during provisioning. If the device reboots, the authentication buffer it had will be lost, and the user will need to sign in again.
If you change the assignment to a user group instead, the same policy will only be applied during the account setup phase, after the user has signed in. At this point, Windows does not perform the same device-wide coalesced reboot, so the disruptive restart does not occur. This is exactly what Microsoft also recommends as a workaround:
“A possible workaround is to change the policy assignment from the Device to the User. This still applies the policy and a reboot may still be required for the change to take effect. However, applying the setting after the device phase prevents the coalesced reboot from happening.”
This small change in how you target your Intune assignments can be the difference between a double sign-in and a seamless Autopilot experience.
But what if you want to test what happens when Windows cannot even signal that a reboot is required? Let’s look at some lab experimentation with permissions…
What Happens If SYSTEM Cannot Set the RebootRequired Key
To dig even deeper into the Autopilot unexpected reboot, we tested what happens if Windows loses the ability to set the RebootRequired registry key. We deployed a PowerShell script that places a DENY ACE for “Everyone” on the HKLM\SOFTWARE\Microsoft\Provisioning\OMADM\SyncML key.
The idea: make it impossible for any account—including SYSTEM—to create new keys or modify anything under this folder. The script removes any existing RebootRequired key, disables inheritance, and adds a DENY for write, delete, or create-subkey operations.
Small Note: Don’t deploy this prod… As I can’t guarantee that nothing else will break. If you are fine with that.. go ahead..
Here’s what the script does:
- Removes the existing RebootRequired key if it is present.
- Breaks inheritance on the SyncML key and copies existing ACEs.
- Adds a DENY entry for Everyone (SID S-1-1-0) to block all write, delete, and create-subkey access.
- Writes an audit log to confirm the ACL changes.
After this script runs, even if a provisioning policy matches something in RebootRequiredURIs, the OMADMClient will be denied access when it wants to set the reboot-required flag.
As a result, Autopilot and ESP never receive the signal and simply proceed to account setup as if no coalesced reboot was required (Even while the device management enterprise event log tells us that the policy triggered a reboot).
In short, without the “RebootRequired” registry key: no more Autopilot unexpected reboots!!! Again not recommended for production. Here’s the PowerShell script for reference:
A Better Way: Audit and Control Your Autopilot Reboot Policies
Instead of hacking registry permissions, a smarter approach is to identify which of your policies actually trigger a coalesced reboot, then adjust your assignment strategy accordingly
A PowerShell script can help by:
- Collecting every URI from RebootRequiredURIs
- Comparing those URIs to the policies in PolicyManager\current\device and the PolicyManager nodecache (because that’s where you Intune policies spend their time)
- Showing which Intune policies are assigned and which are possible triggers for a coalesced reboot
Once you know which policies are to blame, best practice is to assign them to a user group rather than a device group. That way, they only apply during account setup, and you avoid the Autopilot unexpected reboot altogether.
Here’s the first version of the script (please reach out if you have any comments or additions)
Conclusion
If you are dealing with an Autopilot unexpected reboot in your Windows deployment, know that it is not random. These reboots are caused by clear policy logic, registry keys, and device assignments. The best way to avoid the Autopilot unexpected reboot is to understand which policies trigger it, watch the logs, and use the right assignment strategy in Intune.