Fixing Mobile Devices in Non-Compliant Status – MEM


This is John Barbare and I am a Sr Customer Engineer at Microsoft focusing on all things in the space. In this blog, I will be focusing on Mobile Devices in Non-Compliance status after applying a Security Update in Microsoft Endpoint Manager (MEM). With many of my customers switching over to MEM and onboarding mobile devices, sometimes we run into problems with non-compliant mobile devices after security updates and will spend hours the issue.  

In this article, we will walk through  the compliant problem after applying an example from an issue with the Android October Security Update or Samsung October Update for Samsung Knox or Android phones. 

Security Updates and Non-Compliance 

On Windows or macOS personally owned devices (BYOD), a similar problem could happen when there are Update Events or Enrollment Events.  

This problem is not new as it was specified by Microsoft Support on a Tech Community post. Even though this is an older post, the problem has possibly been repeated over time and may need a little bit of our attention with this blog. 

The below technique could be used to detect and fix the kind of errors that originated from the conflicted settings between Compliance Policy and Device Restriction Policy of Device Configuration Profile. These conflicts could be related to Bit Locker, Secure Boot, OS version, System Security (such as password or data storage ),  (Trusted Platform Module) requirement setting, Microsoft Antivirus settings, Threat Level, Jailbroken Device Settings, and more.  

The different conflicts of policy settings could happen to any mobile device's platform including IOS, macOS, Windows, Android and one could use the same technical principles to detect root causes and remediate the issues accordingly. 


There are Android Non-Compliance Devices after you have just applied the Android Security Update:

  • Go to Microsoft Endpoint Manager PortalAndroidAndroid Devices
  • Sort on Compliance column.

It will display that there were hundreds of BYOD/personal devices with the non-compliance status as seen below: 


If the Compliance Policies display the 201628112 Error on the BYOD devices:

  • Go to Microsoft Endpoint Manager PortalDevicesAndroidCompliance policies.
  • Choose the related Compliance Policy, (Android Enterprise, personally owned work profile).
  • Open the policy and view the error, Remediation failed 2016281112   Error Code   0x87d1fde8


  • In Compliance Policy, the “Required Password Type” setting is configured with “Device Default” value instead of other values such as “At least numeric,” “Numeric complex,” “At least alphabet,” … as shown in the following image: 
  • The “Device default” means that there is no evaluation for a password by Compliance Policy, but the device will continue using the default password type.  
  • This may prevent Device passwords to be enforced with the password policy specified by Device Restriction – Configuration Profile. If the device password length and complexity are not matched with the password policy required by Device Restriction (Configuration Profile), then the 2016281112 error will happen. 
  • This error usually comes from compliance policy for BYOD Android, macOS, and Windows desktop devices the Compliance Policy type is “personally owned work profile” where the administrator configure the relax setting “Device Default” as shown: 
  • In consequence, Users are prevented from synchronizing the device with Endpoint Manager's Policies and prevented from accessing Enterprise Resources. Also, Enterprise Apps may not work normally or fail to launch. 
  • IOS devices have no similar problem because they do not have the “Device default” setting in both Device Restriction Configuration Profile and Compliance Policy. 


For Android platform, Device Restriction of Configuration Profile  

Make sure that the Required Password Type is not set to “Device default” 

  • DeviceAndroidConfiguration Profile 
  • On the related Android Enterprise – Device restrictions policy, click to open it 
  • Properties 
  • Edit 
  • Password 
  • Required Password Type:  Change from “Device default” to any of the following or whatever your organization feels like is stricter: 

 For Android, Windows, macOS platforms with Compliance Policies 

Make sure that the Required Password Type is not set to “Device default” 

  • Device 
  • Choose the platform type: Android or Windows or macOS 
  • Compliance Policies 
  • On the related Compliance policy, click to open it 
  • Properties 
  • Compliance Settings Edit (click) 
  • System Security (expand) 
  • Making change to Required Password Type 

Users may be prompted for a new password. If you need to synchronize all the devices of the same platform, you could use PowerShell with a Microsoft Graph script from Github by MVP Michael Mardahl. Please see the disclaimer at the bottom of this blog post regarding using this script.  

Solution Result 

After the Policy Change was made, in my scenario, the Android Devices are automatically remediated, devices' compliance status for password was changed from “not compliant” to “compliant” and started synchronizing again. There is no pending status, no out-of-sync (no data) status, no remediation error status. Depending on the retry cycle of the devices, it may take from 60 minutes to a few hours. On some devices, there are prompted for password change. 


Thanks for taking the time to read this article and I hope you have a better understanding of Mobile Devices in Non-Compliance status after applying a Security Update in Microsoft Endpoint Manager. Hopefully, from now on you can address most of the compliance errors caused by conflicted settings among the Device Security and Device Compliance Policies. Hope to see you in the next blog and always protect your endpoints! Thanks for reading and have a great  day!  

Follow my Microsoft Security Blogs:  and also on LinkedIn.  



The sample are not supported under any Microsoft standard support program or service. The sample are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. 


This article was originally published by Microsoft's Secure Blog. You can find the original article here.