Windows devices stopped syncing with Intune?

Remediate Intune Windows 10 Device Sync Issue

This blog post sheds light on how you can proactively solve Windows 10 device sync issue in an Intune environment.

But before we get started, it is important to understand the background of this blog post.

Understand the context for Intune device sync issue

If you are managing Windows 10 endpoints with Microsoft Endpoint Manager (Microsoft Intune), from the security and manageability perspective, It is important to ensure that the managed endpoints are regularly syncing with the management service.

Though in reality, it is very common to find devices having irregular (old to very old) check-in dates.

Generate a device report from the MEM Admin center to check and you would be actually surprised to see the number of devices that have not checked in with the service for more than a week or maybe even more.

There can actually be several reasons for a managed device to stop syncing with Intune, like

  • user not active, or
  • Intune license gets revoked from user account due to any reason, or
  • the device falls off the network grid, or
  • the device is not being used actively by the user on account of multiple enrolled devices, or
  • the device is registered to more than on organization [enrolling/registering device into multiple organization is not supported], or
  • the device object is actually not an active entry but a stale object on account of failed provisioning attempt, etc.  

Further, Intune MDM communication with the managed Windows 10 endpoint heavily relies on the Windows Notification Services (WNS).

Many organization uses Firewall or Proxy to block unwanted network traffic and ports, and as such if the correct network configuration is not in place, can result in blocking Windows Notification Service communications. Do note that WNS Push Notifications does not support proxy connection. WNS must be able to use a direct connection via port 443.

If your scenario matches with any of the above, then it is actually not a service-end issue with MEM Intune.

However, there are cases where you will find that the device(s) just stops syncing with Intune even if none of the reasons mentioned applies. These are the devices that become a cause of concern for IT from the manageability and security perspective and as usual, become the focus for this blog post.

Why do Windows 10 devices may stop syncing with Intune?

If you know how the MDM client works on Windows 10, you would probably know that it uses scheduled tasks (set during device provisioning) to handle/perform sync operations.

  • When you initiate a remote sync from Intune, the WNS push notification received by the client triggers the PushLaunch task (invokes deviceenroller.exe) which in turn triggers the Schedule to run OMADMClient by client task (invokes OMADMClient.exe) which then completes the sync action.
  • If you wait it out to let the device sync at the normal Intune sync interval of 8 hours, you will see the Schedule #3 created by enrollment client task getting triggered (invokes deviceenroller.exe) which in turn will trigger the Schedule to run OMADMClient by client task (invokes OMADMClient.exe) to complete the sync action.
  • For a manual sync action initiated from the Company Portal app on the endpoint, you will see the WNS push notification received by the client triggers the PushLaunch task (invokes deviceenroller.exe) which in turn triggers the Schedule to run OMADMClient by client task (invokes OMADMClient.exe) which then completes the sync action.
  • For a manual sync action initiated from the Windows Settings menu (from the Work Account Info page), you will notice only the Schedule to run OMADMClient by client task getting triggered (invokes OMADMClient.exe) to complete the sync action.

But the device check-in activity (OMADMClient.exe) has a functional dependency on a particular service.

The Device Management Wireless Application Protocol (WAP) Push message Routing Service (dmwappushsvc) is required for the Intune managed devices to sync with the Intune service.

By default, the dmwappushsvc service startup type is set to Automatic (Delayed Start, Trigger Start) meaning

  • the service will start automatically (delayed) at boot, and
  • it may also start or stop in response to specific operating system events (like the scheduled tasks which handles the sync operations).

If the dmwappushsvc service gets disabled on the endpoint due to any reason (mostly due to 3rd party software install events), it results in the device stops syncing with Intune service.

You can verify this by disabling the service and then try running manual sync from the device. The Sync action will not complete and neither will you get any corresponding error events for this in the Windows Events.

How to solve this Intune Windows 10 device sync failure due to disabled DmWapPushService?

Even though the DmWapPushService getting disabled on the endpoint impacts the device check-in activity with Intune MDM service, however, it has no impact on the Intune Management Extension, if it is also present on the device.

