Windows Autopilot ESP: Diagnose Enrollment Phases and App Tracking

The Windows Enrollment Status Page (ESP) is a provisioning gate, not a generic progress bar. It can hold the first interactive session while Windows receives management enrollment, policies, certificates, network settings, and required applications. When the screen stalls, the last visible label may name the phase that is waiting rather than the component that failed. A sound investigation identifies which stage is active, which settings and apps were actually tracked, and whether the device is blocked by enrollment, policy, restart coordination, or an installer.

ESP can be used with Windows Autopilot scenarios and with supported Windows provisioning flows outside Autopilot. Do not assume every device follows the same ESP policy, phase names, or app tracking behavior. Record the exact Windows build, provisioning method, join type, deployment profile, assigned user, enrollment policy, and timestamp. Also establish whether the incident occurred in device preparation, device setup, or account setup as presented by that scenario; documentation and product behavior evolve, so tie advice to the deployed build and current Intune configuration.

Model the status page as a sequence of gates

At a high level, Windows first completes the out-of-box experience and device identity steps, enrolls in mobile device management (MDM), receives its assigned policy, and processes the configuration selected by the ESP policy. The page can track a configured subset of applications and policies. It does not wait for every arbitrary program or every background task on the endpoint. An item absent from the tracking policy can install later, while a required tracked item can prevent the user from reaching the desktop until the applicable completion or failure rule is met.

Different Autopilot and device preparation paths have different stages and restart behavior. Treat the device’s active policy and registration state as evidence instead of inferring them from the marketing name of the deployment. The ESP registry data collected by MDM diagnostics can include enrollment information, profile settings, policies, and apps tracked for the current enrollment. The FirstSync state under the enrollment record is especially useful when determining which phase is being skipped or awaited. A phase being skipped can be an intentional policy or provider setting; verify the responsible configuration before treating it as corruption.

Build a timeline from the last completed checkpoint. Capture the first screen or error code, local and UTC time, whether the device rebooted, whether the network changed, and which application or policy is named. Then line up that time with MDM event logs, app installation logs, Autopilot diagnostics, and the enrollment state. A screenshot taken hours later can omit the transient message that distinguishes a timeout from an explicit failure.

Collect a diagnostic package at the failed device

If the ESP configuration allows log collection, use its supported collection action and store the resulting package with the incident record. During supported OOBE paths on a non-S-mode device, Microsoft documents opening a command prompt with Shift+F10; follow organizational policy for who may access that console. On Windows 10 version 1809 and later scenarios documented for Autopilot, MDM diagnostics can collect Autopilot and TPM areas as appropriate. A representative user-driven collection is:

mdmdiagnosticstool.exe -area Autopilot -cab C:\ProgramData\Autopilot-ESP.cab

Do not treat one command line as universal for every enrollment scenario. Microsoft documents different diagnostic areas for self-deploying, pre-provisioning, and general device provisioning cases. Select the supported area for the actual scenario and verify that the CAB file was created and contains the expected logs. Where a device is already at the desktop, collect diagnostics through the documented Intune or Settings workflow rather than interrupting a live deployment with an unsupported shell technique.

The MDMDiagReport_RegistryDump.Reg in a diagnostic CAB is a point-in-time diagnostic artifact, not a file to import into the registry. Inspect it as text or with an approved registry viewer. Find the enrollment instance associated with the incident and review its FirstSync data and ESP policy values. Avoid copying registry keys from another device as a repair: enrollment GUIDs, policy providers, and app tracking state belong to one enrollment lifecycle.

For a client-side package, preserve Event Viewer channels associated with DeviceManagement-Enterprise-Diagnostics-Provider, Provisioning-Diagnostics-Provider, Shell-Core, and Autopilot if present. Inspect the Application log and relevant app installer logs only for the incident interval. Discover available channels on the affected release instead of relying on a fixed event ID list. Events may include user, tenant, device, and app identifiers, so control access to the CAB and remove it according to the organization’s retention rules.

If Microsoft Support needs a scenario capture, use the current TroubleShootingScript toolset procedure and its approved scenario for Autopilot. A support script is a collection mechanism, not a cure. Record its version, arguments, start/stop times, and errors. Do not leave verbose trace collection enabled after the reproduction because device-management and application traces can grow quickly and may contain sensitive state.

Determine whether the device or account phase is waiting

