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

Last Updated on May 17, 2024 by rudyooms

Using Autopilot Pre-provisioning and having Non-Compliant devices because they are not evaluated yet? This blog will show 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 beautiful Reddit Intune forum. The OP mentioned that his devices that were enrolled with white-glove weren’t compliant the moment they were resealed.

Afbeelding met tekst

Automatisch gegenereerde beschrijving

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

Afbeelding met tekst

Automatisch gegenereerde beschrijving

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

Afbeelding met tekst

Automatisch gegenereerde beschrijving

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 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

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?

People-who-are-fake GIFs - Get the best GIF on GIPHY

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?

Afbeelding met tekst

Automatisch gegenereerde beschrijving

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 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, the device would reboot and will send out the DHA data to the DHA service. After rebooting the device, I opened Powershell to determine if it also thinks it is 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?


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

Blocked Patrick Bateman Sigma Male GIF |

4 thoughts on “Don’t Tell Mom the Pre-Provisioned Autopilot device is Compliant

  1. I guess if you don’t assign a user to the hash, devices can stay as not evaluated. Built-in device compliance policy is not triggered if no user is specified.

    In your scenario what happens if you have 2 compliances: 1 for device (to have pre-provision as compliant) and 1 for user and device’s one passes but user’s one fails?

    1. Hi. need to check how it handles other compliance policies… but that bitlocker policy I tested with was compliant for the user and device assigned compliance policy

  2. How about a dummy compliance policy with like a min system version assigned to devices?

    I guess this one should not really have a chance to get non compliant for a system user?

  3. Is there any trick to have bitlocker enable without a user signing into a self-deployment/whiteglove autopilot machine?

    Rebooting the machines, and trying various bitlocker policies the machines just refuse to enable bitlocker until a user signs in

Leave a Reply

Your email address will not be published. Required fields are marked *

4  +    =  12