Last Updated on March 15, 2023 by rudyooms

Using Autopilot Pre-provisioning and having Non-Compliant devices because they are not evaluated yet? This blog will show you why and how you could “possibly” work your way around it.

I will divide this blog into multiple parts

1. Introduction
2. Non-Compliant
3. Compliance Policy
4. All Devices
5. Testing it

1. Introduction

Last week I stumbled upon a question in the wonderful Reddit Intune forum. The OP mentioned that his devices that were enrolled with white-glove weren’t compliant the moment they were resealed.

Luckily we arent using the term white-glove anymore, right? Microsoft removed it from all their code! Oww… my bad…

Let’s take a look at what’s happening at the moment the Pre-Provisioned Autopilot device ends up at the sealing screen

2. Non-Compliant

When we end up at this “reseal” screen let’s open the Intune portal and let’s take a look at the device.

If we take a look at the device it’s compliance status, we will immediately notice that the device isn’t compliant and failed on the built-in Device Compliance policy

After we clicked on it to get more details, we will notice that compliance is failing on the “Has A Compliance Policy assigned”

This error just means that the device doesn’t have a compliance policy assigned and because of it, it isn’t getting compliant.

If you want to know more about The built-in Device Compliance policy, please read my blog about them. It will show you each policy and how it works and how it doesn’t

Looking back at the picture which showed us the failed compliance policy, it also mentioned the Enrolled user exists. Pre-Pro equals no user? Is it a ghost?

Maybe it thinks it’s the “fake” FOOUSER

Still funny… but let’s move on shall we

3. Compliance Policy

If you are running into this issue, you have probably also configured some compliance rules, right?

In the past, the “All Devices” was missing. Maybe because it was missing you have assigned those compliance policies to “All users” or maybe a specific user group.

If that’s the case… yeah… noncompliant is what you would get when pre-provisioning a device with Autopilot

4. All devices

Just like we did with the Company Portal back in the day and all other apps we wanted to deploy during the “device” phase in Autopilot, you made sure you changed the assignment to devices (and of course made sure the install context was device)

Why not do the same for Compliance Policies?

As shown above, I made sure I created an additional DHA compliance policy and targeted them to “All Devices” (of course in a production tenant, please scope it)

5. Testing it

With a compliance policy assigned to my devices instead of my users, I reinstalled the device and let it enroll into Autopilot by using pre-provisioning

As shown below, the first thing we will notice is that the device now gets a compliance policy assigned

At first, we will notice that the compliance policy still has some evaluating to do

But after a minute or 2, it will be evaluated. Because it got evaluated, the built-in device compliance policy will get compliant even while our own compliance policy got non-compliant

If we take a closer look at the policy, as shown below, it will mention that the Bitlocker requirement isn’t getting compliant

But that’s because BitLocker still has to be enabled and requires an additional reboot to send the DHA-Data to the DHA-Service.

Before getting the option to release the device, the device would reboot and by doing so send out the good DHA-data to the DHA-service. With this information, the device will get compliant!

Isn’t that just beautiful ?

Conclusion

Of course, changing a compliance policy to all devices could get you non-compliant within the system user but then again having a non-compliant device after it got resealed could also give you issues when you didn’t configure grace periods and you are using conditional access to require a compliant device