Intune device not checking in: diagnosing a Windows device that stopped syncing

A Windows device is still in daily use, but in the Intune admin center its last check-in is a week old, new policies never arrive, and the Sync action just sits there. In this post I'll explain how a Windows device actually talks to Intune, give you an order for checking the things that break that conversation, and be clear about the point where re-enrollment is the honest answer.

Symptoms#

• Devices › All devices shows a Last check-in that stopped updating, while the user confirms the device is online every day.
• The Sync remote action never completes, and the Device sync status tab on the device's overview page doesn't move.
• On the device, Settings › Accounts › Access work or school › Info › Sync fails, sometimes with "The sync could not be initiated (0x80072f9a)".
• Win32 apps and scripts may still work. The Intune Management Extension (IME) has its own check-in, so an MDM channel problem doesn't always stop it.
• Eventually the device drops to not compliant because it exceeded the compliance status validity period, and Conditional Access starts blocking the user.

Why it happens#

Three kinds of sync keep a Windows device current. Change-based syncs happen when Intune pushes a notification through Windows Push Notification Services (WNS) after you assign or change something. Maintenance syncs run on a schedule: roughly every 8 hours, with a limit of one maintenance sync per 6.5 hours. Newly enrolled devices sync every 3 minutes for 15 minutes, then every 15 minutes for 2 hours, then settle into the 8-hour cycle. Single-device syncs are the ones you or the user trigger from the admin center, the Settings app or the Company Portal.

Under the hood, enrollment creates a set of scheduled tasks in Task Scheduler › Microsoft › Windows › EnterpriseMgmt, in a folder named after the enrollment GUID. These tasks start the OMA-DM client on the schedule above and in response to a push. Each session authenticates with the MDM device certificate that Intune issued at enrollment (issuer Microsoft Intune MDM Device CA, stored in the computer's Personal certificate store, valid for one year and renewed automatically). Windows also relies on the Device Management Wireless Application Protocol (WAP) Push message Routing Service, dmwappushservice, which Microsoft documents as required for Intune management.

So a device stops checking in when one of these links breaks:

• dmwappushservice was disabled, typically by a hardening script or baseline. Microsoft's own troubleshooting article describes the result exactly: manual and admin-center syncs don't start, last check-in doesn't update, nothing is logged, and the IME keeps working.
• The enrollment scheduled tasks are missing, disabled or failing.
• The MDM device certificate is missing or expired, so every session fails authentication.
• The device identity changed: the TPM was reset or cleared, the device was re-imaged and re-enrolled (leaving a stale duplicate record), or the Entra device object was deleted.
• Network: a proxy or firewall blocks *.manage.microsoft.com, performs TLS inspection on it (not supported), requires authentication the SYSTEM account can't provide, or blocks the WNS endpoints so change-based syncs never arrive.

How to fix it#

1. Prove it isn't just offline. Trigger Sync from the device's overview page and ask the user to run Settings › Accounts › Access work or school › Info › Sync and Company Portal › Settings › Sync. If a manual sync works but automatic ones don't, suspect push (WNS) and the scheduled tasks. If nothing works, suspect the service, the certificate or the identity.
2. Check the service. Run this in an elevated PowerShell window:
   PowerShell

   Get-Service dmwappushservice | Select-Object Name, Status, StartType
   Set-Service dmwappushservice -StartupType Automatic
   Start-Service dmwappushservice

   Then sync again. If this was the cause, find the script or baseline that disabled it before it does the same on the next device.
3. Check the scheduled tasks. Open Task Scheduler and expand Microsoft › Windows › EnterpriseMgmt › {enrollment GUID}. The tasks created by the enrollment client should be enabled, and their last run result should be 0x0. Run the 8-hour maintenance task manually and watch Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin for a new session and the first error it logs. If the folder is empty or gone, the enrollment is broken and you're heading for step 7.
4. Check the MDM device certificate. Open certlm.msc and look in Personal › Certificates for a certificate issued by Microsoft Intune MDM Device CA. Check its expiry. If it's missing or expired, syncs can't authenticate and re-enrollment is the only way to get a new one.
5. Check the network path. Allow *.manage.microsoft.com, manage.microsoft.com, *.dm.microsoft.com, EnterpriseEnrollment.manage.microsoft.com and login.microsoftonline.com on TCP 443 (and 80 for the Intune client endpoints), exclude *.manage.microsoft.com and *.dm.microsoft.com from TLS inspection, and allow *.notify.windows.com and *.wns.windows.com for push. Remember that the MDM client runs as SYSTEM, so a proxy configured only in the user's profile isn't seen; netsh winhttp show proxy shows the machine-wide setting. Microsoft publishes a connectivity test script, Test-IntuneAFDConnectivity.ps1, on the network endpoints page.
6. Check the identity. Run dsregcmd /status: AzureAdJoined should be YES and MdmUrl should be populated. In the admin center, search by serial number; if you find two records, the newest one is the live enrollment and the stale one should be retired or deleted. Confirm the device still exists and is enabled in Entra ID. If the TPM was reset, Microsoft's guidance is unambiguous: the Entra identity lived in the TPM, so the device must re-enroll.
7. Re-enroll cleanly when you must. Pick the path that matches the join type:
   • Entra joined, corporate: retire or delete the stale Intune record, then reset the device and let Autopilot or OOBE enroll it again. If the device was Autopilot-provisioned before, unblock it under Devices › Device onboarding › Enrollment › Windows Autopilot › Devices first.
   • Entra registered (BYOD): in Settings › Accounts › Access work or school, disconnect the work account, delete the old record in Intune and add the account again.
   • Hybrid joined with Group Policy enrollment: disconnect the MDM enrollment from the same Settings page, delete the stale Intune record, reboot and let the auto-enrollment task run. If the task won't start and the Task Scheduler operational log shows event 7016 with error 2149056522, Microsoft documents the cause as a leftover key under HKLM\SOFTWARE\Microsoft\Enrollments from the previous enrollment; remove it and try again.

Verify the fix#

• Last check-in on the device's overview page updates within minutes of a manual sync, and keeps updating on its own afterwards.
• The Device sync status tab shows the sync completing, and the DeviceManagement-Enterprise-Diagnostics-Provider › Admin log shows sessions finishing without errors.
• A policy you assign shows up on the device at the next change-based sync, which confirms the WNS path as well as the scheduled one.
• Compliance returns to compliant once the device reports in.

Prevent it next time#

• Exclude dmwappushservice from any service-hardening script or baseline, and review scripts that disable services before you assign them broadly.
• Give the Intune, Entra and WNS endpoints a permanent exception from TLS inspection and authenticated proxies.
• Filter Devices › All devices by last check-in regularly so stale devices surface while the user still has the hardware, and use cleanup rules to remove the truly dead records.
• When hardware is re-imaged, retire the old record as part of the rebuild process rather than discovering the duplicate later.

References#

• Windows devices can't sync with Intune after enrollment
• Policy refresh intervals and common questions about policies
• Network endpoints for Microsoft Intune