2016345612(Syncml(500) - Intune Compliance Policy Error

Craig Pennington 325 Reputation points
2023-09-05T13:23:04.57+00:00

We have had this recurring issue for a long time now, and despite searching the error all over the place, there seem to be a lot of other IT professionals in the same boat, but no obvious answers.

The error is on the Anti-Virus setting on the default compliance policy.

2016345612(Syncml(500): The recipient encountered an unexpected condition which prevented it from fulfilling the request)User's image

The compliance policy in question is assigned to all users.

This is a very annoying issue as it stops users from being able to access any MSFT apps as it marks the device as non compliant.

we are forced to add users to the exclusion list of the policy until the error clears on it's own days/weeks later.

If anyone has any ideas on what could be the cause or any possible fixes, it would be greatly appreciated

Microsoft Security | Intune | Compliance
Microsoft Security | Intune | Other

23 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Mathias Heidrich 5 Reputation points
    2025-02-05T13:12:49.3766667+00:00

    Hello, I have deposited the following remediation script in Intune. The commands can also be easily executed in Powershell.

    Get-ScheduledTask | ? {$_.TaskName -eq 'Schedule #3 created by enrollment client'} | Start-ScheduledTask

    Start-Process -FilePath "C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe" -ArgumentList "intunemanagementextension://syncapp"

    Start-Process -FilePath "C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe" -ArgumentList "intunemanagementextension://synccompliance"

    However, I prefer devices to report to the MDM immediately after user login and perform a sync. To do this, I create another task on my clients, which also calls the deviceenroller.exe. The challenge here, however, is that each device has a unique enrollment ID, which must be given as a parameter when it is called, which is the GUID maintaining the key "EnterpriseMgmt". Here's my two-liner Powershell for this:

    $EnrollmentID = Get-ScheduledTask | Where-Object { $_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt\*" } | Select-Object -ExpandProperty TaskPath -Unique | Where-Object { $_ -like "*-*-*" } | Split-Path -Leaf

    schtasks /create /tn "Intune Policy Sync" /sc ONLOGON /delay 0005:00 /rl highest /ru system /tr "C:\Windows\system32\deviceenroller.exe /o $EnrollmentID /c /b"

    First, the enrollment ID of the device is laid out and then a planned task is created accordingly. This is executed 5 minutes after the user login on the device and does an Intune Device Sync in the background.

    I noticed that the easiest method to fully recognize the difference in device check-ins, is by using the Event Viewer. When opening the Event Viewer, simply navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider and look at for Event ID 208. The difference will be in the origin of the started session, as shown in the following list:

    • A notification – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x7), Initiator: (0x0), Mode: (0x2), SessionID: (0x7C), Authentication Type: (0x3).
    • A scheduled check-in – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x3), Initiator: (0x0), Mode: (0x2), SessionID: (0x75), Authentication Type: (0x3).
    • A manual check-in (by using Settings panel) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x5), Initiator: (0x0), Mode: (0x2), SessionID: (0x76), Authentication Type: (0x3).
    • A manual check-in (by using Company Portal app) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0xD), Initiator: (0x0), Mode: (0x2), SessionID: (0x77), Authentication Type: (0x3).

    Was this answer helpful?

    1 person found this answer helpful.
  2. Tyler Huggins 0 Reputation points
    2025-05-29T16:59:14.2566667+00:00

    I discovered another potential cause of this error.

    In my case, the affected device had received the compliance policy via dynamic device group, but had later been removed from that group. Once it was added back to the group and synced, the error disappeared and the device was compliant again.

    If your affected device is no longer in a group needed for the initial compliance policy assignment, make sure to add the group back (or if dynamic, update the dynamic membership rules to include the device).

    Was this answer helpful?

    0 comments
  3. Smith, Lachlan 0 Reputation points
    2026-05-01T01:06:14.4366667+00:00

    A bit late to the conversation sorry. I had this issue on one of our compliance policies. We have ours setup into an immediate and a 24hr delay.
    Immediate
    User's image

    and 24hrs User's image

    At first the firewall had this syncml issue however we also had bitlocker failed to encypt. Once the bitlocker was encrypted for silent encryption (i missed some components for it) (https://learn.microsoft.com/en-us/intune/device-configuration/endpoint-security/encrypt-bitlocker-windows#configure-silent-bitlocker-encryption), it then encrypted, did a Check Access in CP, rebooted, did another sync and the Immediate was working. The FW was then resolved by doing another sync in CP, restarting. To help I was using the event logs in Apps and services > MS > windows > deviceMGMT-Ent and looking there for the warning 2750 for (WSC_security_provider_firewall). After the last sync locally, the event logs no longer showed the 2750, i redid a check access in CP and it then synced back to Intune.

    TLDR: I suspect FW was being prevented from working due to bitlocker not encypting.... No idea why though.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.