Intune diagnostic report

An overview of how this device is managed. The score removes 15 points per critical finding and 5 per warning; it is meant for comparing devices against each other, not for grading absolute severity.

Priorities

1. CriticalMultiple Intune enrolments (2)ENR-002
   Identify the active enrolment (the one whose EnterpriseMgmt scheduled tasks exist and run), then remove the leftover Enrollments keys, the orphaned EnterpriseMgmt tasks and the associated MDM certificates. Re-enrol after cleanup.
2. CriticalOnly 8,2 % free on the system driveSTO-001
   Free space before anything else: no other diagnosis is meaningful while the drive is this full.
3. CriticalUpdate service disabled: DoSvcSVC-001
   Set the service back to its normal start mode, then check what disabled it: a policy, a hardening baseline, or a third-party tool.
4. CriticalClock drift of 421 secondsTIME-001
   Resynchronise immediately with 'w32tm /resync /force'. Check the configured time source and, on a virtual machine, host time synchronisation. Check the time zone too.
5. CriticalEntra ID token acquisition failureSIG-TOKEN
   Check connectivity to login.microsoftonline.com, the device clock, the PRT (dsregcmd /status), and any Conditional Access policy targeting the device.
6. Critical1 application(s) in error are blocking the Enrollment Status PageESP-003
   In IntuneManagementExtension.log, search for the application id listed below to get the installer's own exit code. Then check the detection rule and the installer's return codes in the Intune portal.

The result of cross-checking the collected sources against each other. The 'Passed' entries are kept on purpose: without them there is no way to tell a check that succeeded from a check that never ran.

Critical 6

Warning 16

Info 5

Not tested 4

Passed 24

Join state, MDM enrolments, synchronisation machinery and certificates. This is the foundation: if something is broken here, everything else follows from it.

Device identity (dsregcmd)

Full output: dsregcmd-status.txt (raw output)

MDM enrolments

An active Intune enrolment carries ProviderID = MS DM Server. More than one of those means an incomplete cleanup.

MDM synchronisation tasks

Machine certificates

The certificate issued by a 'Microsoft Intune MDM Device CA' authority authenticates the device on every MDM session. Without it, or without its private key, no synchronisation succeeds.

Whether this device went through Windows Autopilot, with which profile and from which tenant, and at which step it stopped if it did. Microsoft documents little of what Autopilot leaves on a device, so each value says who documents it.

The deployment, step by step

Each step is placed by what it left on the device. The first step in failure is the one to look at: the steps after it never had their chance. 'No trace' means the device keeps nothing for that step, not that it failed.

1. 1
   Autopilot profileDone2026-07-20 14:23:42 +02:00Microsoft
   • CloudAssignedTenantDomain = contoso.onmicrosoft.com
   • DeploymentProfileName = Contoso - Standard utilisateur
   • Event 161 at 2026-07-20 14:23:42 +02:00
2. 2
   TPM attestationNot applicable
3. 3
   Entra joinDone2026-07-20 14:50:42 +02:00Derived
   • AzureAdJoined = YES
   • DeviceCertificateValidity starts 2026-07-20 14:50:42 +02:00
4. 4
   MDM enrolmentDone2026-07-20 14:56:42 +02:00Derived
   • Intune enrolment 6F2A41D8-93C4-4B17-A0E5-1D8C7E2F4B60
5. 5
   ESP - device preparationDoneMicrosoft
   • Sidecar InstallationState = 3 (Completed)
6. 6
   ESP - device setupFailedMicrosoft
   1 application(s) in error, which stops the page: Contoso VPN Client 4.2 (a19f4c7b-2e83-4d16-b5a0-7c91e2d84f35).
   • a19f4c7b-2e83-4d16-b5a0-7c91e2d84f35 : InstallationState = 4 (Error)
7. 7
   ESP - account setupSkipped by the profileMicrosoft
   • SkipUserStatusPage

Autopilot and ESP findings

The verdicts of the consistency checks behind this section, each detailed in the Findings section.

• Critical1 application(s) in error are blocking the Enrollment Status PageESP-003
• Warning1 local setting(s) known to break AutopilotAUT-006
• Warning1 Autopilot endpoint(s) of 5 unreachableAUT-010
• Warning2 application(s) of 6 never completed during the ESPESP-004
• InfoEnrollment Status Page tracking present (last phase reached: DeviceSetup)ESP-001
• InfoESP phase skipped by configuration: account setupESP-010
• Not testedTracking of line-of-business (MSI) applications by the ESPESP-006
• Not testedTracking of Store applications by the ESPESP-007
• PassedAutopilot profile received: Contoso - Standard utilisateurAUT-001
• PassedThe profile's tenant is the device's tenantAUT-002
• PassedWindows edition Enterprise supported by AutopilotAUT-004
• PassedThe hardware meets the requirements of the deployment modeAUT-005
• PassedManagement extension installed during device preparationESP-002
• PassedDevice-phase tracking policies createdESP-005
• PassedAll 1 Wi-Fi profile(s) tracked by the ESP were installedESP-008
• PassedAll 1 certificate profile(s) tracked by the ESP were installedESP-009

