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.
Use the diagnostics page before resetting the device
On a supported Windows 11 user-driven deployment, the Enrollment Status Page can expose diagnostic details before a reset removes the most useful evidence. The Intune administrator must enable log collection and the diagnostics page in the ESP profile. Have the device serial number and deployment profile name ready. Keep the device connected to stable power and an approved network.
-
Record the visible failure state
Photograph the ESP phase, category, progress count, error code, and device time. Note whether the stall is under Device preparation, Device setup, or Account setup and whether Apps, Security policies, Certificates, or Network connections is still processing.
-
Open the diagnostic view
Select View diagnostics when it appears, or press Ctrl+Shift+D in a supported Windows 11 user-driven scenario. Review the tracked policies and applications without changing registry values. If the control is unavailable, record that fact because the ESP profile may not allow end-user diagnostics.
-
Collect the available logs
After a timeout or failure, select Collect logs when offered and copy the resulting package to an approved USB drive or support location. Keep the filename linked to the device serial number and deployment time. Do not upload enrollment logs to a public file-sharing service.
-
Identify the blocking item
Give the package to the Intune administrator and compare the displayed phase with the applications and policies tracked by ESP. For app failures, verify required assignment, device or user context, dependencies, detection rules, and whether the app is explicitly configured to block device use.
-
Retest after one controlled correction
Change the identified app, policy, network requirement, or ESP configuration rather than simply extending the timeout. Reset or redeploy only after evidence is preserved. On the next enrollment, confirm that the same tracked item reaches completion and that the device advances beyond the original phase. If it fails again, compare the new logs with the first package before making another change.
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.