Start with the phase on screen
The Enrollment Status Page separates provisioning into preparation, device setup, and account setup. Each phase can track different providers and assignments. Capture the exact heading, failing category, error code, local time, and whether the failure occurred before or after the first user sign-in.
| Observed phase | Likely evidence | First question |
|---|---|---|
| Device preparation | Enrollment, policy-provider registration, management extension bootstrap | Did the device join and enroll in the intended tenant? |
| Device setup | Device-targeted apps, certificates, security policies, and tracked providers | Which required item remained incomplete or returned an error? |
| Account setup | User-targeted apps and policies after sign-in | Is the assignment user-context, applicable, and required during ESP? |
Preserve the diagnostic package
When the profile allows log collection, use the on-screen diagnostics option. Otherwise collect an MDM diagnostics package through an approved support process. The useful package is not just one event log: it includes the HTML and XML MDM reports, registry export, event logs, and collection metadata.
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\MDMDiagReport.zip"Run diagnostic commands only on devices you are authorized to support. Preserve the original ZIP and work from a copy. The registry dump captures a point in time; a later retry may replace the state that explains the first failure.
Translate the category into an item
ESP uses enrollment-status tracking data to record providers, policies, and applications. The visible “Apps” label can represent a Win32 app, another application type, or a provider whose work is surfaced under that category. Inspect the tracking tree and identify entries whose installation state did not complete.
- Find the enrollment GUID and the ESP profile values captured in the diagnostic registry export.
- Locate the device or account phase that matches the screen.
- Record each tracked application or provider identifier and its installation state.
- Map the identifier to the Intune assignment or application record.
- Move to that workload’s own log only after the tracking state identifies it.
For a Win32 app, continue into the Intune Management Extension logs. For a certificate, policy, or CSP item, correlate the DeviceManagement-Enterprise-Diagnostics-Provider Admin log. Do not assume the final item shown in a user interface is the component that caused the stall.
Check assignment and applicability before the installer
A required app can be correctly packaged and still be wrong for ESP. Verify the group assignment, device-versus-user targeting, install context, applicability rules, dependencies, supersedence, and whether the app is explicitly selected as blocking. Confirm the device and user actually received the intended ESP profile.
- Compare the number of blocking apps with the configured timeout.
- Avoid mixing deployment patterns that compete for the Windows installer during ESP.
- Confirm required dependencies are also applicable in the same context.
- Separate download delay, detection failure, installation failure, and reporting delay.
- Check whether a restart occurred and which phase resumed afterward.
Define a controlled recovery
Once the failing item is identified, change one variable. Correct the assignment, detection rule, dependency, install command, or ESP selection in a limited test group. Do not enlarge the timeout as the only response unless the evidence shows healthy progress that simply needs more time.
A successful retest should prove the same device scenario can progress through the previously failing phase, that the targeted item reports success, and that the managed device checks in after reaching the desktop. Keep the failed and successful timelines together.