Because the Intune Sidecar architecture is a completely separate service running in parallel with the Intune MDM service, you can easily utilize the Intune Management Extension to recover a Windows 10 device that has stopped syncing with Intune due to DmWapPushService getting disabled on the device.

On a device where Intune sync is working fine, export the working registry configuration for the dmwappushservice

Invoke-Command  {reg export 'HKLM:\SYSTEM\CurrentControlSet\Services\dmwappushservice' 'C:\dmwappushsvc.reg'}

You can find the imported .reg file to the location as specified in the command.

Next, create a PS script that will

  • Save the working dmwappushsvc.reg file on the endpoint to a specified location for later use [this is because IMECache content gets purged post successful execution]
  • Import the registry to the endpoint

A very rough implementation of the same is below

If (Test-Path -LiteralPath 'variable:HostInvocation') { $InvocationInfo = $HostInvocation } Else { $InvocationInfo = $MyInvocation } [string]$mypath = Split-Path -Path $InvocationInfo.MyCommand.Definition -Parent

Copy-Item -Path "$mypath" -Destination "C:\ProgramData\DmWapPushService" -Recurse

$startprocessParams = @{
    FilePath     = "$Env:SystemRoot\REGEDIT.exe"
    ArgumentList = '/s', 'C:\ProgramData\DmWapPushService\dmwappushsvc.reg'
    Verb         = 'RunAs'
    PassThru     = $true
    Wait         = $true
}

$proc = Start-Process @startprocessParams

if ($proc.ExitCode -eq 0) {
    Exit 0
}
else {
    $ExitCode = $($Proc.ExitCode)
    Exit $ExitCode
}

Once you have the script created, save it to a new folder. Also, bring the exported dmwappushsvc.reg file to this new folder.

Now you can prepare a .Intunewin out of these and deploy the same as a Win32 app from Intune.

Use Proactive Remediation to remediate Windows 10 device sync issue with Intune

However, though you can make a Win32 app rerun by making manual changes to the app in the portal, still because of the manual effort required, it is good as a one-time fix only.

But what if you could monitor the status of the DmWapPushService on the managed endpoints on a periodic schedule?

This is where Endpoint Analytics with its Proactive Remediation comes in handy, helping you to periodically check the state of DmWapPushService on the managed endpoint (and remediate if necessary), thereby proactively remediating device sync issues.

If you are an EMS (E3/E5) license subscriber and not using the M365 (F3/E3/E5) licensing, then to use Proactive remediation in MEM, requires you to have Windows 10 enterprise (E3/E5) licensing separately.

Considering you have the proper licensing in place to be able to utilize Proactive remediation in your MEM environment,  you can create a device sync remediation script package as below.

Sample Detection Script

$DmWapPushSvcState = Get-ItemPropertyValue -Path "HKLM:\SYSTEM\CurrentControlSet\Services\dmwappushservice" -Name "Start"

if ($DmWapPushSvcState -eq '2')
{
	Write-Output "DmWapPushSvc is in Enabled state"         
	exit 0
}
else
{
    Write-Output "DmWapPushSvc is in Disabled state"
    exit 1
}

Sample Remediation Script

Invoke-Command {reg import "C:\ProgramData\DmWapPushService\dmwappushsvc.reg" *>&1 | Out-Null}

$DmWapPushSvcState = Get-ItemPropertyValue -Path "HKLM:\SYSTEM\CurrentControlSet\Services\dmwappushservice" -Name "Start"

if ($DmWapPushSvcState -eq '2') 
{
        exit 0
} 
else
{
        Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\dmwappushservice" -Name "Start" -Value '2'
        exit 1
}

Wrap Up

That was all for today. Thanks for reading!

Additional Resources

2 Comments

  1. HI Joy, good information.
    Do we have to use win32 method along with Endpoint Analytics or just any one will be fine?

    • Hi Ganesh,

      Anyone is fine, but if you have the licensing to support proactive remediation, I would suggest the later.
      Still, you would need the Win32 app to be deployed for the .reg file to be there on the system.

Comments are closed.