This week’s mail sack question is from David Berner via email:
Question: Quick question on compliance policies for iOS. If I add a second compliance policy and only target a subset of devices, when the second compliance policy is assigned, do the devices ever go into a weird evaluation state that could impact access to resources? Example: using conditional access to check for compliance and want to add a second compliance policy to a subset of devices for a prohibited app. What actually happens when the policy is targeted to those subset of devices? Do they remain compliant until something is flagged which would mark the device non compliant?
Answer: The short answer for David is “No — devices will stay in their current state”, Devices that were “Compliant” before the targeting change will stay that way until they check-in with Intune, receive the latest compliance policies and do the compliant/not-compliant evaluation.
How compliance policy targeting works:
Compliance policy targeting works almost exactly the same as any other type of policy in Intune in that it is check-in based. The high-level process is something like this:
- You change some aspect of targeting in the Intune portal (or AAD by adding members to targeted groups)
- Intune computes policy for a target device
- Device checks-in and asks for the newest policy changes
- Intune marks device as “compliant” or “not compliant” in Intune and Azure AD
If you’ve set up Azure AD Conditional Access policy to “require compliant devices”, Azure AD will look at that attribute and block or allow access to the resources you’ve protected.
When it doesn’t work like that..
It can sometimes get a bit more complex and nuance than that though… the two cases that come to mind are Grace periods and External compliance signals:
- Grace periods: Intune lets you configure compliance grace periods, which means you can give users a set amount of time to resolve issues before marking the device as “not compliant” and locking them out via conditional access. If you’ve configured a grace period, and a device doesn’t meet the criteria in all the new policy that it received during a check-in, it will report as “In grace period” in the compliance reports and then change to “not compliant” if not resolved within the specified number of days.
- External compliance signals: Intune lets you wire up external systems to help calculate device compliance, completely outside the check-in process. For example, Windows “Device Health” compliance settings are wired up to the Windows Device Health Attestation service to report in Bitlocker, Secure boot and code integrity status for a device, Mobile devices can be wired to 3rd party Mobile Threat Detection (MTD) services to provide a “Device threat level” signal into the mix, or you can connect Intune to one of many 3rd party MDM partners (JAMF, VMWare etc) to be completely responsible for device compliance, just sending the “compliant/non compliant” signal to Intune. In all of those cases, there is some overall compliance calculation happening in the background while devices are not actively checking in with Intune.
This was a short and sweet post answering the “What the heck is going to happen?” fear that most of us have when working with large changes in production environments. I cleared up some of that fear by explaining that device compliance will only change once the device has checked in, got the new policy and reported back a new state and added a few details on scenarios where this could work differently.
Hope this information to helps bolster your understanding of Intune and compliance targeting but please TEST, TEST, TEST, before doing any big changes in production that could have unwanted impact, such as blocking access to corporate resources based on an unexpected compliance calculation.
Learning Microsoft Intune
Originally published as "Learning Microsoft Endpoint Manager", this essential Intune ramp-up guide has been updated and…