Inspect the enrollment state and identify the active phase before making an app change. If device setup waits for policy providers, compare the assignment and processing state of each provider, including whether the device has completed registration and received the intended Autopilot profile. A profile can be assigned in the service but not yet applied to this device. Correlate service-side assignment and local MDM enrollment evidence; a tenant inventory row alone does not show what policy reached the endpoint before the timeout.

For an app-tracking failure, identify the exact app, assignment intent, install context, detection rule, return code, and reboot behavior. A successful installer process may still fail ESP tracking if detection never becomes true. Conversely, a package can install but remain in a pending state while another app or provider is awaited. Review the app’s own installation log and the management agent’s execution record; do not change a detection rule based solely on the error string shown to the user.

Windows Installer concurrency is a relevant boundary. Microsoft’s Autopilot guidance documents cases where mixing certain line-of-business (LOB) and Win32 application installation paths can cause a collision because they share Windows Installer resources. If the failure is repeatable only with a particular combination, test a supported sequencing or packaging change in a pilot group. Do not interpret a one-off installer lock as proof that every ESP issue is caused by MSI concurrency.

Unexpected restarts require a separate timeline. ESP supports some device setup reboot flows when the management process coordinates them; an arbitrary installer reboot or repeated restart can reset progress or leave tracking ambiguous. Review installer return-code handling, the responsible app assignment, device policy application, and the documented reboot-URI diagnostics. Do not suppress a required security or device restart without understanding which component requested it and how the deployment manager expects to resume.

Account setup can have different support and restart constraints from device setup. Compare the user’s enrollment and policy state separately from the device’s. A user-targeted app or certificate may not be present during a device-only phase, while a device-targeted app may be blocked by an account-level assumption. A system assigned access or shared-device mode may deliberately skip or reshape account provisioning, so the target UX must match the enrollment design.

Separate identity, network, and application failures

Before blaming a slow app, confirm that the device has stable DNS, time, proxy, and access to required enrollment endpoints. An OOBE device can be on a captive portal, a guest VLAN, or a network path with TLS inspection that behaves differently from a fully managed desktop. Record the active adapter, address, gateway, DNS suffix, and proxy route at the time of failure. Do not publish tenant URLs, tokens, serial numbers, or user identifiers in a public support post.

Identity errors can look like a policy timeout if the device is not correctly registered or the assigned identity is not authorized for the intended enrollment path. Use the documented Autopilot and Entra/MDM diagnostic records to distinguish hardware registration, directory join, MDM enrollment, and ESP processing. Re-registering a device or deleting a cloud object is a material identity change; preserve serial/registration identity and confirm the service-side ownership before considering it.

When the diagnostic evidence points to a timeout, ask what waited and for how long. Compare the configured ESP timeout, the app’s expected installation duration, network throughput, installer retry behavior, and whether the device restarted. Raising the timeout can be correct for an unusually large but healthy app, but it merely hides a permanent detection or policy failure. Test one change at a time on a representative device and retain a baseline from a successful deployment.

Pilot, recover, and prove the enrollment path

Use a disposable or reimaged pilot device to reproduce the failure with the same deployment profile, user/license state, policy assignments, network segment, and app versions. Change a single variable: remove one app from ESP tracking, adjust a supported detection rule, sequence conflicting installers, or repair a policy assignment. Recollect diagnostics after the change and compare the phase and tracked-item state. If the path succeeds, verify that the resulting device has the required apps, policies, certificates, identity, encryption, and restart state before declaring it production-ready.

Do not repeatedly reset a device without preserving its diagnostic package. Repeated resets erase transient state and can create duplicate records or make the timeline harder to follow. Before a reset, record enrollment identifiers and confirm that the device’s Autopilot registration and intended ownership remain intact. After recovery, validate an actual user sign-in and one representative managed workload, not just disappearance of the ESP screen.

A compact ESP incident workflow

Record deployment method, OS build, profile, join type, user, network, visible phase, error, and timestamp.
Collect the supported MDM/Autopilot diagnostic CAB and preserve relevant local event channels.
Inspect the enrollment’s FirstSync data and identify the provider or app that was actually awaited.
Correlate the device’s policy and app tracking state with service-side assignments and installer evidence.
Separate identity, network, app detection, Windows Installer contention, and restart causes.
Reproduce one scoped change on a pilot; do not relax the entire enrollment gate to hide a failing requirement.
Verify final policy, required applications, device identity, user experience, and restart completion.

ESP is most useful when its tracked requirements are deliberate and measurable. The diagnostic objective is not merely to make the progress screen disappear; it is to prove that the device reached the intended managed state through a repeatable enrollment path.

Related:

Sources: