Blood, Sweat, and built-in compliance policy

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.

Intune marks Not Compliant if the device does not sign in regularly, then permanently blocks the device – Microsoft Tech Community

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. Introduction
2. Enrolled user exists
3. Has a compliance policy assigned
4. Is active

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

1. Enrolled user exists
2. Has a compliance policy assigned
3. Is active

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!

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.