Navigating the Microsoft Intune console: What to do when results conflict (and which to believe)

If you manage more than a handful of tenants, you’ll eventually see it: Intune says a device is compliant, but a policy shows “error”. Windows Update rings say “up to date”, while a patch report shows missing KBs. BitLocker is “on” in one place and “unknown” somewhere else. Who’s right?

Short answer: they can all be right just at different times, from different data pipelines, with different scopes. Here’s how to untangle it fast, and when to trust which signal.

Why conflicts happen (in plain English)

• Different data paths, different clocks. Compliance and configuration reports aren’t built from the same feed. Some data is near-real-time (service side), some is client-reported (check-in cadence), and some is stitched from other services (Defender for Endpoint, Windows Update, Azure AD).
• Scope & targeting quirks. Two policies touch the same setting; assignment filters or scope tags hide the culprit; group membership hasn't been evaluated yet.
• State vs. truth. A device can be encrypted while the service thinks it’s still encrypting because the last heartbeat hasn’t landed.
• Stale/duplicate records. Re-imaged or renamed devices, co-management with ConfigMgr, or autopilot resets can leave ghost entries that muddy the picture.

A quick triage flow (use this every time)

1) Check the timestamp, not just the status.
Open the object and read the “last check-in” or “last updated” time. If one pane is hours behind, it loses the argument.

2) Confirm targeting really applies.
Open the policy/profile → Assignments. Expand filters and exclusions. Look for a second policy touching the same setting (baseline vs. settings catalogue is a classic collision).

3) Ask the device.
Where possible, verify locally (e.g., manage-bde -status for BitLocker, Windows Update history, AV health). If the device contradicts the portal and its clock is current, the device usually wins.

4) Compare services like-for-like.

• Patch status: prefer the Windows Update (WU/Autopatch) view by device over a roll-up that might be delayed.
• AV/EDR: Defender for Endpoint is typically the source of truth for protection state; Intune reflects what it last heard.
• Compliance vs. configuration: compliance tells you “is it within your defined rules now?”; configuration tells you “have the settings applied?”. If compliance is green and config is red, you’ve probably set the rule to tolerate a grace period.

5) Kill the doppelgänger.
If you suspect dupes: compare device IDs, join type, and last check-in. Retire/delete the stale record after you confirm the active one.

Common conflicts and what to trust

BitLocker: “Encrypted” here, “Not compliant” there

• Trust: the device (manage-bde -status) and Defender security baseline status.
• Likely cause: policy applied after encryption, escrow not yet posted, or reporting lag. Give it one check-in cycle; if still wrong, re-trigger key escrow.

Patching: Update ring says compliant, report shows missing KB

• Trust: Windows Update per-device history and MDE software inventory (if present).
• Likely cause: supersedence (the KB is replaced) or the report is a delayed roll-up. Refresh and confirm on the endpoint.

Compliance green, configuration red

• Trust: Compliance for the present user risk posture (it obeys your grace settings).
• Likely cause: two profiles set the same knob differently. Resolve policy conflict or merge settings.

App install “succeeded”, Company Portal still pending

• Trust: Intune app install status with the latest timestamp.
• Likely cause: user-context app vs. device-context confusion, or the portal cache. Restart Intune Management Extension; verify install detection rules.

AV status healthy, Defender portal shows old definitions

• Trust: Defender for Endpoint for definitions/engine.
• Likely cause: device was offline during last sync; wait for MDE heartbeat or force a security intelligence update.

How to prevent conflicts recurring

• Set and publish your “truth table”.
  For your team, define which service is authoritative per signal (e.g., BitLocker → device/MDE; patches → WU per-device/MDE; compliance → Intune Compliance policy).
• Reduce overlap.
  Don’t set the same setting in multiple places (e.g., security baselines and settings catalogue). One owner per control.
• Tighten check-in expectations.
  Agree a device heartbeat SLO (e.g., every 8 hours). Escalate anything that hasn’t reported inside that window.
• Label and clean.
  Use a “stale-candidate” tag for devices with no heartbeat in 30 days. Review and retire monthly.
• Use assignment filters instead of sprawling groups.
  They’re easier to reason about and audit when conflicts appear.

Doing this across tenants? Use Eido as the arbiter

Eido pulls Intune (and related) signals into a single, normalised view across all your tenants. That means:

• Policy drift and setting collisions show up fast, so you fix the right policy.
• Alerts trigger when reality and the portal part ways (e.g., BitLocker off, TPM < 2.0, Secure Boot disabled), routed straight to Teams/Slack/ServiceNow.
• Stakeholder reports speak plainly: “Compliant now vs. configured state vs. devices needing attention.”

Summary

Conflicts aren’t bugs so much as timing and scope. Check the timestamp, verify targeting, confirm on the device, and use the right service as source of truth for each signal. Then put guardrails in place so the same issues don’t come back.

See your own truth table in one place.
Plug your tenants into Eido, open the Estate Health and Policy Drift views, and you’ll know which results to trust and why.

Next step: Try Eido on your estate (free trial) or book a 15-minute walk-through to see how it handles Intune conflicts at scale.