Windows Autopilot can appear frozen at Device setup while the Enrollment Status Page (ESP) waits for an application, security policy, certificate, or network operation. The percentage on screen is not enough to identify the blocker, and restarting immediately can erase the clearest view of the failure.
Treat the stopped screen as a provisioning checkpoint. Capture its phase, identify the tracked workload, and only then decide whether to retry the device or change the deployment configuration.
Preserve the stalled state long enough to diagnose it
Record the device name or serial number, the Autopilot profile, the ESP profile, the displayed phase, and the exact time. Photograph the visible error code if the page has timed out. If Collect logs is available, use it before selecting Reset or Continue anyway.
Name the phase that has stopped
ESP separates provisioning into Device preparation, Device setup, and Account setup. A Device setup stall usually means the device has joined Microsoft Entra ID and enrolled in Intune, but a device-targeted workload has not completed. An Account setup stall points more often to user-targeted policy or apps after sign-in.
Do not confuse traditional Windows Autopilot with Windows Autopilot device preparation. Device preparation has a different workflow and does not use ESP, so advice about ESP app tracking does not apply to both experiences in the same way.
Collect logs before wiping the device
From a failed ESP screen, use the configured diagnostics option when it is available. Administrators can also collect the Autopilot diagnostics package and review the provisioning and device-management event logs. Useful events include application failures, policy timeouts, and the point where the provisioning progress page stopped advancing.
Work backward from the tracked application
When ESP displays Apps (x of y installed), identify which applications the ESP profile is configured to track. Open Devices > Windows > Windows enrollment > Enrollment Status Page, select the assigned profile, and review Block device use until required apps are installed if they’re assigned to the user/device plus the selected blocking apps.
Then use Intune app status for the affected device. If one Win32 package is failing, follow the app-level diagnostic path instead of extending the entire ESP timeout. Check its assignment, requirements, dependencies, install command, return codes, and detection rule.
Avoid competing installer technologies during ESP
Traditional ESP does not support mixing line-of-business MSI apps and Win32 apps when their installations compete through Windows Installer. A visible “Another installation is in progress” message is strong evidence of that conflict. Package the application consistently or change what ESP blocks on rather than allowing two installer paths to race.
Microsoft 365 Apps and security products can also take longer than small utilities. Keep the blocking set limited to software truly required before desktop access. Nonessential applications can continue after the user reaches Windows.
Check timeout and restart behavior
An ESP timeout should cover realistic policy and application delivery on the network users actually have. Increasing it can help a healthy but slow deployment; it does not repair a broken detection rule or an installer waiting for interaction.
Review whether the ESP profile allows users to collect logs, reset after failure, or continue anyway. Those choices affect recovery but not the underlying workload. Also look for app-initiated or policy-initiated restarts that interrupt the ESP autologon flow.
Separate network delay from configuration failure
Test with a stable connection that can reach Microsoft identity, Windows Update, Intune, and required content endpoints. Captive portals, SSL inspection, proxy authentication, and restrictive guest Wi-Fi can let OOBE start but prevent later content from arriving.
Use the timing pattern as a clue:
- A profile that never downloads suggests network, registration, or Autopilot assignment.
- A consistent failure on the same app suggests packaging, applicability, dependency, or detection.
- Different apps failing across attempts suggests connectivity, disk, service health, or competing installers.
- A long pause followed by success suggests the timeout or blocking-app set needs tuning.
Avoid changing the Autopilot profile, ESP profile, app package, and network path together. One controlled change makes the next deployment result useful.
Reduce the chance of another Device setup hang
| Configuration area | Safer practice |
|---|---|
| Blocking apps | Track only apps required before desktop use |
| App packaging | Avoid mixed LOB and Win32 installation conflicts during ESP |
| Detection | Test rules in the same context and architecture as deployment |
| Restarts | Prevent unexpected restarts inside blocking app installs |
| Timeout | Set a realistic value based on package size and network conditions |
| Diagnostics | Enable log collection and document the supported failure action |
Pilot profile changes with a small device group and a known network. A clean first device does not prove the deployment is resilient; repeat the test with a standard user, a slower connection, and the same required-app set used in production.
After the device reaches Windows, confirm the device state after provisioning. That check separates a successful OOBE completion from a device that still has unmet security requirements.
Autopilot setup questions
Should I press Reset as soon as Device setup stops moving?
Wait long enough to distinguish slow progress from a timeout, then collect the available logs and screen details. Reset is appropriate when the deployment has definitively failed and your organization supports retrying it. Resetting before evidence is captured often produces the same hang without explaining it.
Why does ESP show zero apps installed when some apps are present?
ESP reports tracked app completion, not a simple inventory count. An app can be installed but fail its detection rule, or it can be outside the selected blocking set. Match the app ID and device install record instead of relying only on the displayed number.
Can I let the user continue to the desktop after a failure?
The ESP profile can expose that option, but allowing it is a policy decision. A user who continues might receive apps and policies later, while a genuinely required security control remains incomplete. Use it only when support staff know which workload failed and how the device will be checked afterward.
Does a longer ESP timeout fix application failures?
It helps only when the packages and network are healthy but need more time. A bad command, missing dependency, incompatible requirement, or incorrect detection rule still fails at the end of a longer wait. Use the error and logs to decide whether time is actually the constraint.
Before you deploy the next device
Keep the failed device’s phase, timestamp, and workload evidence together, then change the smallest relevant setting. Retest with the same profile and network so the result is comparable. The durable fix is not simply getting one machine past ESP; it is proving that the blocking set, installer behavior, timeout, and recovery options work predictably for the next user as well.