1. Establish eligibility and intent
Before reading client logs, confirm that the user and device are intended to enroll through the path being tested. Microsoft’s troubleshooting guidance starts with licensing and MDM scope because a client cannot complete a workflow the tenant has not authorized.
- Target tenant ID and verified domain.
- User principal name and the license that provides Intune entitlement.
- Whether the user is included in the configured MDM user scope.
- Enrollment restrictions, platform limits, device limit, ownership rules, and enrollment method.
- Windows edition and version, network location, proxy or inspection path, and system time.
Capture the actual values, not “looks correct.” If a group drives scope, record the group and how membership was confirmed. A recent change may not have reached every service when the failed attempt occurred.
2. Capture device and identity state
Record the physical and local identifiers: serial number, computer name, Windows version, and the time of the attempt. Run dsregcmd /status and retain the join indicators, tenant ID, device ID, and diagnostic section. Then identify the matching Entra device object and note whether an Intune managed-device or Autopilot record already exists.
This prevents an enrollment case from becoming a cleanup guess. A similarly named device may be a prior image, a personal registration, or a different object type. Correlate by identifiers before removing anything.
3. Locate the enrollment event
Windows records MDM enrollment activity under the DeviceManagement-Enterprise-Diagnostics-Provider logs. Capture the event ID, result or HRESULT, exact timestamp, and surrounding events from the same attempt. Export the relevant events when escalation may be required; a photo of only the red line removes the sequence that gives it meaning.
| Evidence | What it can establish | What it cannot establish alone |
|---|---|---|
| MDM event and HRESULT | The client phase and recorded result at a point in time | Whether tenant scope, identity, or a later ESP phase is correct |
dsregcmd /status | Local join and registration state | Successful Intune management or policy delivery |
| Intune portal record | Service-side management record and status | The complete local enrollment sequence |
| Autopilot device record | Deployment registration and assignment context | Current Entra trust or Intune health |
4. Separate enrollment from Enrollment Status Page
The Enrollment Status Page can make a successful identity and MDM enrollment appear to the user as one long “enrollment” operation. Record which ESP phase is displayed—device preparation, device setup, or account setup—and the application or policy named at the failure. Note whether the failure is consistent or intermittent and whether the Continue anyway option is available under the assigned profile.
Microsoft documents diagnostic collection during ESP, including log collection and locally stored diagnostic information. Preserve the package before a reset, wipe, or new attempt changes the evidence. The failure time should be aligned with service-side deployment status and device logs.
5. Inspect post-enrollment management separately
If the device has enrolled but Win32 applications, scripts, or remediations fail, the Intune Management Extension is a later component. Microsoft documents its log folder as C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Useful files include the main agent log and workload-specific logs, but choose them based on the failing action rather than attaching the entire directory without a timeline.
Record the application, script, or policy identifier from the portal when available. Correlate that identifier and the device’s local time with the management-extension log. An IME failure is not proof that initial MDM enrollment failed.
Build a compact escalation packet
- One-sentence expected outcome and one-sentence observed outcome.
- User, tenant, device, join, managed-device, and Autopilot identifiers.
- License and MDM scope evidence.
- Attempt time with time zone and network context.
- Relevant MDM events with surrounding sequence.
- ESP phase, named blocking item, and diagnostic package when applicable.
- IME log excerpt and workload identifier when failure occurs after enrollment.
- Changes already attempted and their results.
Remove access tokens, passwords, recovery keys, and unrelated personal data before sharing. Preserve the originals under your organization’s evidence and privacy rules.