KBY Technologies Logo
runbooks/windows-endpoint-intune/intune-autopilot-esp-device-setup-timeout.md
HIGH SEVERITYWindows Endpoint & IntuneMicrosoft Intune

Intune Autopilot ESP Device Setup Timeout

Severity
HIGH
Target Time
45m
DomainWindows Endpoint & Intune
Verified
Overview

Diagnose Intune Autopilot Enrollment Status Page Device Setup timeouts, including 0x800705b4, by preserving diagnostics and identifying the exact blocking app, policy, join, MDM or network stage before changing assignments.

Share

01 // Diagnose

Symptom

Incident signalWhat responders observe

Windows Autopilot Enrollment Status Page times out during Device Setup before the user reaches the sign-in or desktop experience. The timeout symptom alone does not identify whether the blocker is application, policy, join or network related.

Detection Signature

Detection evidenceMetrics, logs, and confirmation commands

  1. Start with read-only evidence collection before any reset or configuration change.

  2. Confirm the operator has approved support access to the exact device and read-only access to the intended Intune tenant. Identify the exact Device ESP phase, then review MDM diagnostic logs, Autopilot diagnostic archives, relevant event logs and registry tracking information to determine which setting, application or policy is being tracked and failing.

  3. Correlate the blocking item with its Intune assignment and installation evidence, and separate whether the failure path is network access, profile download, Entra join, MDM enrollment, ESP-delivered policy, or application installation.

  4. Use mdmdiagnosticstool.exe -area Autopilot -cab <path\autopilot-diag.cab> for user-driven deployments.

  5. Use mdmdiagnosticstool.exe -area Autopilot;TPM -cab <path\autopilot-tpm-diag.cab> instead only for self-deploying or pre-provisioned deployments where TPM evidence is relevant. Other useful read-only inspection includes eventvwr.msc and reg query HKLM\SOFTWARE\Microsoft\Enrollments /s.

  6. Review DeviceManagement, ModernDeployment and Provisioning event logs and look for application failures and Device Configuration Timeout events.

Root Cause Analysis

Causal chainWhy the incident occurred

  1. Common proven causes include a blocking application or policy tracked during ESP, unsupported mixing of line-of-business and Win32 applications during ESP causing installer contention, and policies that force a reboot or interfere with OOBE autologon during Device ESP.

  2. Investigation must also account for network issues, profile download problems, Entra join failures and MDM enrollment failures before attributing the timeout to apps or policies.

02 // Contain & Prevent

Blast Radius

  • New or reset Windows Autopilot devices using the affected deployment profile

  • Users unable to reach sign-in or desktop because Device ESP does not complete

  • Assignments that deliver ESP-tracked applications or policies

  • Provisioning flows involving network, Entra join, MDM enrollment or profile download dependencies

Prevention Measures

Prevent recurrenceControls and architectural guardrails

  • Collect and preserve diagnostics before changing configuration.

  • Avoid mixing line-of-business and Win32 applications during ESP.

  • Avoid policies that force a reboot or interfere with OOBE autologon during Device ESP.

  • Validate changes against a pilot cohort in the same deployment profile and use collected evidence to identify the exact blocking application or policy before broader rollout.

03 // Fix & Intervention

Pre-Flight Checks

Change gateChecks required before intervention

  1. Confirm the operator has approved local administrative or support access to the exact device and read-only access to the intended Intune tenant; stop if the device, tenant or access context does not match.

  2. Record the device serial number, deployment profile, Device ESP phase, exact timeout time and affected pilot scope.

  3. Confirm read-only access to MDM diagnostics, event logs and registry tracking data, and avoid collecting unrelated user data.

  4. Separate network, profile download, Entra join and MDM enrollment failures from an ESP application or policy blocker.

  5. Correlate any suspected blocker with its current Intune assignment and installation evidence without editing the assignment.

  6. This runbook performs no app, policy, group, ESP or tenant mutation. Prepare a proposed single-object pilot diff only as evidence for the separately approved Intune change procedure.

Execution CommandsCOMMANDS

Get-Date -Format o
For a user-driven deployment, run: mdmdiagnosticstool.exe -area Autopilot -cab <path\autopilot-diag.cab>
For a self-deploying or pre-provisioned deployment where TPM evidence is required, run instead: mdmdiagnosticstool.exe -area Autopilot;TPM -cab <path\autopilot-tpm-diag.cab>
Run only the command matching the documented deployment scenario.
reg query HKLM\SOFTWARE\Microsoft\Enrollments /s
Review DeviceManagement, ModernDeployment and Provisioning event logs and identify the exact tracked application or policy associated with the Device ESP timeout.
Do not exclude applications, edit policy assignments, disable ESP, reset the device or make tenant-wide changes through this runbook. If a single blocker is proven, attach the diagnostic archive, current assignment evidence, exact pilot group object and proposed single-object diff to the separately approved Intune change procedure; otherwise escalate without mutation.

04 // Verify & Recover

Verification Steps

Recovery proofEvidence required before closure

  1. Validate using a newly reset test device in the same deployment profile.

  2. Confirm Device ESP completes and User ESP also completes.

  3. Verify required applications and policies are delivered successfully and that no Device Configuration Timeout or application failure evidence remains in the relevant diagnostics.

  4. Monitor the next production cohort using the same profile for repeat failures.

Rollback Protocol

Safe reversal path

  1. No state change is performed by this runbook, so there is nothing to roll back.

  2. Any later approved Intune assignment change must use its owning procedure, captured before-state and explicit pilot rollback.

Escalation

Conditions requiring additional ownership

  • Escalate when diagnostics do not identify a specific blocking application or policy.

  • When failures point to network.

  • Profile download.

  • Entra join or MDM enrollment rather than ESP-tracked content.

  • When multiple blockers are present.

  • Or when the timeout persists after reverting unsupported app combinations or problematic reboot or OOBE-interfering policies in the pilot scope.

Authoritative Sources

Authoritative · Microsoft

Troubleshoot the Enrollment Status Page

ESP troubleshooting starts by identifying settings, applications and policies tracked at each stage; MDM diagnostic logs and device registry contain ESP tracking information; collected evidence should identify the blocking application or policy before configuration is changed.

Authoritative · Microsoft

Windows Autopilot troubleshooting FAQ

Autopilot investigation covers network, profile download, Entra join, MDM enrollment and ESP-delivered settings; mixing line-of-business and Win32 applications during ESP is unsupported because installer contention can occur; policies that force a reboot or interfere with OOBE autologon can disrupt Device ESP.

Authoritative · Microsoft

Troubleshoot Microsoft Entra registration and Windows Autopilot

Autopilot diagnostic archives include DeviceManagement, ModernDeployment and Provisioning event logs plus registry state; provisioning diagnostics record application failures and Device Configuration Timeout events; the timeout symptom alone does not identify whether the blocker is application, policy, join or network related.

Intune Autopilot ESP Device Setup Timeout - Incident Runbook | KBY Technologies