This new blog will be about me (again) dealing with some issues while enrolling a device with Autopilot. While trying to re-enroll the same device with Autopilot, it “suddenly” stopped receiving the required Autopilot Profile. Do you want to know more about the “suddenly” and what caused it? Keep reading! I will show you how something new called, the Autopilot Marker is interfering!
1. Introduction
This blog will be sort of version 2 of my The 41-Year-Old Hardware Hash Who Knocked Up Autopilot and Felt Superbad About It blog.
Something Went Wrong when fetching the Autopilot Profile (call4cloud.nl)
In this blog above I showed you a weird issue when your Autopilot device doesn’t receive the Autopilot Profile. We were all told it’s always about the hardware hash right?
Let me guide you through the whole story and me trying to find out what was happening in the back
2. The Issue
I can be quick and dirty here… Here you go! A nice welcome screen for you!
As shown above, when our hash was uploaded before from the same VM with the Convert Autopilot device option as described in one of my latest blogs we ended up with the NON-Autopilot screen asking us how we would like to set it up. No Autopilot profile for us!
3. It’s all about the Hash, right?
After noticing my device didn’t get its Autopilot profile, I had a hunch about what could be causing this issue. So Let me guide you through the steps I took to reproduce the error.
While reproducing the error keep an eye on the Hash I am showing you with the OA3tool. With the latest Windows 10 22h2 build out there, I decided to install a VM with it, and before uploading the hash to the Autopilot service I exported it to a TXT file.
Windows 10 22h2
While uploading the Hash I also made sure I watched Fiddler capture the upload of the hardwareidentifier to make sure I could compare it with the OA3Tool I mentioned earlier.
As shown above, the Hardware Hash was indeed uploaded. For everyone thinking Microsoft still has your Autopilot Hash in their service, you are totally wrong! When the hash gets uploaded, Microsoft extracts the “data” they need and immediately ditches that chunk of wonderful information.
Microsoft is even telling us the same thing, right? Otherwise, they should mention the Hash and not mention “data” .. but that is just me thinking out loud….
Let’s get back to the story before you get distracted, shall we? After uploading the hash I rebooted the VM to take a look if it could fetch its Autopilot Profile.
As shown above, yes the device was able to fetch its Autopilot profile without any issue. After receiving the Autopilot profile I decoded the hardware hash again to compare it.
As shown above, it is “almost” the exact same hash (besides the date stamp… but that’s pretty obvious) But let’s continue, shall we? As I decided to reinstall the VM again with the same ISO to check out what was happening
Reinstall the same VM with 22h2
After the device was reinstalled, the device was again able to fetch the Autopilot profile. To be sure the device was still the same I again compared the Hash with the one I got earlier.
As shown above, again no difference right? Let’s step it up a notch and reinstall the device with an older Windows 10 21h2 build.
Reinstall the same VM with 21h2 19044.1645
Oh my… it breaks… we even got event 314 mentioning the Autopilot profile can’t be downloaded.
I assume the Hash should be different right? Because we all know the Hardware Mismatch error I showed you in my version 1 blog
As shown above, the decoded Hash is still the same, except for a “ToolBuild” version..? That one made me wonder and think about it a bit more… 1865…. 1865…. 1865…..
Installing (KB5015878) or the 2022-08 Kb5016616
Before installing those updates I started to install each previous update separately (2022-05/06/07) but all of them got me the error: Failed to get Autopilot profile….. until I arrived at (KB5015878) for 21h2 windows 10 x64
After upgrading the same VM that didn’t get its Autopilot profile the first time with this preview build, guess what happened?
Again… I decoded the Hardware Hash and compared it to the one that wasn’t working… guess what changed? Yep.. The ToolBuild.
Okay… the Hardware Hash Information is still the same. Before moving on let’s talk some more about the hardware hash and the required fields because I have the feeling there is some additional information being sent to the Autopilot service.
4. The Hardware Hash
Michiel Niehaus already explained this part, but to tell you the whole story, I also need to add it to my own blog a bit. Microsoft Is telling us that when uploading your device its hardware hash the critical fields that need to be in the Hardware Hash are these fields.
When looking back at fiddler and the Hash we uploaded those “critical fields” were indeed all in it. If we open the Autopilot.dll with IDA we would also notice the same “HardwareInfo” get commands
Please Note: This Autopilot.dll screenshot is taken from the July 26 build!
As shown above, there is a lot of important information. I guess I need to explain the OfflineDeviceId in a future blog.
5. Comparing the Autopilot.Dlls
Where should I begin comparing those Autopilot DLL files, even though the new Autopilot.dll file is 150% bigger than the original?
I decided to open IDA to find out what is missing from the original DLL one.
As shown above… that was a quick one! All the stuff I showed you before is missing… It looks like a total rebuild to me. I guess I can ditch this idea because comparing something with nothing will be difficult…. Or?
Wait sec… When I was trying to find out which parts of the hardware hash were also mentioned in the Autopilot.dll I forgot to look at the stuff I couldn’t “translate” .
Sometimes it’s better to look at the stuff you don’t know instead of looking at the stuff you do know. Let’s sum up what I am missing…
- GetRemediationData
- GetAutopilotMarker
- GetCachedHardwareBlob
- GetCurrentHardwareBlog
Please Note: the GetMsaTicket deserves a unique blog… so not going to put it here.
Looking at the summary above, the GetAutoPilotMarker truly attracted my attention!
6. Let’s Zoom in
Okay… it’s not my best work .. but this was my draft while looking at the flow and trying to determine what is going on with my Autopilot profile and looking at the summary I showed.
When taking a good look at my beautiful work in ms paint.. we will notice a lot of UEFI and Firmware stuff in it
I decided to use the UEFI tool from Micheal NIehaus to determine if I could find the Autopilot Marker in the UEFI… As shown below, when running the get-UEFIvariable command, the answer is … YES!!! That Autopilot marker is set in the UEFI with a device unique ID on a 22h2 Device (or the July preview build) 
Besides looking at the UEFI, we could also spot the same AutoPilot Marker in the registry by opening the Provisioning\HardwareInfo registry key
When checking for the same stuff on a pre-preview July build, we will notice that Autopilot Marker isn’t in it
Mmmm… Marker… Marking…. I guess Microsoft needs to mark a specific point in time.
7. Autopilot marker
As we noticed before and looking at the wonderful blog from MN (third time I am mentioning you… I guess I need to buy you a drink)
Connect the dots: From hardware hash to Autopilot profile – Out of Office Hours (oofhours.com)
After the hash is uploaded and the device reboots for the first time, we will notice that the device will reach out to https://login.live.com/ppsecure/deviceaddcredential.srf to submit the hardware information to get the needed x-device-token AKA Microsoft Account (MSA) Ticket AKA OnlineIdServiceTicket AKA MSA-DDID AKA.Microsoft Passport AKA .NET Passport or the old Microsoft Wallet 🙂
This token will be used later on to authenticate to the Autopilot Service and to fetch the Autopilot profile from ztd.dds.microsoft.com. As shown below the device also sends out some “other information” with the device-token it got earlier.
- MS-CV
- X-Autopilot-Marker
- X-Device-Token
- X-Hardware-Hash
One of them is the most wanted X-Autopilot Marker. I also tried to catch that hardware submitted to login.live.com, but I could only catch it on a device pre-preview July build. (I’m not giving up!)
Let’s put on my assuming hat one more time to do some assumptions!
When a 22h2 device first contacts the Autopilot service after the hash has been uploaded to get its Autopilot Profile, it needs to send out the Hardware information. This Hardware information will be used to get the device token.
In the same process to get the device token on a 22h2 build, the unique Autopilot Marker is also sent to the service because otherwise, why would it send out the Autopilot Marker with the device token when trying to fetch the Autopilot Profile? Sending out a Marker when Microsoft has nothing to compare it with is nonsense.
If we reinstall the same device with a pre-preview July build, the device doesn’t have the UEFI Autopilot_marker Information, and that code is missing in the Autopilot.dll. Without the requirements, it could NOT send out the unique Autopilot Marker to the Autopilot service. With the Autopilot Marker missing in the headers, we will run into the famous HardwareMismatchDetected error!
Why? Because once the Autopilot marker has already been set, it is there to stay, and it will be a requirement to fetch your Autopilot profile
To make it even becomes funnier,
When you upload the hash from a 22h2 device, nothing will go wrong.(Without trying to fetch the Autopilot Profile, of course.)
*When you reinstall that same device with a Windows 10 21h2 pre-26 July build and click next to fetch the Autopilot profile nothing will probably go wrong.
*When you reinstall that same device with a Windows 10 22h2 build and click next to fetch the Autopilot Profile, the Autopilot Marker information and the device token will be sent to Autopilot.
*When you reinstall that same device again with Windows 10 21h2 pre-26 July, you are screwed as it doesn’t contain the knowledge about the Autopilot Marker. So when clicking next to fetch the Autopilot profile it will fail!
8. Owww I removed it.
I guess I still need to dive into the “why” the marker needs to be set. I decided to remove this part from the picture in part 6… Otherwise, my story would already be complete and that wouldn’t be fun at all
Looking back at some parts of the summary I mentioned earlier and comparing it with the picture above
- GetAutopilotMarker
- GetCachedHardwareBlob
- GetCurrentHardwareBlog
And adding the GetRemediationData to it and check out what we get… The HardwareMismatchRemediationData that was put in place on 26 July
I guess the Autopilot Marker AKA the UEFI Marker is used to mark a device “compatible” with Hardware Hash Remediation?
This new Hardware Hash Remediation feature seems to be currently looking pretty active in my tenant. 🙂 But I guess that is too much information to show you in this blog, so stay tuned!
9. Bios update breaking the Autopilot Marker
Besides the update necessary to get the Autopilot Marker working, we could also run into some nasty issues when updating the BIOS.
I dedicated a separate blog to this issue. Feel free to read it here
Conclusion
By the very looks of it, The Hardware Hash isn’t the only thing the Autopilot service is comparing when the device reaches out to get its Autopilot profile. Besides the Device Token, it first sends to get the device token, it will also send the Autopilot_Marker information, the MS-CV (Correlation Vector/Telemetry), and the HardwareHash itself to perform some remediation if needed
What’s the purpose of all this churn? It seems to be causing issues forcing me to delete hashes and re-import before AP profile loads again.
ah all Windows 11 versions you install would by default have the marker inplace ofcourse… 😀
I loaded my vm with windows 10 22H2(19045.3693). But still I don’t find the AUTOPILOT_MARKER in it. I tried Get-UEFI as well as checked in registry. Do I missed something that ms updated recently?
I assume the device itself is an autopilot device (added to intune)?