What Happens When an Intune Device Stops Checking In?

"LAPTOP-042 hasn't checked in for two weeks" is the single most common Intune ticket, and also one of the least useful sentences in IT. It describes a symptom that at least five completely unrelated failures can produce: a dead network path, a blocked push notification, an expired certificate, a disabled scheduled task, or a genuinely broken agent. Treating "hasn't checked in" as one problem is why these tickets sit open for days.

This post walks through what "checking in" actually is, mechanically, then works through each place that mechanism can break, with the actual commands and logs to tell them apart, and finishes with a real diagnostic session on a specific device.

What "Checking In" Actually Means

A Windows device talks to Intune over OMA-DM, the same device management protocol used across the MDM industry, not something Microsoft invented just for Intune. Two independent triggers cause a check-in:

The MDM Channel

The actual client-side piece doing this work is the device's built-in enrollment client, and its trust in Intune rests entirely on a certificate issued during enrollment, commonly referred to as the MS-Organization-Access certificate. No valid certificate, no trusted channel, no check-in, regardless of how healthy the network connection is.

The first command to run on any device that's stopped checking in isn't an Intune command at all:

dsregcmd /status

Three fields matter most:

If AzureAdPrt is NO, the device failed to get a Primary Refresh Token from Entra ID, which breaks far more than just Intune. If AzureAdPrtUpdateTime is stale by more than roughly four hours, something is preventing token refresh, and that's worth chasing before touching anything Intune-specific.

Intune Management Extension

Since this runs on its own separate cycle, it needs its own separate check. If the main MDM channel above looks healthy but Win32 apps or scripts still aren't running, the IME's own logs at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs are the next stop, specifically IntuneManagementExtension.log for its check-in behaviour, not the OMA-DM diagnostics covered above.

Scheduled Tasks

Every check-in, on either channel, ultimately runs through Windows Task Scheduler. Open Task Scheduler Library → Microsoft → Windows → EnterpriseMgmt → <enrollment GUID> and you'll find the tasks actually responsible for this:

• PushLaunch: wired to fire the moment a specific system-level notification (WNF_ENTR_PUSH_RECEIVED) is raised. This is what actually reacts to the WNS push described above, launching the enrollment client to check in immediately.
• Schedule created by enrollment client: the periodic poll described earlier, plus a short-lived version that runs every 5 minutes for the first day after a Group Policy refresh, specifically to catch auto-enrollment quickly.

Sync

Understanding the mechanism above makes the "Sync" button in the Intune portal much less mysterious: clicking it does not talk to the device directly. It asks Intune's service to send a WNS push notification, which the device's PushLaunch task is waiting for.

This gives you a genuinely useful diagnostic split:

Logs

Three tools cover almost every case:

Network Connectivity

Intune's own documentation is specific about two things that break silently rather than loudly:

• manage.microsoft.com and *.manage.microsoft.com do not support SSL inspection. A corporate proxy that intercepts and re-signs TLS traffic for security scanning will break the MDM channel without necessarily throwing an obvious error, the connection just quietly fails or the certificate chain doesn't validate.
• Some actions specifically require unauthenticated access to manage.microsoft.com, *.azureedge.net, and graph.microsoft.com. A proxy that forces authentication on all outbound traffic can block exactly the requests that need to bypass it.

Entra ID Registration

The certificate mentioned earlier isn't permanent. It has a real lifecycle:

This is why a device that's been powered off or off-network for a long stretch, a laptop left in a drawer during extended leave, a device shelved during a hardware refresh, can come back online and never recover on its own. Past that 40-day cliff, no amount of network connectivity fixes it; the device needs to be re-enrolled.

Compliance Evaluation

Here's the gotcha that catches people who jump straight to the compliance report: a device that's stopped checking in does not immediately show as non-compliant. Compliance state reflects the last successful evaluation. A device that went quiet 10 days ago can still show "Compliant" today, not because it's healthy, but because nothing has told Intune otherwise since its last real check-in.

That's a different problem from the one covered in why compliance reporting and compliance state aren't the same thing. A stale "Compliant" status isn't evidence of health, it's evidence of silence. Cross-reference last check-in time against compliance state before trusting either one in isolation.

A Real Diagnostic Session

Here's how this actually plays out on a real ticket: "LAPTOP-042, last check-in 15 days ago."

Five steps, each one either confirming or ruling out an entire category from the sections above, is a much shorter path than guessing and re-enrolling devices one at a time hoping something sticks.

The Full Diagnostic Flow

Work through it in that order and "hasn't checked in" stops being a vague, days-long mystery. It becomes one specific, confirmable answer, usually inside the first three steps.

What's the most common root cause you've actually found behind a "hasn't checked in" ticket in your own environment? I'd guess SSL-inspecting proxies are more common than most admins realise. Drop a comment below.