Fixing Mobile Devices in Non-Compliant Status – MEM

Published Nov 21 2021 09:10 PM 1,714 Views
Microsoft

Introduction 

 

This is John Barbare and I am a Sr Customer Engineer at Microsoft focusing on all things in the Cybersecurity 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 troubleshooting the issue.  

 

In this article, we will walk through troubleshooting 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 encryption), TPM (Trusted Platform Module) requirement setting, Microsoft Defender 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. 

 

SYMPTOMS: 

 

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

  • Go to Microsoft Endpoint Manager Portal\Android\Android Devices 
  • Sort on Compliance column. 

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

 

John_Barbare_0-1636498280387.png

 

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

  • Go to Microsoft Endpoint Manager Portal\Devices\Android\Compliance policies. 
  • Choose the related Compliance Policy, (Android Enterprise, personally owned work profile). 

John_Barbare_1-1636498280347.png

 

 

  • Open the policy and view the error, Remediation failed 2016281112   Error Code   0x87d1fde8 

 

John_Barbare_2-1636498280395.png

 

  

ROOT CAUSE 

 

  • 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: 

 

John_Barbare_4-1636498280404.png

 

 

  • 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: 

 

John_Barbare_5-1636498280361.png

 

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

 

SOLUTION 

 

For Android platform, Device Restriction of Configuration Profile  

 

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

  • Device\Android\Configuration Profile 
  • On the related Android Enterprise – Device restrictions policy, click to open it 

 

John_Barbare_6-1636498280410.png

 

  • Properties 
  • Edit 
  • Password 

John_Barbare_7-1636498280367.png

 

 

  • Required Password Type:  Change from “Device default” to any of the following or whatever your organization feels like is stricter: 

 

John_Barbare_8-1636498280370.png

 

 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 

 Force Synchronize for the problem devices. 

 

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. 

 

Conclusion   

   

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 Cybersecurity day!  

 

Follow my Microsoft Security Blogs: http://aka.ms/JohnBarbare  and also on LinkedIn.  

 

References 

 

Android Enterprise compliance settings in Microsoft Intune | Microsoft Docs 

Android passwords may not be enforced when selecting the "device default" password type. - Microsoft... 

Error -2016281112 deploying password policy - Intune | Microsoft Docs 

iOS/iPadOS device compliance settings in Microsoft Intune | Microsoft Docs 

macOS device compliance settings in Microsoft Intune | Microsoft Docs 

Script from Github 

Windows compliance settings in Microsoft Intune | Microsoft Docs 

 

Disclaimer: 

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts 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 scripts 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. 

 

4 Comments
Co-Authors
Version history
Last update:
‎Nov 21 2021 09:10 PM
Updated by: