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:
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).
- Open the policy and view the error, Remediation failed 2016281112 Error Code 0x87d1fde8
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:
- 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.
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
- 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
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
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
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.
Posted at https://sl.advdat.com/3liTt4b
