The Enrollment Status Page is the most visible part of the Autopilot experience and the most common source of Autopilot failures. Getting it right matters more than almost any other provisioning decision.
The ESP holds the device at the setup screen while policy applies and apps install. Done well, it gives you confidence that a device is fully configured before the user touches it. Done poorly, it times out, blocks devices indefinitely, or gets bypassed – leaving devices in an unknown configuration state that causes problems weeks later.
What the ESP actually does
The ESP has two phases: the device setup phase and the account setup phase. The device phase runs before any user signs in – it applies device-targeted policies and installs device-targeted required apps. The account phase runs after the user signs in – it applies user-targeted policies and installs user-targeted required apps.
Both phases are configurable independently. You can require the device phase to complete before allowing sign-in, require the account phase to complete before allowing desktop access, or configure both. In most deployments you want both phases enforced – the device phase ensures security baseline is in place before the user logs in, the account phase ensures the user’s apps and settings are ready before they reach the desktop.
The ESP tracks progress against the apps and policies that are assigned as required to the device and user groups involved in provisioning. Only required assignments are tracked. Available assignments – apps the user can install on demand – are not tracked by the ESP and don’t block progress. This distinction matters when you’re designing what gets required versus available.
The timeout problem
The default ESP timeout is 60 minutes. If required apps haven’t finished installing within that window, the ESP either fails or – depending on your configuration – allows the user to bypass it. Either outcome is bad. A failed ESP usually means a device that needs to be wiped and re-provisioned. A bypassed ESP means a device that reached the desktop before its required configuration was complete.
The ESP timeout is not a safety valve. It’s a failure mode. Design your app assignments so you never need it.
The fix is to be deliberate about what you mark as required for ESP tracking. Every Win32 app that’s required during provisioning adds to the ESP install time. Large apps – Microsoft 365, Visual Studio, development tools – can easily push a deployment past 60 minutes on a slow network connection. Increase the timeout if you need to, but more importantly, audit what’s required during provisioning versus what can be installed after the user reaches the desktop.
The right approach is to keep the ESP-tracked required apps to the essentials – security tools, Company Portal, anything that genuinely must be present before the user works. Everything else goes in as available or gets installed by a post-enrollment remediation. A 15-minute ESP that completes reliably is better than a 60-minute ESP that times out on complex deployments.
Configuration settings
The ESP profile has a handful of settings worth understanding before you deploy.
Show app and profile installation progress is the main toggle. Turn it on. Without it the ESP shows nothing – the user sees a blank screen with no indication of what’s happening. That generates helpdesk calls.
Block device use until all apps and profiles are installed controls whether the ESP is enforced or advisory. Turn this on for the device phase. Whether to enforce it for the account phase depends on your app catalog size and network conditions – for most environments, enforce both.
Allow users to reset device if installation error occurs gives users an escape hatch if the ESP fails. Leave this off in production. A failed ESP needs IT involvement to diagnose – letting users reset the device without logging the failure removes the data you need to understand what went wrong.
Allow users to use device if installation error occurs is the bypass setting. This is the setting that lets users skip past a failed ESP to the desktop. Turn it off. An uncompleted ESP means the device may not have its security baseline applied. That’s not a state you want users working from.
Error message shown to users is a custom message displayed when the ESP fails. Set something useful here – an IT contact number or a support URL. The default error message gives users nothing actionable.
Diagnosing ESP failures
When the ESP fails or stalls, the diagnostic information is in the MDM diagnostic logs on the device. During an active ESP session, pressing Ctrl+Shift+D opens a diagnostics view that shows which apps are pending, which have failed, and what errors they returned. This is the first place to look before assuming a network or infrastructure problem.
The most common causes of ESP failures are app installation errors – usually a Win32 app with a detection rule that doesn’t match after a successful install, or an app that fails silently without returning a proper exit code. Fix the app packaging and the ESP failure goes away. The second most common cause is network timeouts on large app downloads – fix by either increasing the timeout, reducing what’s required during ESP, or improving network conditions at enrollment sites.
Track ESP failure rates from the start. Intune’s enrollment reports show ESP completion status and failure reasons. If more than a small percentage of deployments are hitting ESP failures, something in your required app assignments or timeout configuration needs attention. A reliable ESP is one of the clearest signals that your provisioning design is sound.
Intune Deployment Guide · Phase 4: Provisioning
‹ Previous: [4.1.1] Autopilot Profiles and Deployment Modes
Next: [4.1.3] Hardware Hash Registration ›
