Autopilot Device Preparation: The Hardware Hash Voyage home

Last Updated on June 30, 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”)

Afbeelding met kleding, person, tekst, persoon

Automatisch gegenereerde beschrijving

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

Afbeelding met tekst, schermopname, scherm, software

Automatisch gegenereerde beschrijving

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 (

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.

Afbeelding met tekst, schermopname, nummer, Lettertype

Automatisch gegenereerde beschrijving

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.

Afbeelding met tekst, schermopname, software, Webpagina

Automatisch gegenereerde beschrijving

Source: Fetch the Autopilot Profile with PowerShell and a token (

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

Afbeelding met tekst, schermopname, Lettertype, informatie

Automatisch gegenereerde beschrijving

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.

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!

Afbeelding met tekst, schermopname, Lettertype

Automatisch gegenereerde beschrijving

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.

Afbeelding met tekst, schermopname, software, nummer

Automatisch gegenereerde beschrijving

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?

Afbeelding met tekst, schermopname, software, nummer

Automatisch gegenereerde beschrijving

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 (

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

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.

Afbeelding met tekst, Lettertype, schermopname, lijn

Automatisch gegenereerde beschrijving

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

Afbeelding met tekst, nummer, Lettertype, lijn

Automatisch gegenereerde beschrijving

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.

Afbeelding met tekst, schermopname, Lettertype

Automatisch gegenereerde beschrijving

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!

Afbeelding met tekst, schermopname, Lettertype, nummer

Automatisch gegenereerde beschrijving

With this enrollment filter in place, the device would be stuck with the 80180014 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.

Afbeelding met tekst, elektronica, schermopname, Lettertype

Automatisch gegenereerde beschrijving

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!

Afbeelding met tekst, lijn, Lettertype, schermopname

Automatisch gegenereerde beschrijving

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


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.

11 thoughts on “Autopilot Device Preparation: The Hardware Hash Voyage home

  1. Great summary!

    So now it does not support hybrid, does that mean AP does not support it all or is V1 going to work?

    1. with device preparation, hybrid is indeed not supported.. byt luckily for everyone still using hybrid, you could still use apv1

  2. Adding the just-in-time Group fails for me consistenly – even when creating a blank group. Is there something I’m missing here?

      1. I haven’t no – so that might be the issue. I cleaned my glasses and re-read this blog post. But still can’t see where you mentioned it? On that: “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.” can you point me to it?

    1. Just like you would normally do…except one big difference.. make sure the owner is configured like i mentioned in the blog

  3. Thanks for explaining! Understood it right away. I did not see the “Device preparation policies” option in the “Windows Enrollment” page/options. Could it be it has not rolled out to every tenant yet?
    I’ve created a new device group with specific owner and followed all the other steps as Microsoft explains here:
    Yet don’t see anything..

  4. Hi Rudy

    you wrote “Autopilot and Autopilot Device preparation enrolled devices are always marked as Corporate.”

    So, that means if I allow personal devices to be enrolled (Device Platform Restrictions) all users within the ADP *User Group* are eligible to enroll a device (corporate and/or personal). And all these devices will have Ownership “Corporate”? My expectation was, that an ADP enrolled device can have the Ownership “Personal” or “Corporate”, but if I add the Corporate device identifier, the Ownership of the personal device will change to corporate. If that is correct, how can i distinguish between personal and corporate devices? Is it possible? I guess you will recommend me to block “Personal” devices on the Device Platform Restrictions, so only “real” corporate devices can enroll?!

    Many thanks

    1. I guess you will recommend me to block “Personal” devices on the Device Platform Restrictions, so only “real” corporate devices can enroll?! –> 🙂 yes exactly this… but there seems to be a slight issue with the corporate identifiers and they are not yet working with device preparation

  5. hmm, maybe i need to see and test it for myself but i don’t see any difference between uploading a file with hashes and a file with corporate identifiers.
    also i use mostly preprovisioning and hybrid.

    but great article…thanks!

Leave a Reply

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

  +  70  =  74