This time a blog without me doing some shoveling but only some explanation about some stuff. It will be about the underestimated built-in Intune device compliance policy
I realized that after reading a question on the TechNet community I didn’t have any blog about this topic.
1. Taking a first look
When you are using Conditional Access and you are also requiring compliant devices (obviously without grace periods :P) to access Microsoft 365 it’s important to also beware of the built-in Device compliance policies. Even when those are the built-in compliance policies, in my opinion, it’s good to know how these compliance policies work and of course what they could break.
I guess it’s time to take a look at which policies I am talking about
There are 3 Windows built-in compliance policies, so I guess I will need to split up this part into multiple sub-parts to explain them one by one
1.1 Introduction
Before I show you the 3 built-in compliance policies, we need to be aware of 1 very important item. The device needs to be enrolled into Intune to be “measured” and “compliant,” as mentioned in this blog!
Azure Ad joined vs Azure Ad Registered | AADR vs AADJ | PRT (call4cloud.nl)
1.2 Enrolled User exists
I guess this one sounds obvious. The user who enrolled/registered the device should still exist! Intune checks if the device has an existing and licensed user assigned to it (Primary User). When you delete the user who enrolled the device then there is no longer a valid user assigned to it. When this is the case you now luckily have the option to change the UPN (User Principal Name). You could change the user by opening the “preferences” tab in the device pane and clicking on “change primary user”
1.3 Has Compliance policy assigned
This one also sounds quite easy. But let me tell you some more about the built-in “Has Compliance policy assigned?”
When first starting to use Intune, there aren’t any custom-made Windows Compliance policies. I guess it’s pretty obvious it’s best practice to create some additional compliance policies so you can make sure you have at least assigned one compliance policy to your devices. One of them should be a compliance policy to require Bitlocker DHA to be enabled on the device to be compliant
Device Health Attestation Flow | DHA | TPM | PCR | AIK (call4cloud.nl)
It’s not only best practice to create some additional compliance policies but if you don’t create them you could run into some other compliance errors. I will show you what errors you could receive in part 3 of this blog.
While discussing this specific built-in compliance policy, let’s extend it a little bit more. Did you happen to read the text when opening the “Compliance policy Settings” in Intune? It mentions something about the “built-in device compliance policy,” which I am discussing in this blog!
This setting below “mark devices with no compliance policy assigned as” is default configured to “compliant”.. Mmm sounds like something like “Has a compliance policy assigned”
You need to change this setting from the default setting, Compliant, to Not Compliant to ensure that all of your devices have a compliance policy assigned. Otherwise, you could end up with a device that does not meet your company’s compliance requirements but can still access the Microsoft 365 Data.
Some additional advice: When creating additional compliance policies, make sure you are targeting users rather than devices.
As shown above, your compliance policies need to be assigned to “All users” if not, they could break. In the past, there was NO virtual “all devices” group but Microsoft seemed to change that. With this change we “could” assign the compliance policy to “All Devices” but do we want it? I will show you the “why” in the part 2.3
Please Note: The built-in device compliance policy is applied on “All devices” in addition to your own created compliance policies!
1.4 Is Active
Is active as in “Is Active”…. Who is active? The User? The Device? As told in the “has a compliance policy assigned” this built-in compliance policy is assigned to devices.
It’s probably best when thinking about the “Is active” compliance policy, to think about the “Last check-in date” of the device
Devices that don’t report the status within a specific time period (default value is 30 days) are treated as non-compliant. Again, looking back at the “Compliance policy settings”, we will notice the “Compliance status validity period”
As shown above, it looks like the amount of “Is active” setting we are talking about? Please Note: The minimum validity period is one day and the maximum amount of days is 120! While reading other blogs about this topic, something caught my eye on an older GitHub page
It’s mentioned that: The background task to report this “Is Active” report runs once a day. Okay? Which background task? Why is it removed from this official MS-Doc? Still not sure
Please beware when changing the validity period. This change will affect all of your devices and could result in a Not Evaluated error.
But then again it also could fix things. When a device shows “not compliant” in the “is active” policy you could change this compliance status validity to 35 days for 1 day and change it back to 30. I am not saying it will resolve the issue, it’s like Russian roulette somehow.
2. What do they break and how to fix it
Now we have some background information about the built-in device compliance policies, let’s break them! Just like with the first part, I need to split this part up into some nice subparts
2.1 Enrolled user exists
To break this, I made sure I enrolled a device with a new user. After the device was enrolled, I removed the user to see what happens. I opened the Company Portal to check it out
As shown above, the device is already assigned to someone in my organization. However, when we look at the device compliance report in Intune, we will notice that the device is no longer compliant!
It’s telling us it’s not compliant because the enrolled user no longer exists!
Okay…So let’s change the primary owner as shown earlier, shall we?
And within a couple of minutes and with some patience, we are compliant again!
2.2 Is Active
I guess this one is easy to break!. I enrolled a new device again and changed the compliance check-in day to 1. To make sure this test was valid, I made sure the Conditional Access to require a compliant device was active
After waiting some days, I made sure I looked at Intune before logging in. As shown below, the device wasn’t compliant anymore!
When logging on to the not compliant device, you will get a prompt notifying you there is a problem with your work or school account
But after opening the Company Portal app, manually syncing the device, and checking for compliance, it is marked compliant again!
The device will also change from non-compliant to compliant in Intune within (normally) a few minutes!
Please Note: When manually initializing a sync from the device doesn’t fix it, please open your Azure Ad Sign-in Logs and watch out for the Sign-in error code 53000 notifying you “Conditional Access policy requires a compliant device, and the device is not compliant“
Because if Conditional Access has the power to break the Subscription activation to upgrade your device to Windows Enterprise, I assume it “could” also break your device, becoming compliant again!
Subscription activation Issues and the Windows Store API (call4cloud.nl)
2.3 Compliance policy assigned
When assigning it to a device group or “All devices” instead of a user group you could end with the “system account” not being compliant as we also could notice with the built-in Device Compliance Policy.
If you made this mistake in the past and you have changed the assignment to users to fix it, it still could be that your devices are still not getting compliant. To make them compliant again, you need to open the Company Portal app and click on “check access”
Pressing ‘Check Access’ in the company portal will bring the system account back into compliance.
Another possibility when getting the system account to be not compliant could be if there is no user signed in to the device. At that point in time, the device will send a compliance report back to Intune showing System Account as the user’s principal name.
3. Monitoring Compliance policies
When you want to have a nice overview of the built-in compliance policies, there are a lot of places you could look but the devices / Monitor is a perfect place to start.
In this dashboard, you could select the “setting compliance” option
You will notice the three built-in options we have been discussing and a simple and brief description of the policy! Damn… isn’t that nice, we just got a perfect summary!
Conclusion
Let me start with the summary we got above!
Has a compliance Policy assigned | Devices must have at least one compliance policy assigned to be compliant. |
Is active | Devices must regularly contact Intune to be considered compliant. |
Enrolled user Exists | The user must exist and have a valid Intune license |
I guess I just love those compliance policies! Even when they sound easy, they could mess up your environment if you suddenly decide to flip the “mark devices with no compliance policy assigned as” to not compliant switch.
Hi Rudy
Great In depth explanation of compliance.
I still don’t quite get the deploying to users rather than Devices. Please don’t think i am spamming you, I will copy/paste my answer to you in a tech community thread:
“We used to deploy our Windows compliance policy to All Users but found that many devices were non-compliant due to the Has compliance policy assigned being non compliant. We have now deployed it to devices and the non-compliance has dramatically reduced. (The bulk of our devices are multi user (Education) with only staff devices being assinged a Primary User. The biggest cause of non-compliance we have now is the “is Active” setting.”
I have heard others recommending deploying the compliance policy to users as well so there must be something in it that i am just no quite getting (happens a lot 🙂 ).
I think it’s a case of Microsoft’s entire “compliance” system being screwed up. Logically, it makes sense that compliance policies should be assigned to devices, as it’s the device that needs to be compliant. A user isn’t Bitlocker encrypted, a device is, etc. However, because of the way the system is designed, the default compliance policy, and the “system account” issue, it’s unreliable. I’d love to be able to use device compliance in my CA policies, but I don’t trust it enough to risk users not being able to login because Intune screws up.
I I have some issues with devices failing on require.remain.contact. I can’t for the life of me figure out why. I have a CA policy that requires a compliant device to be able to access Exchange Online and this means a lot of users complain that they can’t open Outlook and Teams.
Last week my manager had his PC reset and autopilot configurated. He’s been working in the office every day the past week. Today he called me and couldn’t access Outlook and Teams because his computer was non-compliant, it failed require.remain.contact. We have the interval set to 7 days.
I am starting to suspect that some computers don’t ever check in with Intune but most clients of 800 doesn’t have any issues. It’s just so confusing to me what is wrong with those that don’t check in with Intune.
You really write some good articles, it’s a pleasure to read them. Thanks.
I can’t even find the “Default Device Compliance Policy” in Intune! I can see it is referenced in a Noncompliant devices and settings report, but I can’t for the life of me find where that policy is or the settings that it has. Can you provide the exact navigation path please?
If you open the company portal on the provblem device itself, it shoud tell you why it isnt compliant. (yep back in the day you could click n the non compliant message to get more details but somehow that chagned)
I agree with this comment. I understand how you can check each device, but I just want to see the default device compliance policy so I can see exactly what the policy contains. Where can you find these policies? They are not listed under “compliance policies” in Intune. Where are they?
Really appreciate you putting this together and breaking it down by scenarios talking about the ‘unknowns’ that even Microsoft doesn’t publicize.
Was getting nowhere with an endpoint that was stuck as Non-Compliant with the ‘Is Active’ state not changing after hours of syncing. Sure enough it went through after about +/-36 hrs of staying connected.
Hi Rudy, was wondering if over time you’ve changed your mind about preferring to assign these policies to users rather than devices? Am thinking that M$ might have optimized some things to change that–but maybe not? Trying to come up with a best practice around this question.
Hi Rudy,
having issues with Enrolled use exists, on co-managed Hybrid joined , the first user becomes the Enrolled user so when they leave and get removed it just leaves behind a GUID and then the compliancy policy fails. so the IT Tech is the first user, all fine, after a year they leave now hundreds of devices are not complaint and MS response is to rebuild. we have not had any luck with the above working. had looked at Dem accounts but these are no longer supported by MS for this use.
It seems earlier this year it was possible to change the Enrolled By user, however this is no longer the case. as per the below
Did something change in Intune to allow “enrolled by” user to changed when “primary user” changed? – Microsoft Q&A
https://learn.microsoft.com/en-us/answers/questions/1533809/did-something-change-in-intune-to-allow-enrolled-b