Last Updated on October 24, 2022 by rudyooms
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 policies.
I realized that after reading a question on the TechNet community I didn’t have any blog about this topic.
So here we go! I will divide this blog into multiple parts
- Taking a first look at the Windows Built-In device compliance policies
- What do they break and how to fix it
- Monitoring Compliance policies
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
Before I am going to show you the 3 built-in compliance policies, we need to beware of 1 very important item. The device NEEDS to be enrolled into Intune to have the possibility to get “measured” and to get “compliant” as mentioned in this blog!
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
Somehow 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 could 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
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 talking about this specific built-in compliance policy, let’s extend it a little bit more. Did you happen to have read the text when opening the “Compliance policy Settings” in Intune? It’s mentioning something about the “built-in device compliance policy” which I am talking about 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 make sure that all of your devices need to have a compliance policy assigned. Otherwise, you could end up having a device that does not meet your company its compliance requirements but could still access the Microsoft 365 Data.
Some additional pieces of advice: When creating additional compliance policies, make sure you are targeting USERS and NOT 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, all of your devices will be affected by this change and could end up with 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, it’s mentioned that the device is already assigned to someone in my organization. When taking a 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 having 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 first took a look at Intune first 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 and manually syncing the device and checking for compliance, it is marked compliant again!
The device will also change from not 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!
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”
When pressing ‘Check Access‘ in the company portal it 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 3 built-in options we have been talking about and a simple and brief description of the policy itself! Damn… isn’t that nice, we just got a perfect summary!
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.
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 me those compliance policies! Even when they sound easy, they could mess up your environment if you suddenly decided to flip the “mark devices with no compliance policy assigned as” to not compliant switch