The profile received

The Source column says who documents each value. Microsoft: Microsoft Learn. Get-AutopilotDiagnostics: described only by the script Microsoft's own ESP troubleshooting page tells you to run. Community: described only in community write-ups. Derived: worked out by this tool from the other values. Microsoft documents little of this on the device side, which is why the distinction is kept.

OOBE options in the profile

Decoded from CloudAssignedOobeConfig = 1310. Microsoft documents the five lower bits; the others are named by Get-AutopilotDiagnostics.

Enrollment Status Page

The page that holds the device until its applications and policies are in place. A single application in error (state 4) stops it from installing anything after it.

Settings received

Received through the DMClient CSP and stored under the enrolment key (Enrollments\6F2A41D8-93C4-4B17-A0E5-1D8C7E2F4B60\FirstSync).

Tracked applications

The Win32 applications the page waited for, any in error first. Names come from the management extension's records when it has them.

What each phase waited for

Reboots requested by a policy

Event 2800 names the policy behind each reboot. An unplanned reboot during the ESP is a common reason for autologon to fail.

Prerequisites checked on this device

Autopilot event trail

Read over the whole of each channel rather than the 14-day window: a device is deployed once, and the events that say how are usually older than that. Newest first.

What this device cannot tell

These answers live in the tenant, not on the device. Where to find them:

• Whether the device is registered, and which deployment profile is assigned to it: Intune admin center > Devices > Windows > Enrollment > Windows Autopilot > Devices.
• Two profiles reaching the same device through two groups, which Microsoft gives as a cause of 0x801C03EA: the device's group memberships and each profile's assignments.
• Which ESP profile applies and its blocking applications: Devices > Windows > Enrollment > Enrollment Status Page. Microsoft notes that blocking apps listed in a user-targeted ESP profile are ignored during device setup.
• A device reused after self-deploying mode or pre-provisioning, refused with 0x80180014: its Autopilot device record, 'Unblock device'.
• Hybrid join: the Intune Connector for Active Directory - version 6.2501.2000.5 or later, installed in the target domain - and its log under Microsoft > Intune > ODJConnectorService (event 30132: rights on the target OU).
• Licences and the device limit (80180018), the MDM user scope, and Conditional Access exclusions for Microsoft Intune Enrollment.
• The deployment report, Devices > Monitor > Windows Autopilot deployments, and the diagnostics collected automatically on failure, kept for 28 days.

Raw files

Everything above was read from these files, all inside the archive.

Every code encountered is normalised (hexadecimal, decimal and signed decimal), decoded, and tied to the exact list of files and lines where it appears. Codes with no individual entry are at least attributed to their subsystem.

Overview

Detail

Unable to download updates: 0x80072EE7. The name of the update service could not be resolved.

Refresh token acquisition failed: AADSTS50058, interaction required. The PRT is absent.

The Primary Refresh Token could not be obtained: 0xCAA5011E.

Application a19f4c7b-2e83-4d16-b5a0-7c91e2d84f35 (Device): Error, code 0x87D1041C.

Detection rule did not find the application after a successful installation. Registry rule targets the 64-bit branch; the installer writes to the 32-bit one.

Application 3d82c5e1-9b47-4a60-8f12-6e05b7d31c94 (Device): Error, code 1603.

MSI returned exit code 1603. The verbose MSI log is the only place the real cause appears.

The MDM session failed during TLS negotiation with manage.microsoft.com. The presented certificate was issued by CN=Contoso SSL Inspection CA.

Every source merged into a single stream, newest first. This is where the real order of events shows: what failed first, and what is merely a consequence of it.

10 distinct entries. Repeated occurrences of the same message are grouped: the multiplicity column gives the count.

The state of every managed application alongside what is actually installed - side by side, because most application failures are really detection disagreements.

Applications tracked by the management extension

These states come from the local registry (HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps). This is what the device knows about itself: a gap against the portal means the last state report never got through.

Applications installed on the device

The reference for validating a detection rule. Note the Branch column: a registry rule that only targets the 64-bit branch will never see a 32-bit application, and will produce 0x87D1041C indefinitely.

What the MDM client actually applies, and where two sources contradict each other.

Conflicts between providers

