Enrollment Status Page timing out during Autopilot: a step-by-step troubleshooting guide

An Autopilot device sits on the Enrollment Status Page (ESP) until the timer runs out and the user gets a setup error. The timeout is only the messenger: something the ESP was tracking never finished. In this guide I'll show how to identify exactly what that was from the device itself, and which profile changes stop it happening again.

Symptoms#

• The ESP stalls in Device setup or Account setup, usually on the apps step, and shows an error once the configured time limit passes.
• Depending on the profile, the error screen offers Collect logs, a reset, or a way to continue anyway.
• Sometimes the ESP never gets past Identifying, or the device restarts unexpectedly in the middle of setup.

Why it happens#

The ESP runs in three phases: Device preparation (enrollment itself), Device setup (device-targeted apps, SCEP certificates and network profiles, before anyone signs in) and Account setup (user-targeted items after sign-in). Most security policies apply in the background and aren't tracked. When Block device use until all apps and profiles are installed is Yes, the user is held until every tracked item completes or the timer expires (60 minutes by default).

The usual reasons a tracked item never completes:

• Too much work for the time limit. Microsoft names this the usual cause of app-related timeouts: many required apps, short timeout.
• Mixing line-of-business (LOB) MSI and Win32 apps. Both install through TrustedInstaller, which can't run two installations at once. The Win32 install fails with "Another installation is in progress, please try again later", and the ESP fails with it.
• Reboots. Restarts are only supported during device setup, and Intune must drive them through return codes. Packages that reboot on their own, or policies that need a restart (the AppLocker CSP and security baseline settings such as virtualization-based security are documented examples), derail the flow.
• A user-targeted ESP profile. Blocking apps listed in a profile assigned to users are ignored during device setup, because the device doesn't know the user yet.
• Problem app types. Scripts that run with the logged-on credentials might not run during ESP, and Microsoft 365 Apps added with the built-in Microsoft 365 Apps app type can hang the ESP if they start while another tracked Win32 app installs.
• Stuck on Identifying. A user without an Intune license can leave the ESP calculating what to track indefinitely.

How to fix it#

1. Note the phase and collect logs#

Write down which phase and step failed: device setup points at device-targeted items, account setup at user-targeted ones. If Turn on log collection and diagnostics page for end users is Yes, use Collect logs on the error screen to save logs to a USB drive. With that setting on, Ctrl+Shift+D also opens the Autopilot diagnostics page on Windows 11 user-driven deployments.

Otherwise, press Shift+F10 to open a command prompt (not available in S mode) and run:

mdmdiagnosticstool.exe -area Autopilot -cab C:\autopilot.cab

For self-deploying and pre-provisioning, use -area Autopilot;TPM instead. On your admin workstation, summarize the cab with the Get-AutopilotDiagnostics script from Microsoft's ESP guide:

Install-Script -Name Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics -CABFile C:\Temp\autopilot.cab

2. Find the stuck app in the registry#

ESP tracking lives under HKLM\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking. Each device-phase Win32 app gets a Win32App_<AppID> key under Device\Setup\Apps\Tracking\Sidecar, with an InstallationState value: 1 not installed, 2 in progress, 3 completed, 4 error. From the Shift+F10 prompt, type powershell and run:

$root = 'HKLM:\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\Setup\Apps\Tracking\Sidecar'
Get-ChildItem -Path $root -ErrorAction SilentlyContinue | ForEach-Object {
    [pscustomobject]@{
        App   = $_.PSChildName
        State = (Get-ItemProperty -Path $_.PSPath).InstallationState
    }
} | Format-Table -AutoSize

An app parked at 2 is your prime suspect. A 4 means the ESP stopped installing apps after that failure. User-phase Win32 apps are tracked under a key named after the user's SID, and LOB MSI apps, Wi-Fi and SCEP profiles under ESPTrackingInfo\Diagnostics.

3. Read the IME logs for that app#

Win32 apps are installed by the Intune Management Extension (IME), which logs to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Open AppWorkload.log, search for the app ID from the registry key, and follow it from download to install to detection:

• A download that never finishes points at content size or network filtering.
• An installer that never exits is often waiting for input; Intune installs must be silent.
• "Another installation is in progress" is the LOB and Win32 clash.
• Installed but not detected is a detection rule problem (0x87D1041C).

4. Check for unexpected reboots#

In Event Viewer, open Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin and look for event ID 2800, which records the policy URI that asked for a restart. Move that policy out of the ESP window, for example by targeting it to users instead of devices.

5. Fix the ESP profile#

Go to Devices › Device onboarding › Enrollment, open the Windows tab and select Enrollment Status Page under Windows Autopilot. Then:

• Set Block device use until these required apps are installed if they are assigned to the user/device to Selected and list only what users need on day one, such as security and connectivity agents. Apps outside the list still install: the IME checks for app assignments as soon as the ESP finishes.
• Raise Show an error when installation takes longer than specified number of minutes to cover the real install time of your blocking apps on your slowest network. Remember that each Win32 app also has its own installation time limit (60 minutes by default).
• Package ESP apps as Win32 only. If you genuinely need LOB and Win32 apps together, Microsoft points to Windows Autopilot device preparation, which doesn't use the ESP.
• Assign ESP profiles to device groups, and let return codes drive app restarts.

Verify the fix#

• Reset a test device and redeploy. Every app under the Sidecar key should reach 3 well within the time limit.
• AppWorkload.log shows each blocking app installing and then being detected.
• The apps report as installed, and the Autopilot deployment report under Devices › Monitor shows success.

Prevent it next time#

• Keep the blocking list short, Win32-only and in device-targeted ESP profiles.
• Size the timeout from measured install times, and retest whenever you add a blocking app.
• Leave log collection and the diagnostics page on, so users can hand you logs when something fails.

References#

• Troubleshoot the Enrollment Status Page (ESP)
• Set up the Enrollment Status Page
• Windows Autopilot troubleshooting FAQ