The Enrollment Status Page (ESP) is where most Autopilot deployments die: stuck on "Identifying," spinning on "Installing apps (2 of 5)," or showing a red pre-provisioning failure screen. The ESP tells you almost nothing about why. The logs tell you everything, if you know where to look.
Get a command prompt during OOBE
Press Shift + F10 on the ESP (or Shift + Fn + F10 on some laptops) to open a command prompt. From there you can open Explorer, the event viewer, or PowerShell, and collect logs without waiting for the timeout.
Collect the diagnostics
# One cab with Autopilot, ESP, TPM, and enrollment logs
mdmdiagnosticstool.exe -area "Autopilot;TPM;DeviceEnrollment;DeviceProvisioning" -cab C:\Temp\autopilot.cabFor a readable summary of the ESP and every app's status, the community Get-AutopilotDiagnosticsCommunity script parses the same data:
Install-Script -Name Get-AutopilotDiagnosticsCommunity -Force
Get-AutopilotDiagnosticsCommunity -OnlineThe Intune Management Extension logs cover Win32 apps and scripts:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.logStuck in the device setup phase
Symptoms: stuck on "Security policies" or "Certificates," or waiting on "Identifying" for a long time.
- Certificate profiles (SCEP or PKCS) that can't be issued will hold device setup until timeout. Check the Intune Certificate Connector's health.
- The device isn't enrolled. Check automatic enrollment scope (see Autopilot setup).
- Network. Proxies, SSL inspection, and captive portals break setup in ways that look like hangs.
Stuck installing apps
This is the most common case. Look for:
- Mixing LOB (MSI) and Win32 apps in the ESP. Two installer technologies competing during setup is a classic source of hangs and failures. Package required apps as Win32 wherever possible.
- An app that waits for user input, or reboots without telling Intune. Check the install command's silent switches and return codes.
- Detection rules that never match, so Intune keeps waiting for an app it has already installed. See Intune app deployment failures.
- Too many blocking apps. Every app in the ESP's blocking list adds time and risk. Cut the list to what users truly need at first sign-in.
Pre-provisioning failures (the red screen)
Pre-provisioning (formerly "white glove") runs the device phase at a technician's bench, before the user ever touches it. It adds its own requirements:
- TPM 2.0 with working attestation. Virtual machines and some firmware versions fail here. Update the firmware and BIOS first.
- A wired network is strongly recommended at the tech bench.
- Device-targeted assignments only during the technician phase. Apps and policies assigned to users don't install until the user signs in.
- Time. Hitting the ESP timeout during pre-provisioning often means an app is trying to install that shouldn't be in the device phase.
Check the TPM from Shift+F10:
Get-Tpm
tpmtool getdeviceinformationLook for TpmReady : True. Attestation-related failures usually show up in the TPM section of the mdmdiagnosticstool output.
Fix it once, not per device
When one device fails, reset and retry. When several fail at the same step, the problem is in the configuration: the ESP blocking list, an app package, or an assignment. Change it once in Intune, then retest on a single device before resetting the rest.