How to Fix Microsoft Intune Policies Causing Unexpected Reboots During Windows Autopilot OOBE
Identify and resolve unexpected device reboots during Windows Autopilot OOBE caused by Intune security policies, Windows Update rings, and Win32 app installers.
- Difficulty
- Advanced
- Time required
- 30-45 minutes
- Steps
- 8
- Platform
- Microsoft Intune
Table of contents
Quick Answer
Go to the stepsUnexpected Autopilot OOBE reboots happen when Intune security policies assigned to device groups trigger coalesced reboots during the ESP device setup phase. The fix is to reassign those policies to user groups, which delays application until after the device phase completes. Check Event Viewer for Event ID 2800 to identify the specific policy URIs.
- Check Event ID 2800 to identify reboot-triggering policy URIs.
- Cross-reference URIs with RebootRequiredURIs registry key.
- Reassign security policies from device groups to user groups.
- Fix Windows Update ring preview build settings if needed.
- Configure Win32 apps with /norestart flags.
Event Viewer > DeviceManagement-Enterprise-Diagnostics-Provider > Admin > Event ID 2800Expected result: Autopilot OOBE completes without unexpected reboots, and users sign in only once.
Key takeaways
- You'll learn how to identify which Intune policies trigger coalesced reboots during Windows Autopilot OOBE, reassign them to avoid interruptions, and configure Win32 apps to suppress reboot prompts.
- Unexpected reboots during Autopilot OOBE force users to sign in again, clear cached credentials, and can cause deployment failures. Fixing this creates a smooth, single-sign-in experience.
- Assign security policies to user groups, not device groups, to prevent coalesced reboots during Autopilot OOBE.
Introduction
Unexpected reboots during Windows Autopilot Out-of-Box Experience (OOBE) are one of the most common complaints from IT admins deploying devices with Microsoft Intune. The symptom is unmistakable: a device reaches the Enrollment Status Page, starts applying policies or installing apps, then restarts without warning. The user must sign in again, and in some cases the provisioning flow fails entirely.
The root cause is what Microsoft calls a 'coalesced reboot.' When Intune delivers certain policies to a device during the Autopilot device setup phase, Windows detects that those policies require a system restart to take effect. It schedules a consolidated restart, interrupting the OOBE flow. Per Microsoft's official troubleshooting guide on Tech Community, the most common triggers are Device Guard, Credential Guard, Virtualization-Based Security (VBS) settings, and misconfigured Windows Update rings.
This tutorial walks through the complete diagnostic and fix process: identifying the offending policies via Event Viewer and registry analysis, reassigning them from device groups to user groups, fixing update ring settings, and configuring Win32 apps to suppress reboot behavior.
Who this is for: IT administrators and MSPs managing Windows device deployments through Microsoft Intune and Windows Autopilot.
Before you start
- Access
- Access to the Microsoft Intune admin center and local admin access on an affected Autopilot device.
- Required roles
- Intune Administrator or Global Administrator
- Required licenses
- Microsoft Intune Plan 1 or Microsoft 365 E3/E5
- Environment
- An affected Windows device plus a test device for validating fixes.
- Vendor
- Microsoft
- Administrator permissions required
- Backup required
Time varies depending on the number of policies and apps to audit. Budget 30-45 minutes for the full diagnostic and fix cycle.
Warning: Backup policy assignments before changes
Document all current policy assignments before making changes. Reassigning policies changes the timing of policy application.
Warning: Test changes on a pilot group first
Don't apply changes to production groups immediately. Validate on a test device group first.
Note: Security policies still apply after reassignment
Moving policies from device to user groups delays application, not removes it.
1Identify the reboot trigger in Event Viewer
Find the exact policy URI that triggered the coalesced reboot.
Event Viewer > DeviceManagement-Enterprise-Diagnostics-Provider > AdminOn the affected device, sign in with the local admin account. Open Event Viewer (eventvwr.msc). Navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin. Filter for Event ID 2800, which logs whenever a policy URI triggers a reboot requirement.
Also check the System log for CloudExperienceHostBroker.exe entries with error code 0x20004, which confirms the OOBE process was interrupted by a restart.
eventvwr.mscExpected result: One or more Event ID 2800 entries listing specific policy URIs that triggered the coalesced reboot.
Note
If no Event ID 2800 entries appear, the reboot may have been caused by an app installer. Skip to Step 5.
2Cross-reference with RebootRequiredURIs in registry
Confirm which policy URIs are registered as reboot-requiring.
Open Registry Editor (regedit) and navigate to HKLM\SOFTWARE\Microsoft\Provisioning\SyncML\RebootRequiredURIs. Document the URIs. Then check HKLM\SOFTWARE\Microsoft\Provisioning\OMADM\SyncML\RebootRequired to confirm a policy triggered the reboot flag.
regeditExpected result: You confirm which URIs from Event ID 2800 appear in the RebootRequiredURIs list.
Note
Don't delete or modify these registry keys manually. They're managed by Windows.
3Reassign security policies from device groups to user groups
Move offending policies from device group to user group assignments.
Intune > Devices > Configuration > [Policy] > AssignmentsIn Intune admin center, locate each offending policy. Go to Assignments, remove Device groups, add User groups, and save. Per Microsoft's guidance, this delays application to account setup phase, preventing the coalesced reboot.
Expected result: Security policies assigned to user groups. They apply during account setup rather than device setup.
Note
Some policies need device-scope assignment (Wi-Fi, certificates). Only reassign the ones causing reboots.
4Fix Windows Update ring ManagePreviewBuilds issue
Clear the ManagePreviewBuilds URI that triggers a coalesced reboot.
Intune > Devices > Windows > Windows Update ringsIf Event ID 2800 shows the ManagePreviewBuilds URI, go to Devices > Windows > Windows Update rings. Toggle Enable pre-release builds to Enabled, save, wait 5 minutes, change back to Not Configured, save again.
Expected result: ManagePreviewBuilds URI is no longer set, eliminating it as a reboot trigger.
Note
New update rings created after the Intune 2111 service release don't set ManagePreviewBuilds by default.
5Configure Win32 apps to suppress reboots
Prevent Win32 apps from forcing reboots during Autopilot.
Intune > Apps > Windows apps > [App] > ProgramAdd /norestart or REBOOT=ReallySuppress to install commands. Configure return codes 3010 (soft reboot) and 1641 (hard reboot). Set Device restart behavior to Determine behavior based on return codes.
Expected result: Win32 apps install without forcing reboots. Intune handles restarts through return codes.
Note
Not all apps support /norestart. Check vendor documentation for correct silent install switches.
6Check for DFCI-related reboots on Surface devices
Determine if DFCI is causing a reboot on Surface devices.
High-trust Surface enrollments invoke the UEFI CSP, which triggers a reboot even without DFCI configured. Check the DeviceManagement logs for the UEFI CSP URI. This reboot is expected and can't be prevented through policy changes.
Expected result: You confirm whether the UEFI CSP URI appears. If so, the reboot is expected for high-trust enrollments.
Note
This applies only to Surface or OEM devices with high-trust enrollment.
7Test the fix with a fresh Autopilot deployment
Validate that all changes eliminate unexpected reboots.
Reset a test device and run through the full Autopilot OOBE. After completion, run mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\temp\AutopilotDiag.cab and check for Event ID 2800 entries and the RebootRequired registry key.
mdmdiagnosticstool.exe -area Autopilot;TPM -cab C:\temp\AutopilotDiag.cabExpected result: Autopilot deployment completes without reboots. User signs in only once.
Note
If reboots still occur, re-check Event ID 2800 for newly introduced policy URIs.
8Set up ongoing monitoring
Prevent future regressions with a regular audit process.
Intune > Endpoint securityCreate a recurring review process to audit policy assignments. Document which policy types require user group assignment vs. device group assignment. Add this check to your change management process.
Expected result: A documented process exists for reviewing policy assignments.
Note
Create a shared wiki page with your Autopilot policy assignment rules for new team members.
How to Confirm Autopilot Deploys Without Reboots
Verify fix
After applying all fixes, a successful Autopilot deployment should proceed from OOBE through the Enrollment Status Page to the desktop without unexpected restarts. The user signs in once.
Check three things: no Event ID 2800 entries during enrollment, no RebootRequired registry key, and no CloudExperienceHostBroker.exe errors with code 0x20004.
Surface devices with high-trust OEM enrollment may still show one expected DFCI-related reboot. This is normal.
Normal result: Autopilot completes with a single sign-in, no Event ID 2800, and no RebootRequired key.
Abnormal result: If Event ID 2800 still appears, a policy URI is still assigned to a device group.
Successful
No Event ID 2800, single sign-in
All coalesced reboot triggers eliminated.
ManagePreviewBuilds persists
Event 2800 with ManagePreviewBuilds URI
Recreate the update ring.
App-triggered
IME log shows installer restart
Check Win32 app install command.
Troubleshooting
Event ID 2800 shows unknown URI
Warning
Cause: Policy inherited from All Devices or Settings Catalog.
Check All Devices assignments. Search Settings Catalog profiles for the URI.
Policies don't apply after reassignment
Warning
Cause: User group membership or exclusion group issue.
Verify user group membership in Microsoft Entra ID. Check for exclusion groups.
ManagePreviewBuilds persists after toggle
Warning
Cause: Cached setting not cleared.
Delete the existing update ring and create a new one from scratch.
Win32 app still forces reboot
Warning
Cause: Installer ignores /norestart.
Wrap the installer in a PowerShell script. Configure Intune to handle 3010 as soft reboot.
Double sign-in persists
Critical
Cause: Multiple reboot sources or PowerShell restart command.
Re-run diagnostic from Step 1. Check all PowerShell scripts for Restart-Computer or shutdown /r.
Frequently asked questions
Why do Intune security policies cause reboots during Autopilot OOBE?
Security policies like Device Guard, Credential Guard, and VBS require system-level changes that only take effect after a restart. When assigned to device groups, they apply during the device setup phase and trigger a coalesced reboot.
What is a coalesced reboot?
A consolidated restart Windows schedules when policy URIs match entries in the RebootRequiredURIs registry key. Windows batches requirements and performs a single restart, interrupting OOBE.
Does reassigning to user groups reduce security?
No. The same policies still apply, just during account setup instead of device setup. Same security posture, no OOBE interruption.
Can I prevent ALL Autopilot reboots?
Not always. Surface devices with high-trust OEM enrollment trigger a DFCI-related reboot that can't be prevented. Policy-driven and app-driven reboots can be eliminated.
How do I map a CSP URI to an Intune policy?
Cross-reference the URI with Microsoft's CSP documentation on Microsoft Learn. The URI path follows: Policy area > Setting name.
Conclusion
Unexpected Autopilot OOBE reboots stem from security policies triggering coalesced restarts during the ESP device setup phase. The fix involves identifying offending URIs through Event ID 2800, reassigning policies from device to user groups, and configuring Win32 apps with reboot suppression.
Assign security policies to user groups, not device groups, to prevent coalesced reboots during Autopilot OOBE.
Event Viewer > DeviceManagement-Enterprise-Diagnostics-Provider > Admin > Event ID 2800Sources4
