Don’t Tell Mom the Pre-Provisioned Autopilot device is Compliant.

When using Autopilot for pre-provisioned deployments, you might encounter non-compliant devices that have yet to be evaluated. This blog will explain why this happens and how you can potentially work around it.

1. Introduction

Last week I stumbled upon a question in the beautiful 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 aren’t 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 reach this “reseal” screen, let’s open the Intune portal and examine 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 click 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

https://call4cloud.nl/2021/06/blood-sweat-and-built-in-compliance-policies/

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 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 was 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 reseal the device, it would reboot and send the DHA data to the DHA service. After rebooting the device, I opened Powershell to determine if it also thought it was compliant. To do so, I queried the MDM_DeviceStatus_Compliance01 classname.

As shown above, the device thinks it’s pretty much compliant. With this information, the device will eventually become compliant. It could take a couple of minutes, but as shown below, the pre-provisioned autopilot device will be 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.