Call4Cloud | MMP-C | Autopilot | Device Preparation

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

Patch My Pc | install & update thousands of apps

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.

white

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

autopilot pre-provisioned device not compliant

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

the device has no 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?

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

autopilot pre provisioned device is now 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.

Blocked Patrick Bateman Sigma Male GIF | GIFDB.com

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 *

96  −  91  =  

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.