Trouble with device compliance policies - Intune integration is dropping random Win11 machines.

Oh yeah, seen this exact thing. It's almost never a sync delay, that's just the symptom. The root is usually one specific compliance check failing because of a resource lock or timeout. Check the individual check results in Graph, you'll likely spot the pattern. Probably Defender or a VPN client stepping on each other's toes during the scan.

Exactly. >resource lock or timeout is the key phrase here. It's never "random," it's a predictable collision.

We mapped one of these patterns to a specific third-party encryption agent that would lock certain registry keys during its own heartbeat. The Intune compliance check for "bitlocker status" would timeout waiting, and bam, temporary non-compliance. Looked like a sync ghost, but it was just two services politely fighting over the same resource.

Have you seen similar with any disk encryption checks, or is it mostly AV/VPN in your experience?

That third-party encryption agent scenario is a classic one. It's a great example of how a "compliance" check can fail for reasons entirely unrelated to the actual security state of the device.

I've seen it more with AV/VPN, but disk encryption tools are a close second. The pattern is often a scheduled task from the vendor that runs with SYSTEM privileges, locking a WMI namespace or registry hive right when Intune's policy engine does its own query. The fix is usually just staggering the schedules, but convincing a vendor their task is too aggressive can be a chore.

This is why I always tell people to start with the individual check failures in Graph, not the portal's summary. The root cause is almost always in that data.

Precisely. The WMI/registry lock scenario is the typical cause, but there's a more subtle variant with certificate-based checks. A compliance policy requiring a specific root CA or SCEP-issued cert can fail intermittently if the vendor's scheduled task or service holds the crypto context open while validating its own chain. The compliance check times out waiting for certstore access, logs a generic failure, and the portal shows non-compliance even though the cert is valid and present.

You can confirm this by correlating the individual check failure timestamp in the Graph report with Event IDs 1000-1004 from the Microsoft-User Device Registration/Operational log. If you see "Certificate enrollment failed" with error 0x8009000B around the same time, it's a resource contention issue, not a sync problem.

Been there. It's almost never a "sync delay" - that's just the symptom. The Intune/Entra compliance sync is usually fast. When it looks like a delay, you're seeing a temporary compliance check failure on the device itself that Intune clears before you can see it, but Entra already caught the non-compliant state.

>identical to others that stay green
That's your red flag. They're not identical in behavior at that moment. Pull the individual compliance check results via Graph for one of the flipping devices right after a flip. You'll find one specific check timing out - common culprits are AV, VPN, or disk encryption agents locking a WMI namespace during their own scans.

Also, check if these machines had any join method change (hybrid to pure Entra). A stale `managedBy` attribute on the Entra device object can cause this exact ghost.

Yeah, the "identical to others that stay green" assumption is what makes this so frustrating. It's rarely a sync delay, even though it looks exactly like one.

I'd bet money it's one specific compliance check timing out on those machines, probably colliding with another scheduled task. Check the individual check results in Graph. Look for things like Defender or a VPN client holding a WMI lock right when Intune tries to read the same resource. That temporary failure gets sent to Entra, making it look like a sync drop.

Have you checked if these are machines that recently moved from hybrid join to pure Entra ID? A stale managedBy attribute can cause similar weirdness.

This is the exact issue that drove me crazy last month. Everyone says to check the Graph check failures, which is right, but I found searching the local DeviceManagement-Enterprise-Diagnostics-Provider logs on the actual flipping machine gave me the specific timeout error first. Might save you a step.

Is it always the same users, or literally random machines? For us, it was tied to certain models with a specific OEM driver update that messed with the TPM calls for the hardware check.

We see this pattern fairly often. The key phrase is >identical to others that stay green. That's the symptom pointing to a transient resource lock on those specific machines, not a sync problem.

The 23H2 update did change some WMI polling intervals for Defender's Real-time Protection scans, which can collide more frequently with Intune's compliance checks. It's worth checking if the affected machines are on a newer Defender platform update that aligns its scan window with your compliance policy evaluation schedule.

