Intune Enrollment Status Page stuck: fix app and policy timeouts

When the Intune Enrollment Status Page (ESP) hangs or times out, first note which phase is stuck (device preparation, device setup or account setup), then collect mdmdiagnosticstool.exe logs and check the EnrollmentStatusTracking registry key and the Intune Management Extension's AppWorkload.log to find the app or policy that never finished. The documented causes are a timeout too short for the apps you require, LOB and Win32 apps installing at once, Microsoft 365 Apps added with the built-in app type, reboots triggered inside app packages or by policies, user-context scripts, and users without an Intune license, which leaves the ESP on Identifying. Fix the cause in Intune rather than by raising the timeout alone.

Who this is for and what you will have

This guide is for Intune administrators supporting Windows Autopilot or Microsoft Entra join OOBE deployments where users sit on the ESP for too long or see the "Setup could not be completed" error. At the end you will have:

• A way to tell which phase and which item the ESP is waiting for.
• The registry values and log files that prove the cause.
• Fixes for each documented cause, and ESP settings that reduce the impact of the next failure.

If the device fails with a specific error code before the ESP, such as 0x80180014 or 0x800705b4, start with Windows Autopilot error codes explained.

How the ESP decides what to wait for

The ESP shows provisioning progress and can block the desktop until required apps and policies are in place. It tracks three phases.

Three details explain many "stuck" reports:

• The ESP doesn't track security policies such as device restrictions; they install in the background. It does track Microsoft Edge, Assigned Access and Kiosk Browser policies. When finished, security policies show as (1 of 1) completed.
• In account setup, the subtasks show Identifying while the device creates the tracking policy and calculates what to wait for.
• The Block device use until these required apps are installed list filters what the ESP waits for; it doesn't decide what installs. If an app isn't in the list, the ESP doesn't wait for it, and in user-driven and self-deploying mode Win32, Microsoft Store and Enterprise App Catalog apps outside the list install after the ESP completes.

For an app to be installed and tracked by the ESP, it must have a Required assignment to a group containing the device (device setup) or the user (account setup), it must be blocking (all apps, or in the selected list), and it must install in device context with no user-context applicability rules.

Prerequisites

• An Intune role that can edit ESP profiles and the affected apps.
• Access to the device. In OOBE on a non-S mode device, Shift+F10 opens a command prompt.
• An ESP profile with Turn on log collection and diagnostics page for end users set to Yes, so users can export logs and, on Windows 11, open the diagnostics page with Ctrl+Shift+D.

Step 1: Identify the stuck phase and item

Ask the user for a photo of the ESP or open it yourself, and note:

1. The phase (Device preparation, Device setup or Account setup).
2. The category (Apps, Certificates, Network connections, Security policies).
3. The counter, for example Apps (3 of 5), or whether it says Identifying.

A reboot during device setup is supported, but it forces the user to enter credentials again before account setup starts, because credentials aren't preserved across the reboot. Users often mistake that sign-in prompt for a failure.

Step 2: Collect diagnostics

From Shift+F10 or an elevated prompt, collect a cab file:

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

For self-deploying and pre-provisioning add the TPM area (-area Autopilot;TPM). For runtime provisioning, use -area DeviceProvisioning. On an admin workstation, summarize the cab with Microsoft's script:

Install-Script -Name Get-AutopilotDiagnostics -Force
Get-AutopilotDiagnostics -CABFile C:\Diagnostics\Autopilot.cab

Inside the cab, MDMDiagReport_RegistryDump.Reg holds the ESP settings the device received under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\{EnrollmentGUID}\FirstSync. If SkipUserStatusPage or SkipDeviceStatusPage there is 0xffffffff, a custom CSP is configured to skip that phase.

Step 3: Read the EnrollmentStatusTracking key

Since Windows 10 version 1903, the EnrollmentStatusTracking CSP records what the ESP tracks in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Autopilot\EnrollmentStatusTracking
  Device
    DevicePreparation        IME (SideCar) install state and tracked resource types
    Setup
      Apps
        Locked               whether device use is blocked until this stage completes
        PolicyProviders\Sidecar   TrackingPoliciesCreated
        Tracking\Sidecar\Win32App_{AppID}   InstallationState per Win32 app
  ESPTrackingInfo
    Diagnostics              timestamped status for MSI, store apps, Wi-Fi, SCEP
  {User_SID}                 account setup: user-context Win32 apps and tracking policy

Interpret the values as follows:

If any Win32 app has InstallationState of 4, the ESP stops installing apps; go to that app's entries in the IME logs. If the IME itself shows 4, apps can't start at all. If the {User_SID} subkey is missing, device setup never completed. Because the ESP doesn't track security policies, ExpectedPolicies contains only the placeholder EntDMID, which is normal.

Step 4: Read the Intune Management Extension logs

Win32 apps, PowerShell scripts and Microsoft Store apps are handled by the IME, which logs to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Open the files with CMTrace.

