Windows Autopilot Enrollment Status Page Stuck at 0% — Causes and Fixes

Identify the failed phase, not just the percentage

Use this guide when Windows Autopilot's Enrollment Status Page (ESP) stalls or fails during device preparation, device setup or account setup. A 0% display is a symptom, not a diagnosis: app installation, policy tracking or authentication can still be relevant. Preserve the displayed stage, error text, time, device serial and deployment mode before retrying.

Scope and assumptions

This guide covers classic Windows Autopilot deployment profiles on supported Windows 11 releases. Windows Autopilot device preparation has its own provisioning flow and does not use classic ESP; use the Autopilot deployment comparison to identify the applicable model. Microsoft's ESP configuration documentation distinguishes these flows.

You need authorised access to the affected Intune device, deployment profile and app reports. Entra sign-in investigation requires the corresponding log-reading permission. Profile changes require appropriate Intune RBAC and scope. Diagnostic examples are illustrative and documentation-reviewed; no reproduced tenant failure is claimed.

Collect the first evidence

Where log collection and diagnostics are enabled in the ESP profile, use View Diagnostics or Ctrl+Shift+D on supported Windows 11 devices. Availability depends on the deployment scenario and profile. See Microsoft's Autopilot troubleshooting FAQ. A missing diagnostic button is not proof of an enrolment failure.

If an authorised support session permits Shift+F10, collect diagnostics before resetting. The following Command Prompt example creates its destination first:

if not exist C:\Temp mkdir C:\Temp
mdmdiagnosticstool.exe -area "Autopilot;DeviceEnrollment;DeviceProvisioning" -cab C:\Temp\AutopilotDiagnostics.cab

Keep the CAB in an approved support location. It can contain user, device and tenant identifiers. Use the portal's diagnostic collection when a local command prompt is unavailable; do not defeat restrictions to obtain one.

Choose the next check from the evidence

This ordering prevents a common diagnostic loop: rebuilding the same device while the unchanged blocking app or tenant assignment fails again.

Where each check lives

On the device, with the diagnostics CAB or a permitted Shift+F10 prompt:

Phase decision tree

Microsoft's ESP documentation splits classic ESP into three phases: device preparation, device setup and account setup. Each phase waits for different things, so the phase on screen narrows the search before you open a single log. Work through these questions in order.

1. Is this classic ESP at all?

• Windows Autopilot device preparation does not use ESP. If the tenant uses device preparation policies, this page is the wrong branch; use the Autopilot deployment comparison to confirm the model.
• Wrong branding, no organisation sign-in page, or a profile that never arrives is a registration or profile-assignment problem, not an ESP problem. Check the device in Windows Autopilot devices and its profile assignment, then use Autopilot hardware-hash import diagnosis if the device is not registered correctly.
• Record the deployment mode: user-driven, self-deploying, or pre-provisioning (technician flow or user flow). Several checks below apply to only one mode.

2. Device preparation

Microsoft lists three tasks here: securing the hardware, joining the organisation's network, and registering for mobile management. After enrolment the device works out which policies and apps to track and installs the Intune Management Extension.

• Secure your hardware (TPM key attestation) applies to self-deploying and pre-provisioning only. It is not needed for user-driven mode. An attestation error in those two modes points at TPM, firmware and the documented attestation path; see the TPM section below.
• Join and register are only tracked in this phase for self-deploying and pre-provisioning. In user-driven mode the user has already joined Entra ID and enrolled before ESP opens, so a user-driven failure here is more likely IME installation or tracking-policy creation than join.
• Local evidence: the diagnostics CAB's MDMDiagReport_RegistryDump.Reg contains HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\DevicePreparation, which records the Intune Management Extension installation state (1 NotInstalled, 2 NotRequired, 3 Completed, 4 Error).
• For self-deploying and pre-provisioned devices, Microsoft's ESP troubleshooting article collects the TPM area as well: add TPM to the -area list in the mdmdiagnosticstool.exe command above.

