Intune Troubleshooting: Follow the Device, Not the Portal

The single habit that separates a fast Intune diagnosis from a two-day ticket is this: the admin centre is not where the truth lives. It's a summary, assembled from several independent systems that each report in on their own schedule, through their own channel, with their own delay. When something looks wrong in the portal, refreshing it again doesn't get you closer to an answer. Going to the actual layer that owns that truth does.

This post is a map of that stack, nine layers deep, and exactly where to look at each one when something breaks.

User
 ↓
Windows
 ↓
MDM
 ↓
Intune
 ↓
Policy
 ↓
IME
 ↓
Application
 ↓
Detection
 ↓
Reporting

Layer 1: User

Before touching any Intune-specific tool, confirm the boring thing first: which account is actually signed in, and does that match who the assignment was built for. A configuration profile assigned to a user group does nothing for a device where a different account is logged in, and a device targeted directly ignores per-user targeting entirely. Run:

whoami /upn

Layer 2: Windows

This is the layer people skip past fastest, and shouldn't. The operating system has its own ground truth, completely independent of what Intune's portal claims happened. There's a genuine "gpresult for MDM" hiding in Settings: Settings → Accounts → Access work or school → Info → Create report, which exports a full diagnostic bundle to C:\Users\Public\Documents\MDMDiagnostics, including every applied Policy CSP setting, certificates, configuration sources, last successful check-in, BitLocker state, and whether any Group Policy is actively being blocked by an MDM policy.

For anything even more specific, verify the actual OS-level state directly rather than trusting any report about it:

manage-bde -status          # is BitLocker actually on, regardless of what any report claims

Layer 3: MDM

This is the channel the device uses to talk to Intune at all, and I've written an entire post on diagnosing it: what happens when a device stops checking in. The short version for this stack: run dsregcmd /status, confirm AzureAdJoined and AzureAdPrt are healthy, and check the EnterpriseMgmt scheduled tasks actually exist before assuming anything above this layer matters. If the device isn't reliably talking to Intune, every layer above this one is irrelevant until this one is fixed.

Layer 4: Intune (the Service)

Here's a layer most people assume is instantaneous and isn't: assignment evaluation itself has a real, measurable delay, and it depends entirely on how you're targeting.

Dynamic group membership evaluation runs asynchronously in the background. A device that was just renamed, or a user who just changed department, doesn't instantly reflect in a dynamic group's membership, and Intune can't assign what it doesn't yet see as a member.

Layer 5: Policy

The portal's compliance and configuration profile status is a binary summary: Succeeded, Error, or Conflict. The actual application happens setting by setting, through individual Configuration Service Providers (CSPs), and a profile can report "Succeeded" overall while one specific setting inside it silently failed.

MDMDiagReport.xml, part of the same diagnostic bundle from Layer 2, contains the real granularity: a status code per CSP, per setting, not just per profile. A non-zero code on one line is your actual answer, buried inside a report the portal only shows you the summary of.

Layer 6: IME

For anything that isn't a CSP-based configuration profile, Win32 apps, PowerShell scripts, Proactive Remediations, the Intune Management Extension is the layer doing the work, on its own separate roughly-8-hour cycle, with its own logs at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. A device can be perfectly healthy on the MDM channel above while this layer is stuck, or vice versa. Confirm each independently rather than assuming one implies the other.

Layer 7: Application

Once IME is confirmed healthy, the next question is narrower: did the install command actually run, and what did it report back. This is the exit-code layer I walked through in what actually happens after uploading a .intunewin file, running as SYSTEM in a non-interactive session by default. AppWorkload.log inside the IME logs above is the specific file for this layer, distinct from the general check-in logging.

Layer 8: Detection

This is the layer with the most misleading name in the entire stack, because "detected" doesn't mean "installed," it means "the detection rule matched." I've written a full post on exactly how this fails: MSI product codes, WOW6432Node redirection, the PowerShell STDOUT requirement, and the HKCU-under-SYSTEM trap. If Layer 7 shows a clean install but the app still shows as failed or missing, this is almost always where the real answer is, not a reason to reinstall the app again.

Layer 9: Reporting

This is the layer that explains why the entire premise of this post is true. What you see in the admin centre isn't a live feed, it's the end of a chain, and every link in that chain adds real, measurable delay:

A Worked Example

A real ticket: "Compliance policy still shows Not Compliant, but I fixed the setting 20 minutes ago."

The Field Guide

Nine rows, and every one of them answers a question the portal alone cannot. Learn which row a given symptom actually belongs to, and most Intune tickets stop being investigations and start being lookups.

Which layer do you find yourself jumping to first, out of habit, regardless of the ticket? For me it's almost always Layer 2, the device itself, before I've even opened the admin centre. Drop a comment below with yours.