2016345612(Syncml(500) - Intune Compliance Policy Error

Question

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)

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

Answer 1

Had the problem since I started using Intune for my clients. Devices will randomly fall out of compliance and get back compliant. Always the firewall and antivirus with Syncml(500) error. This will happen for domain devices, Azure only devices, pre-provisionned devices, etc... it doesn't follow any logic, it's just random. This is the reason why I will never make a CA policy for compliant devices.

Answer 2

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

Answer 3

What is your current AV solution and what is it status locally, any warnings?

I would suggest to re-create and re-deploy the compiance policy to test it our, will that solve your problem.

Answer 4

Hi,

Thank you for posting in Microsoft Q&A forum.

Please install the latest windows update and re-sync from the client to have a try. Also ensure the Anti-Virus software is up to date. Sometimes, outdated software can cause compatibility issues.

Similar thread for your reference: Compliance failing because Firewall not detected

Thanks for your time. Have a nice day!

Best regards,

Simon

---

If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 5

Seems that the problem is resolved.

We had to reset the laptop and let it hybrid join and sign to intune again.

The only difference this time is that we had the laptop connected to the network by cable and not over wifi but I think that has nothing to do with the fact it worked.

Another odd thing we were getting before and didn't mention is that there

was a message that can't access company resources because Windows defender antimalware real time protection is off...something that apparently wasn't true. That caused the laptop to show as non compliant.

Luckily by redoing the whole process on a formatted laptop worked this time.