3. Device setup

This phase tracks device-targeted work: SCEP certificate profiles, VPN and Wi-Fi profiles, a small set of policies (Microsoft Edge, Assigned Access, Kiosk Browser), and device-context apps. Most security policies apply in the background and are not tracked.

• Which app? Blocking apps are the usual culprit. EnrollmentStatusTracking\Device\Setup\Apps\Tracking\Sidecar\Win32App_{AppID} holds an InstallationState per tracked Win32 app (1 NotInstalled, 2 InProgress, 3 Completed, 4 Error). Microsoft states that ESP stops installing apps once any app reaches 4; take that app ID to the IME logs.
• LOB and Win32 mixed? Microsoft says not to mix line-of-business MSI and Win32 apps with classic ESP. Both use TrustedInstaller, one fails with "another installation is in progress", and ESP fails. Pick one app type for ESP-tracked apps, or move that scenario to device preparation.
• Microsoft 365 Apps added with the Microsoft 365 Apps app type can hang ESP if it starts while another tracked Win32 app is installing. Microsoft recommends the Win32 app type for that case.
• Blocking-app list behaviour: the list filters which assigned apps ESP waits for; it does not assign anything. An assigned app that is not on the list is not waited for, and in user-driven and self-deploying mode Win32 and Store apps outside the list install after ESP completes. For pre-provisioning, check the "Only fail selected blocking apps in technician phase" setting.
• Reboots are supported in device setup only when Intune manages them through the app's return codes. A reboot packaged inside the installer can hang ESP. After a device-setup reboot the user must enter credentials again before account setup.

4. Account setup

This phase tracks user-targeted work: SCEP user certificates, user Wi-Fi profiles and user-assigned apps.

• Stuck at Identifying: Intune calculates what to track here. Microsoft documents that this can fail to complete when the signing-in user has no Intune licence. Check the licence before anything else.
• Reboots are not supported in account setup. An app that restarts the device here is a packaging problem.
• Hybrid Entra join: Win32 and UWP apps assigned to the device with user install context are not tracked, and Microsoft documents that hybrid Autopilot ESP runs about 40 minutes beyond the configured timeout while the device object syncs. Do not diagnose a hybrid timeout against the raw profile value.
• User-context scripts might not run during ESP. Microsoft's workaround is to run them in System context.
• Sign-in and Conditional Access failures surface here for the user phase. Use the sign-in record approach in the next section rather than widening exclusions.

5. Then change one thing

Once the phase and the category (network, authentication, app or TPM) are clear, make one scoped change on a pilot device, as described in Validation and recovery. Increasing the timeout, adding exclusions or letting users continue past errors are not diagnoses.

Network, time and authentication

Use a known working, approved provisioning network without an interactive captive portal. Compare the failing device against another device on that network before changing security controls. A TCP test is only one layer of evidence:

Test-NetConnection login.microsoftonline.com -Port 443
w32tm /query /status

TcpTestSucceeded: True does not validate TLS inspection, every required endpoint or authentication under the provisioning context. Review Windows Autopilot network requirements. If the clock is wrong, correct it through the supported time configuration and document the difference; do not disable certificate checks.

For Conditional Access, correlate the failure time and application in sign-in logs. An enrolled/compliant-device requirement can conflict with the initial enrolment path, but the resolution must be scoped to the actual affected policy. Use What If/report-only evaluation on a proposed change and preserve existing protection while reviewing it. Do not broadly exclude a named location, all users or all cloud apps to make ESP pass.

Apps and the ESP timeout

Inspect the configured ESP timeout and blocking-app list. The documented default is 60 minutes, but the assigned profile can differ. Increasing the timeout is reasonable only when the installation is progressing and measured pilot duration justifies it; it cannot repair an invalid detection rule.

Review C:\ProgramData\Microsoft\IntuneManagementExtension\Logs where IME is installed. Identify the exact app and correlate its installer exit code with detection, dependency, architecture and System/user context. Preserve the logs before another attempt. The Win32 application troubleshooting guide covers that branch in detail.

