How to Fix Intune Policies Causing Reboots During Windows OOBE and Autopilot

Unexpected restarts during Windows OOBE can derail Autopilot provisioning fast. The device reboots mid-flow, the user is pushed back to sign-in, and the Enrollment Status Page (ESP) feels stuck or inconsistent.

This guide walks you through how to confirm what triggered the reboot, how to isolate the policy or app responsible, and how to restructure assignments so Autopilot completes cleanly without weakening your security posture.

---

What This Looks Like in the Real World

Common symptoms:

• The device restarts during OOBE or while ESP is still applying policies/apps
• The user has to sign in again and sometimes repeat parts of setup
• Autopilot appears to “hang” or “loop” after reboot
• The device eventually completes, but the experience is unreliable

---

Why It Happens

Most OOBE reboots during Autopilot come down to one thing:

A policy or installer triggers a reboot too early

Typical culprits include device-based security settings that require a restart to fully enable, such as:

• Device Guard / VBS-related settings
• Credential Guard-related settings
• Other security profiles that flip hardware-backed protections on

When these are targeted to device groups, they can land during the device phase of Autopilot and cause an in-flight restart.

A second common cause:

An app forces its own reboot

Some installers return reboot-required codes (or hard reboot the machine) unless you explicitly suppress restarts in the install command.

---

Step 1: Confirm It Was a “Coalesced Reboot” and Identify the Trigger

When Windows consolidates a reboot request coming from management policies, it often shows up as a coalesced reboot.

Check Event Viewer

On the affected device:

1. Open Event Viewer
2. Go to:
   Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin
3. Search for:
   • “Reboot”, or
   • Event ID 2800

Event ID 2800 usually includes a URI that points to the setting area that triggered the reboot. That URI is your best breadcrumb to the exact policy category involved (Windows Update policy, security baseline, Device Guard/VBS settings, etc.).

Quick PowerShell to pull the latest reboot-trigger events

Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" |
  Where-Object { $_.Id -eq 2800 } |
  Select-Object -First 10 TimeCreated, Id, Message |
  Format-List

---

Step 2: Map the Reboot to the Policy That Caused It

Once you know the reboot-triggering URI or the “theme” (Update, Security, Device Guard), review the policies assigned to the device during Autopilot.

Security settings commonly associated with reboot behavior include items like:

• DeviceGuard/LsaCfqFlags
• DeviceGuard/ConfigureSystemGuardLaunch
• DeviceGuard/EnableVirtualizationBasedSecurity
• DeviceGuard/RequirePlatformSecurityFeatures
• DmaGuard/DeviceEnumerationPolicy

If these are being applied during provisioning, you are very likely to see reboots.

---

Step 3: Apply the Fixes That Keep Autopilot Smooth

Fix A: Delay Device Guard, Credential Guard, and VBS settings during Autopilot

Best practice: do not apply reboot-required security settings during the Autopilot device phase.

What to do instead:

• Move these policies away from device-targeted assignments during provisioning
• Prefer assigning them to user groups (so they apply later in the flow)
• Or create a staged rollout where these policies apply after Autopilot completes

Key point: You are not disabling protections. You are controlling when they are enforced.

---

Fix B: Control application reboots with Win32 packaging and return codes

If an app truly requires a reboot, you want Intune (IME) to handle it, not the installer.

Practical approach:

• Package the installer as a Win32 app
• Ensure return codes are mapped correctly (so Intune can interpret reboot-required outcomes)
• Avoid installers that force a restart outside Intune’s control during ESP

This gives you predictable behavior and keeps reboots from becoming “surprise events” mid-OOBE.

---

Fix C: Stop apps from forcing reboots

If the app does not absolutely require a reboot, suppress it.

Examples of common patterns:

• EXE installers: add a /norestart or /quiet /norestart style switch (varies by vendor)
• MSI installers: use properties that suppress reboots (vendor-dependent)

The goal is simple: don’t let the installer reboot the device during ESP.

---

Step 4: Re-test Autopilot the Right Way

Use a clean test device and validate in this order:

1. Run Autopilot again with the adjusted assignments
2. Confirm ESP progresses without an unexpected restart
3. If a reboot still occurs:
   • Check Event ID 2800 again
   • Identify the new URI
   • Repeat the isolation process

---

A Simple “Autopilot Safe Build” Checklist

Use this to keep OOBE stable:

• Keep device phase policies minimal and predictable
• Delay reboot-required security profiles (Device Guard, Credential Guard, VBS)
• Package apps as Win32 where possible
• Suppress reboots in install commands when the reboot is not mandatory
• Use Event ID 2800 to pinpoint the exact trigger when a reboot happens

---