Detected by comparing PolicyManager\providers\* against PolicyManager\current\device. These conflicts are invisible from the Intune portal, which shows both profiles as applied.

Effective policies (14)

TPM, BitLocker, Defender, the management extension, the clock and the proxy: the components that enrolment and deployments depend on.

Security posture and component state

System and hardware

Whether the required endpoints are genuinely reachable, from this device and in its network context.

Each endpoint is tested in three steps: DNS resolution, TCP connection, then a full TLS handshake. The issuer of the presented certificate is recorded: if it is not an expected public authority, something is decrypting the traffic - a configuration explicitly unsupported on Intune endpoints.

Effective WinHTTP proxy: proxy.contoso.local:8080. This is the one SYSTEM services use, independently of the user session's proxy - a frequent source of confusion when diagnosing.

What governs updates on this device, what it actually received, and how current its applications are. Most of what stops a device updating is configuration rather than failure, and configuration produces no error anywhere.

Windows Update for Business settings

The Source column says where each value came from. A CSP value is what the MDM client applied; a GPO value comes from Group Policy. When both exist the CSP one is shown, because that is the one in force.

Other values present under the same keys

Everything else found under the Windows Update policy keys, the CSP area and the UX settings. Listed so that nothing is hidden merely because it was not on the curated list above.

Delivery Optimization

Delivery Optimization as it is running

Measured by the Delivery Optimization service itself, not read from the registry. The mode here is the one actually in force, which can differ from the configured one - a device with no policy still runs in some mode.

What Delivery Optimization actually moved

A device can be configured perfectly for peer caching and still take every byte from the internet. Only the usage counters say which happened. The figures below cover the current calendar month, as Windows keeps them.

Effective configuration, and who set it

Read through Get-DOConfig, which reports the value in force together with the provider that set it. A registry sweep cannot do that: a documented default and a policy that happens to agree with it look identical there.

What the cache is holding

Each file Delivery Optimization is keeping, with how much of it came from a peer or a cache host rather than straight from the internet.

The cache is empty, or Delivery Optimization did not answer.

The services the update stack needs

Several of these are Manual by design and sit stopped between runs, which is normal. Disabled is the fault worth finding: a disabled service does not start on demand, and the stack then fails with codes that point anywhere but here.

Where the update stack keeps its working files

Measured, not estimated. A SoftwareDistribution folder that has grown without bound, or a system drive with no room left, stops the stack in ways the update history never names.

The channels that record what happened

Counts cover the analysis window. A channel that is off, or unreadable without elevation, is marked as such rather than reported as silent - an empty log and an unread log are not the same finding.

Update history

614 entries in the agent's history, 4 read here, 2 of them failed.

Hotfixes reported by QuickFixEngineering

QuickFixEngineering lists only part of what is installed on current Windows: feature updates, driver updates and anything delivered by the modern servicing stack do not appear. The Windows Update history below is the complete picture.

Application versions

Whether a version is the newest in absolute terms cannot be established from the device alone: that needs the vendor's own feed. What is shown is the installed version, whether updating is enabled, and - when -CheckAppUpdates was used - what winget reports as available.

Every file, where it came from, its size, its hash, and what it is useful for diagnosing.

Every file below sits in the Raw\ subfolder next to this report. The links are relative: they work as long as the report stays in its folder, or in the extracted archive.

26

Report 3

Collection issues

What the collector could not retrieve. Read this before concluding there is no problem: a missing source is not a healthy source.

Reading aids: the forms an error code takes, the prefix families, and diagnostic routes by symptom.

Reading an error code

The same code appears in three forms depending on the source: hexadecimal (0x87D1041C), unsigned decimal (2278622236) and signed decimal (-2016345060). They are the same 32 bits. This report always gives all three, because the Intune logs and the portal do not present the same form and you need to be able to match them.

The prefix names the emitting subsystem, which is often enough to know where to look:

Windows Installer exit codes

These decimal codes appear in the management extension logs and in application states. 1603 is the most common and the least informative: you always have to go down into the verbose MSI log to find the real cause.

Where to look, by symptom

• An application never arrives. The Application deployment section, then IntuneManagementExtension.log. Separate an installation failure from a detection failure first: the treatment is completely different.
• A policy has no effect. The Policies and conflicts section. Check that no other provider - and no GPO, in a hybrid environment - sets the same value.
• The device reports nothing any more. The Identity and enrolment section: MDM certificate, synchronisation tasks, then the clock and connectivity.
• Autopilot is stuck. The Autopilot section: the step where the deployment stopped, then the ESP tables and the trail of the ModernDeployment-Diagnostics-Provider/Autopilot channel.
• Scattered, inconsistent errors. Check the clock and TLS inspection before anything else: both produce dispersed symptoms that never point back at themselves.