Autopilot ESP troubleshooting checklist

Symptoms to confirm

• 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.

Likely causes

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).

• 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.

Note: For Microsoft Entra hybrid join deployments, the ESP runs about 40 minutes longer than the configured timeout by design, giving the on-premises side time to create the device record in Microsoft Entra ID.

+1 more causes in the full article.

Checklist

1. 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.

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

   cmd

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

   On your admin workstation, summarize the cab with the Get-AutopilotDiagnostics script from Microsoft's ESP guide:

   powershell

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

2. 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:

   powershell

   $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

3. 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. 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. 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

• 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.