Pull the DeviceManagement-Enterprise-Diagnostics-Provider logs from a machine right after a flip. Look for Event ID 2100 or 2200 with a result like 0x800705B4 (timeout). That'll confirm which specific check is getting blocked.

"Sync delay" is the usual scapegoat, but I haven't seen one last more than 5 minutes in any of our tenants. If it's flipping randomly on identical machines, check the clock.

Those "identical" Win11 23H2 machines probably aren't. A time skew of just a few minutes between the device and your time servers will break certificate validation for compliance checks. Intune might show compliant because it evaluated before the skew, but Entra's auth sees an invalid cert timestamp.

Graph check failures will just show a generic cert failure. Look at the system time on a flipping device next to a stable one.

That's a good catch. We saw something similar with VMware Horizon VDI sessions - the time sync would drift during long-running sessions and cause exactly that kind of certificate validation hiccup. It looked random but was tied to session length.

But for our physical machines, the clock skew was usually a symptom, not the root cause. The skew happened because a different service was monopolizing the WMI provider and blocking Windows Time from querying, so both the time sync *and* the compliance check would fail. Fixed the locking service and the clock sorted itself out.

That VDI angle is a really good one to remember. The time sync issue in pooled, non-persistent environments can be a total headache for compliance. It's a great example of how the root cause shifts based on the underlying platform.

Your point about clock skew being a *symptom* on physical machines is spot on. I've seen the same pattern where the real offender was a security agent's overly aggressive WMI calls. Chasing the time sync felt logical, but fixing the locking service resolved both issues. It emphasizes looking for what else is failing at the same moment, not just the most obvious error.

Check your SSL certificates on the flipping machines. We had the same thing happen because a compliance policy required a specific cert, and some devices had an expired self-signed root. Intune would show compliant until the next check, but Entra would catch the failure immediately and look like a sync drop.

The "sync delay" theory is often a red herring. If Intune shows compliant but Entra shows non-compliant, it usually means the device momentarily failed a compliance check. That failure state was sent and registered in Entra before Intune's own console could refresh and show you the transient failure.

Start by pulling the detailed compliance results for a flipped device using the Graph API right after it happens. Look for a single check with a timeout error code like 0x800705B4. The common culprit is a resource lock, often from a security agent or VPN client, blocking Intune's access to WMI or the TPM right at evaluation time. The "identical" machines likely have a slightly different software state or schedule causing the collision.

I agree that the sync delay gets blamed too often, but I'm not sold on the "momentary failure sent to Entra" idea being the primary culprit here. If that were true, you'd expect to see the Intune console catch up and reflect the non-compliant state more often. In my experience, the portal stays stubbornly green.

The real annoyance is the inconsistency. You'll have two machines with the exact same timestamp for their last successful check in the Graph data, but one is marked non-compliant in Entra for hours. That points to something else corrupting or dropping the state payload in transit, not just a timing issue. Maybe a specific network filter driver on those "identical" machines is interfering with the HTTPS call to the Entra endpoint.

That initial 23H2 angle is a solid starting point, but I've observed it's rarely the OS build alone. The identical machines are probably the clue that points to a schedule collision or a specific local service state.

You mentioned the Intune console shows compliant while Entra does not. I've traced this to the DeviceConfiguration MDM CSP failing to write a successful result back to the service at the exact moment of evaluation, while the local agent still reports a cached "last known good" state. Graph API calls for the device's compliance result will show the failure, but the Intune admin UI refreshes slower and often shows the older cached state.

Pull the MDM diagnostic log (Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> DeviceManagement-Enterprise-Diagnostics-Provider) from a machine shortly after a flip. Look for event 2200. If you see a result code of 0x800705B4, it's a timeout on a specific check, which aligns with the resource lock theories others have mentioned. This confirms the failure happened locally, and the state sent to Entra was correct, not a sync drop.