Limit blocking apps to the ones genuinely needed before the user reaches a usable, protected desktop. Pilot any change rather than allowing users to bypass all failures or removing security agents without an alternative control. Track whether the excluded app subsequently installs; passing ESP alone is not the success criterion.

TPM-specific failures

TPM attestation is relevant to self-deploying and pre-provisioned scenarios; it is not a universal requirement of user-driven Entra-joined Autopilot. For an attestation error, collect the exact code and inspect TPM state:

tpmtool getdeviceinformation

Check the documented hardware requirements and OEM firmware guidance. Do not switch TPM implementations, clear TPM or run reset commands you have not verified. Firmware and TPM changes can affect BitLocker and credentials, so confirm recovery access before an approved repair. A reimage does not resolve a persistent service, network or hardware incompatibility.

Validation and recovery

Make the change reversible first. Do not edit the ESP profile that production devices use. Create a copy with the one change, assign it to a pilot device or user group, and give it a higher priority than the production profile. Rollback is then removing that assignment, not remembering what the old values were. Leave the Default ESP profile alone: it applies to every device and user with no assigned profile.

After one scoped correction, repeat the affected deployment on the pilot. Record profile assignment, completion of each ESP phase, the blocking apps' detection results, expected policy state and user sign-in. Then verify Intune check-in and the security controls required for handover. Do not report success solely because the progress screen disappeared.

Success check: the pilot attempt shows as succeeded in Autopilot deployments; every tracked Win32 app has InstallationState 3 (Completed); the device record in Intune shows a recent check-in and an evaluated compliance state; and the controls you require at handover are present on the device, such as endpoint protection running or a BitLocker key escrowed. Compare the phase durations with those of a known-good attempt. A pass that took three times as long is a warning, not a success.

If the same error returns, retain both sets of diagnostics and undo the specific pilot policy change if it caused a regression. Resetting or reinstalling is a separate destructive action: preserve needed data and logs, establish recovery access and use an approved reset workflow only after diagnosing whether local state is the cause. Avoid deleting device registrations as a routine troubleshooting shortcut.

What not to run in production

• Turning on Allow users to use device if installation error occurs (or turning off blocking) on the production profile to make the ticket go away. Devices reach users without the apps or controls ESP was there to guarantee.
• Deleting the Autopilot registration or the Entra device object to “re-trigger” the profile. The registration must then be re-imported, and a deleted Entra object for an Autopilot device breaks the link Autopilot relies on until the device is re-registered.
• Raising the timeout to the maximum as a fix. It turns a clear failure into a device that sits on the ESP screen for hours.
• Excluding the Intune enrolment apps from every Conditional Access policy. Scope the exception to the policy and the provisioning path you proved in the sign-in log.
• Clearing the TPM or resetting the device before the diagnostics CAB and IME logs are saved. After a reset, the evidence for the next attempt is gone.

Related resources

• Autopilot hardware-hash import diagnosis helps when registration fails before provisioning.
• Intune device not syncing covers post-enrolment MDM check-in.
• BitLocker recovery-key verification belongs before destructive recovery work.

Correction record

29 September 2026 — Reviewed against documentation. Added the console and device log locations for each check, a copy-and-prioritise pattern so ESP changes can be rolled back by removing one assignment, an explicit success check and a list of actions not to take in production. No endpoint or tenant execution is claimed.

25 September 2026 — Reviewed against documentation. Added a phase decision tree for device preparation, device setup and account setup, including blocking-app, LOB/Win32 mixing and TPM attestation scope, based on Microsoft's ESP setup and troubleshooting articles. No endpoint or tenant execution is claimed.

10 September 2026 — Reviewed against documentation. Separated classic ESP from device preparation, corrected the diagnostics shortcut, and replaced unsupported error mappings and TPM/reset advice with evidence-led checks.