Last Updated on June 5, 2024 by rudyooms

This blog will cover a significant difference between Autopilot and Autopilot Device Preparation(APV2). I will explain why the hardware hash is NO LONGER required when you enroll your Windows device with Autopilot Device Preparation / APv2.

I will divide this blog into multiple parts

1. Introduction
2. Autopilot (apv1)
3. Configuring the Device Preparation Profile
4. Autopilot Device Preparation (apv2)
5. Corporate vs Personal
6. APV2 and the OOBE

1. Introduction

Last week, Microsoft officially announced Autopilot Device Preparation. With the official announcement, I also released my blog post, in which I compared the existing Autopilot version to the new Autopilot Device Preparation. (even when it are 2 different “things”)

After publishing that blog, I started a poll to ask what people wanted to hear next. Let’s look at the outcome.

I guess the outcome is pretty obvious. People want to learn why we no longer need the hardware hash to enroll our device in Autopilot Device Preparation.

With the Hardware Hash requirement removed with ADP, Microsoft also fixed the issue in which hardware replacement (such as motherboards) could give you issues in combination with the existing Autopilot. With the motherboard replaced, the Autopilot service wouldn’t recognize the device any longer as an Autopilot device. Microsoft tried to overcome this issue by implementing the hardware hash remediation feature and the Autopilot marker. Unfortunately, this feature also caused some other challenges.

Hardware Change | Autopilot | Fix Pending (call4cloud.nl)

Removing the hardware hash requirement looks like a good step, but before we dive into why we no longer need the hash for APV2, let’s take a trip down memory lane and look at how the hardware Hash is required for Autopilot.

2. Apv1

With Autopilot version 1, we must ensure we have uploaded the hardware hash to the Ztd autopilot service before enrolling the device. We could do so by using the Powershell tool.

Once the Hardware Hash has been uploaded to the service, it should become visible in the Windows Autopilot Devices.

With the hardware hash uploaded and recognized by the service, we can now turn on the device. Once the device is turned on, the OOBE will kick off, and we will notice that the Autopilot profile will be downloaded. The Autopilot profile download will happen in the background and, most importantly, before the user can enter his corporate credentials.

Let’s zoom in to understand this authentication flow with the Hardware Hash a bit better.

Source: Fetch the Autopilot Profile with PowerShell and a token (call4cloud.nl)

The flow above describes what’s happening. Once the device is turned on, it will eventually contact ztd.dds.microsoft.com to fetch the autopilot JSON.

This Autopilot Profile will be stored in the wmansvc folder in JSON format. This will ensure your device skips all the OOBE questions and starts showing the corporate login screen.

To resume: The Hardware Hash is required for Autopilot v1 to function and would deal with the OOBE questions

3. Configuring the ADP profile

The flow of Autopilot Device Preparation (APV2) is slightly different…… Well….I guess it’s totally different! Let me explain, but let’s make something clear first.

We don’t need to collect the hardware hash and we must ensure that the device is NOT an Autopilot device!

So, what do we need to configure if we don’t need the hardware hash? First, we must create the Autopilot Device Preparation policy/profile to use Autopilot Device Preparation!

When we create the Device Preparation policy, we also must configure some other required settings.

The first important setting we need to configure is the device group for the just-in-time enrollment grouping, which Microsoft also announced last week.

When you enroll your device with Apv2, the device automatically becomes a member of this just-in-time enrollment group. You can target your apps and policies to this group. I will discuss this fancy just-in-time enrollment group in a future blog, as it needs way more explanation than a couple of sentences.

With the first significant requirement configured, we must also define some other settings. Let’s take a look, shall we?

As shown above, we need to configure the Autopilot device preparation Page settings, which Apps, and which scripts we need to deploy during enrollment. Again, ensure these apps are targeted to the same just-in-time device group we configured earlier.

With the Autopilot page settings defined, we need to configure the assignment. This assignment needs to be a user group. When the user is a member of this group, the user will become applicable for APv2.

To summarize: Autopilot Device Preparation (APV2)is assigned to your users and does NOT rely on the Hardware Hash.

Let’s look at what is next and how Autopilot Device preparation gets enabled without the hardware hash requirement!

4. Autopilot Device Preparation (apv2)

