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

Symptoms to confirm

• 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.

Likely causes

Three kinds of sync keep a Windows device current.

• 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.

Checklist

1. 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.

2. 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

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

Watch out: Collect diagnostics is delivered through check-in, so it can't help with a device that isn't checking in; the action simply expires if the device doesn't pick it up within 24 hours. Collect locally instead: mdmdiagnosticstool.exe -area DeviceEnrollment;DeviceProvisioning -cab C:\mdm.cab, or Settings › Accounts › Access work or school › Info › Create report, which writes MDMDiagReport.html.

Verify

• 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.