In this blog, I’ll dive into a key difference between traditional Autopilot and Autopilot Device Preparation (APv2). I’ll explain why the hardware hash is no longer needed when enrolling your Windows device using APv2 and how the Corporate Identifier now takes its place to help differentiate between corporate and personal devices—making it easier to block personal devices from enrolling!
1. Introduction
Last week, Microsoft officially announced Autopilot Device Preparation. With the official announcement, I also released my blog post, comparing the existing Autopilot version to the new Autopilot Device Preparation. (even when it are two 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. Autopilot V1
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 Device Preparation 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.
- PageSettings (The Device Preparation Policy)
- The PageEnabled settings
- 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 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.
Please make sure you are running the latest Windows Version. Minimum Required: March 26, 2024—KB5035942 (OS Builds 22621.3374 and 22631.3374) Preview
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 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! But the questions we get after enrollment to configure and choose the privacy settings for our device will still be shown!
Which is obvious as we couldn’t configure this option in the Autopilot Device Preparation profile. Luckily I already blogged about how you could deploy a PowerShell script to get rid of these privacy settings questions after the Autopilot Device Preparation enrollment
Autopilot Device Preparation | Hide Privacy Settings
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.
Great summary!
So now it does not support hybrid, does that mean AP does not support it all or is V1 going to work?
with device preparation, hybrid is indeed not supported.. byt luckily for everyone still using hybrid, you could still use apv1
Adding the just-in-time Group fails for me consistenly – even when creating a blank group. Is there something I’m missing here?
Did you made sure you added the proper owner to that group as i showed in the blog?
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?
How did you created this device group?
Just like you would normally do…except one big difference.. make sure the owner is configured like i mentioned in the blog
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: https://learn.microsoft.com/en-us/autopilot/device-preparation/tutorial/user-driven/entra-join-automatic-enrollment
Yet don’t see anything..
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
Yannick
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
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!
What about device name ? in APV1, device naming template can be given. How can we achieve device naming template on APV2. Do we need to push CSP to change device name ?
Hi. with apv2, we dont have the device naming option right now .. hopefully msft will add it in the future.
I have two questions.
1) What if we exclude Apv2 user group from “personal device enrollment block” policy. Will it still allow those to enroll using Autopilot device preparation way?
2) What happens to a device after Windows reset. In APv1, it remains in autopilot. What happens if after device reset, user doesn’t return the device. Will it still be attached to the tenant?
Hi!
1: if the user isnt blocked from enrollment (excluded/not targetted) by the platform restriction, it should enroll
2: the device would just be reset and would start enrolling into apv2 (if the hash isnt uploadedm otherwise it will switch to apv1)
How long does it take for the corporate device identifier added will work?
I have followed every step, the device is there, the groups are there, the user is in the correct group but i stell get en 80180014 ?
Is it broken right now ?
Did you solve this issue?
I’m having the same issue and I’ve tried with multiple tenants. Whenever I block “Allow Personal Device” we get error code “80180014” after filling in the users email + password in OOBE even though the corprorate device identifier is in place. I have tried with both physical device and VM.
Both user group and Device group is assigned to Device Prep policy. The Device group has the Intune provisioning client as owner.
However when we enroll a device with “Allow Personal Device” allowed, the device is not getting added to the Device group either. But atleast then we get through the error message “80180014”
We solved this with assistance from the wonderful Rudy Ooms himself. An upgrade from Windows 11 Enterprise 23H2 22631.2861 to Windows 11 Enterprise 23H2 22631.4249 fixed the issue for us.
Hi,
we are testing APv2 and your Blog is a great help.
We use Windows 11 Enterprise and the regular OOBE Questions are still there.
Is that a new Bug or did we miss some Options?
Yes… with windows enteprrise the questions before the enrollment shouldnt be shown (home/work or school account question stuff) the questions afterwards are still be shown
Thanks
I have a question. I have followed all the steps and was able to get one device setup through the Autopilot Preparation (all the scripts and apps were installed during the “setting up work or school” loading screen. On the same laptop, I had wiped it, and removed it from Intune (i made sure i couldn’t find the device by looking up the name, and checking if it was listed in the “Windows Autopilot Devices” page in Intune) After wiping it and trying to go through the setup process again, during the “Setting up work or school” loading screen, instead of getting the 1 big spinning wheel with the % of completion, I got the old Autopilot “Setting up Work or school” screen where there is a section for “Device Preparation” and “Device Setup”. So none of the apps or scripts were installed. I also tried the Autopilot Preparation on a brand new laptop, and registered it as a corporate device, but also received the same old Autopilot “Setting up Work or school” screen. Not sure how I was able to get it work once. Is there some lingering data in Intune that is causing the wiped device to enroll through old Autopilot? But also not sure why the new laptop had the same issue.
The moment you upload the hash, the device will always be recognized as apv1. If you enroll an apv2 device but you do have an autopilot profile configured with the option: convert existing devices to autpilot devices, the next time it will enroll with apv1.