With the Device preparation policy created, it’s time to turn on the device, go through the OOBE, and log in with our corporate credentials. As mentioned, the autopilot device preparation profile kicks in after the user signs in with his credentials.

If you watched the video, you might have noticed that after the “please wait while we set up your device” message, the cloud experience host shows you the new Autopilot Device preparation page. This “please wait” message screen takes a bit longer than with Autopilot version 1.

So, what’s happening in the background? To find out, I recommend reading this blog first.

Preparing your device for mobile device management | Intune (call4cloud.nl)

If you don’t want to read it… let me summarize it. The device will join Entra and automatically be onboarded to Intune. In the last step of the Intune enrollment, the device would contact manage.microsoft.com to ask for the binary security token.

If all goes well, we will receive the base64 security token. In the base64 decoded response, we will notice something funny.

One of those funny things hidden in this response is your Intune Certificate!

When we convert this encoded certificate, we will notice it is indeed the Intune MDM Device CA.

Looking further into the response, we will spot something more critical for Autopilot Device Preparation to kick in… In addition to the Intune certificate, it also holds 3 items of the already published device preparation CSP.

1. PageSettings (The Device Preparation Policy)
2. The PageEnabled settings
3. Bootstrapper Agent information

The page enabled, and page settings could ring a bell or 2? even while my tenant wasn’t flighted for APV2, I was already using them to manually enable Autopilot version 2. (together with the AutopilotDevicePrephint value)

Autopilot Version 2 Device Preparation Page | APV2 (call4cloud.nl)

With the page settings and the page enabled setting (apv2 profile) that came down with the Intune Certificate, the cloudexperience host now knows it needs to switch to the device preparation mode/pages without having the hardware hash.

Switching to the new device preparation pages (APV2 Mode) would also fire off the bootstrapper agent to start the initial provisioning. During the provisioning, the progressreporter would report every step in the process

The bootstrapper agent deserves a blog on itself, so I want to share that many details in this blog, but if you’re going to peak at it a bit, you could use get-ciminstance, for example.

So, with Autopilot Device Preparation, we don’t need the hash!! Without the hardware hash being required, we could run into some issues when we have an enrollment restriction in place to block personal devices. Let me explain why!

5. Corporate vs Personal

Let me start with some clarification and clearing things up.

Autopilot and Autopilot Device preparation enrolled devices are always marked as Corporate.

However, if you use an enrollment platform restriction to block personally owned devices, those Autopilot Device Preparation devices will also be blocked from enrolling!

With this enrollment filter in place, the device would be stuck with the 801800014 error.

How are we going to fix this? Well, that’s easy. In the same article Microsoft used to announce the just-in-time group membership, Microsoft also announced the corporate identifiers.

We must upload the corporate identifier to ensure the device isn’t blocked. This will ensure that your APV2 enrollments aren’t blocked because of that personal enrollment restriction.

Microsoft added this standalone feature to allow us to upload a CSV with the manufacturer, model, and serial number. Once we create the CSV, we can upload it to our tenant. Once we upload the CSV, the device will no longer be blocked!

Please note: It is good to know that the Windows corporate identifier is not required for apv2 to work. This feature can also be used for other purposes.

Most of your questions are probably answered by now… but we still need to deal with the OOBE questions first.

6. APV2 and the OOBE

Let me summarize the previous parts to understand better how Autopilot device preparation works.

Autopilot Version 1 will get the AP profile before user login

Autopilot Version 2 will get the AP profile after the user login

But what about the OOBE questions about how we would like to set up this device?

As mentioned a couple of times, Autopilot Device preparation kicks in after the user signs in with his credentials.

These OOBE questions are not skipped if you are using Windows 11 Pro, so for now, expect these questions to pop up if you are using Autopilot Device preparation combined with Windows 11 Pro.

It’s good to know that when you install your device with Windows Enterprise, the regular OOBE questions will NOT be shown!

So, if you are wondering why you get that stupid OOBE question from above when you want to enroll your device with autopilot device preparation, you probably use Windows 11 Pro.

Conclusion

Autopilot device preparation does NOT require or need the Hardware Hash to function. You could use corporate identifiers to ensure the personal device restriction doesn’t block the APv2 enrollment.