Search AppWorkload.log for the AppID from the registry. The usual findings are a download that never completes, an installer that waits for user input (Intune doesn't support interactive installs), an install that exceeds its Installation time required value, or a detection rule that never reports the app as installed after a successful install.

Fixes for the documented causes

The timeout is too short for the required apps

Microsoft states that ESP app timeouts usually happen because the timeout in the ESP profile isn't long enough for all required apps. Show an error when installation takes longer than specified number of minutes defaults to 60 minutes. Each Win32 app also has its own Installation time required value, which defaults to 60 minutes and can go up to 1,440 minutes; if you raise app timeouts, raise the ESP timeout to match. Then reduce what the ESP waits for: set Block device use until these required apps are installed to Selected and pick only the apps users need on day one (up to 100). On Microsoft Entra hybrid join Autopilot deployments the ESP runs 40 minutes longer than the value you set, to give the connector time to create the device record.

If Install Windows quality updates (might restart the device) is Yes, plan for 20 to 40 extra minutes and possible restarts after the ESP completes. On new ESP profiles this setting defaults to Yes; on profiles created before the setting existed it stays No until edited.

LOB and Win32 apps install at the same time

Both use TrustedInstaller, which allows one installation at a time. The Win32 install fails with Another installation is in progress, please try again later and the ESP fails. Package the LOB app as Win32, or move that device population to Windows Autopilot device preparation, which doesn't use the ESP and supports both types; see Autopilot device preparation vs classic Autopilot.

Microsoft 365 Apps hangs the ESP

The ESP can hang when Microsoft 365 Apps are added with the Microsoft 365 Apps (Windows 10 and later) app type, the ESP tracks them, and they start installing during another tracked Win32 install. Deploy Microsoft 365 Apps as a Win32 app instead. A related conflict involves the Teams Machine-Wide Installer MSI included with the Click-to-Run install, which the ESP doesn't track; Microsoft's workarounds are to deploy Teams or Office after the deployment completes, or to use device preparation on Windows 11.

Reboots inside packages or from policies

Reboots packaged inside an app can make the ESP hang. Configure restart behavior in the app's Device restart behavior setting and return codes instead. Reboots are supported in device setup but not in account setup. Policies known to force reboots during the ESP include the AppLocker CSP (used by App Control), some DeviceLock password settings and security baseline settings for UAC and virtualization-based security; Microsoft's workaround for the baseline settings is to target them to users so they apply later.

To find what triggered an unexpected reboot, look for the RebootRequiredURI event in the DeviceManagement-Enterprise-Diagnostics-Provider log. A sample event names the URI, for example:

The following URI has triggered a reboot: (./Device/Vendor/MSFT/Policy/Config/Update/ManagePreviewBuilds)

Stuck on Identifying

The ESP computes its policies during Identifying. Microsoft documents that this can never complete if the current user has no Intune license. Assign a license that includes Intune, then reset and retry.

Blocking apps ignored during device setup

Blocking apps listed in a user-targeted ESP profile are ignored during device setup, because the service can't know the user at that point. Target ESP profiles to device groups, or put the blocking list in the default profile. Profile priority is: highest-priority profile assigned to the device, then to the user (only when there's a user), then the default profile. Pre-provisioning and self-deploying use device-targeted profiles only.

Scripts that never run

Scripts set to Run this script using the logged on credentials = Yes might not run during the ESP. Set it to No so they run in System context.

ESP times out before the sign-in screen

If the ESP tracks Microsoft Store for Business apps and a Conditional Access policy requires a compliant device for all cloud apps on Windows, the ESP can time out. Target compliance policies to devices so compliance is known before sign-in, or use offline licensing for store apps.

Clock skew

ESP timeouts and TPM attestation failures can occur when the real-time clock is off by several minutes or more. At the start of OOBE, connect to the network and run w32tm /resync /force.

Settings that limit the impact of failures

• Allow users to reset device if installation error occurs lets users retry without IT.
• Allow users to use device if installation error occurs trades completeness for availability.
• Show custom message when time limit or error occur tells users who to contact.
• To drop the account setup phase entirely, deploy a custom setting with OMA-URI ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage, data type Boolean, value True. Disabling an ESP profile doesn't remove ESP policy already on devices.

Microsoft added ESP reliability changes on September 14, 2026: more app installation retries during the ESP, an IME sync immediately after the ESP completes, and more resilient check-in after network loss during OOBE. Those changes help with transient failures but don't fix configuration problems.

Verification

• Repeat the deployment on a test device. In the registry, every tracked Win32App_{AppID} should end at InstallationState 3, and the {User_SID} subkey should appear when account setup starts.
• Check the Windows Autopilot deployment report in the Intune admin center for the test device, and confirm the result against the device itself.
• Check each required app's device install status in Apps and confirm its detection rule reports it as installed.

Closing checklist

• ESP timeout covers the sum of blocking app installs; app Installation time required values aligned with it.
• Blocking list set to Selected with day-one apps only; ESP profiles targeted at device groups.
• No LOB MSI apps alongside Win32 apps; Microsoft 365 Apps deployed as Win32.
• Restarts controlled through app restart behavior, not inside packages; reboot-forcing policies tested or user-targeted.
• Scripts run in System context; all enrolling users licensed for Intune.
• Log collection and diagnostics page enabled; AppWorkload.log and EnrollmentStatusTracking checked before any reset.

References

• Set up the Enrollment Status Page
• Troubleshoot the Enrollment Status Page (ESP)
• Understand Microsoft Intune Management Extension
• Add and assign Win32 apps to Microsoft Intune
• Windows Autopilot troubleshooting FAQ
• Windows Autopilot known issues
• Troubleshooting Windows device enrollment problems in Intune
• What's new in Windows Autopilot