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

Ok so we also have this error for some devices for some customers.
This customer uses a password and PIN to sign-in. Lot's of them only use their PIN.
The password was recently changed (a few days), is correct and every application works with it.

I could fix the not compliant issue by locking the device and sign-in with the password instead of the PIN. Then rebooted the device and let the user sign-in with the password aswel instead of the PIN.

Started multiple syncs from the Settings > accounts > work/school > Emailadress > Info > Sync.

Suddenly, after 10m and many many many refresh of intune device page later the device came compliant =)

Answer 2

Change default windows compliance assignment group to device instead of user

Answer 3

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 4

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 5

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.