The 41-Year-Old Hardware Hash Who Knocked Up Autopilot and Felt Superbad About It

In this blog I will be talking about a sudden “HardwareMismatchDetected” I got when I was trying to enroll my Windows 10/11 device with Autopilot for Pre-provisioning deployments

I will divide this blog into multiple parts

  1. Introduction
  2. The Issue
  3. Troubleshooting the missing Autopilot profile
  4. Solving it
  5. What could have caused it?
  6. Conclusion

In one of my latest blogs, I showed you that with the latest Windows 11 Insider preview version, Microsoft fixed the ESP progress page after it rebooted because WUfB was targeted at devices as mentioned in this blog

As we all know, when we want to make use of the Autopilot Service we need to make sure we have the 4K Hardware Hash uploaded to Intune, otherwise, the device won’t be approved to enroll into Azure Ad and Intune.

To make sure the device was recognized I opened a new PowerShell session on my cleaned installed Dell Latitude 3590 and uploaded the Hash by using the get-windowsautopilotinfo PowerShell module. After a couple of minutes, it was done and the device ended up in the list of Autopilot devices in Intune.

Graphical user interface  Description automatically generated with medium confidence

Before I started the test, I made sure the “Create Imported Windows Autopilot Device” event was logged in the Intune audit log. As shown below, on 06-04-2022 a new Autopilot device was imported!

A small reminder: When using Autopilot White Glove/Pre-Provisioning you will need to delete the Intune Object first before re-enrolling the same device

Graphical user interface, text, application, email  Description automatically generated

I guess when you have read the Don’t Be a Menace to Autopilot While configuring Your WUfB in the Hood blog, you can probably guess how many times I needed to remove the Intune device object (Delete MangedDevice) before testing it again.

Graphical user interface, application, table  Description automatically generated

As shown above, I tested it multiple times, that’s for sure!. But suddenly on 22-04-2022 the enrollment just stopped working!

Just one day before I went on holiday, I heard that with the latest Windows 11 insider preview, the Autopilot sealing issue would be fixed. Okay… I was like, I am not on vacation yet, so I deleted the Intune Object again and started the enrollment process again!

I made sure I waited 30 minutes before pressing the Windows logo to start the pre-provisioning because I also noticed some weird behavior when you try to pre-provision a device when the Intune Object was still pending deletion!

Graphical user interface, application  Description automatically generated

After selecting the Pre-Provisioning option as shown above, almost immediately the famous “Something went wrong” error was thrown!

As shown below, the Autopilot Pre-Provisioning process didn’t find an Autopilot profile? It’s telling us: No organization found and no profile found?

Image

That’s weird because on 20-04-2022 it worked like expected.

To be sure I was not going crazy just 1 day before going on holiday I took my shovel out of my suitcase and started digging!.

Okay okay.. I asked a colleague to get my shovel and started digging

Hey You! Get my shovel! - john cena | Meme Generator

The first place to start, after checking if the device has internet should always be Intune when troubleshooting issues with Autopilot Profiles. I opened Intune and made sure if the Autopilot profile was still assigned to the device. As shown below… the profile status was still assigned as it should and with the proper Autopilot profile

You can never be certain! I needed to check it out even It should be weird that somehow this suddenly changed but ey who knows?

Now we are sure the profile was still assigned let’s take a look at the device itself! I opened a PowerShell session with the use of shift+f10 and opened the registry. I wanted to be sure if it was just a GUI glitch or if the Autopilot profile settings didn’t arrive at the device!

HKEY_LOCAL_MACHINESOFTWAREMicrosoftProvisioningDiagnosticsAutoPilot

Text  Description automatically generated

As shown above, it was missing some important information needed for Autopilot like the “CloudAssignedTenantId” and the “CloudAssignedTenantDomain”.

At that same time, I realized that this issue could be due to something that could have broken at Microsoft their Service side as mentioned in this blog

In a normal situation when using Autopilot, the Autopilot profile will be received from the Autopilot endpoint Zero Touch Deployment Directory Domain Services (ztd.dds.microsoft.com). This wonderful key could also be noticed in this Autopilot Settings registry key

ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftProvisioningAutopilotSettings

I tried to find differences in the route to ztd.dds.microsoft.com when running tracert from multiple locations and other “working” devices

As shown above, on all other locations and working devices the output was almost the same so no routing issues for us this time!. I guess it’s time to open the event logs to take a look at the ModernDeployment-Diagnostic-Provider and Shell-Core event logs

Table  Description automatically generated

As shown above, the modern deployment event log was throwing event 100 errors at me and mentioning it didn’t find the required Autopilot Registration ID! High ho, high ho it’s up to the Shell-Core event log we go!!

As shown below, the same kind of error is shown in the event 62407. “Unable to get device ZtdID”

Text  Description automatically generated with medium confidence

I decided it was time to download fiddler to check what Fiddler has to tell us! Maybe somehow, someone placed a proxy inside this network without me knowing it?. After setting up Fiddler as shown in the blog above I restarted the Autopilot pre-provisioning flow.

Within a few seconds, Fiddler was showing us a connection to the same Autopilot Endpoint I showed you earlier. While communicating with ztd.dds.microsoft.com it also transferred its Hardware-Hash

Text  Description automatically generated with medium confidence

Looks fine to me? Shall we look at the response I got while communicating with the Autopilot Endpoint?

A picture containing graphical user interface  Description automatically generated

HUH… HUH and again HUH? So somehow we got a 908 error code – HardwareMismatchDetected?

I guess I don’t need to explain what Hardware Mismatch Detected means…

Hypothesis

When the device its Hardware Hash doesn’t match the one in Intune… it doesn’t get the Autopilot profile! But why? I didn’t change anything as shown earlier in the Intune Audit logs!

I guess solving this weird issue is pretty simple…. Just remove the Autopilot device object and reupload the hash again!

Graphical user interface, text, application  Description automatically generated

After the device record was successfully deleted I reupload the hash again and after a couple of minutes of waiting the device object was ready to be used

I reinstalled the device and started the Autopilot pre-provisioning again and after a couple of seconds, it successfully downloaded the Autopilot profile and started the device setup!

I guess this part will be a work in progress because I also put in a support ticket at Microsoft about this issue. When looking at the facts, it looks like somehow the hash previously uploaded to Intune became invalid, but why?

Please Note this pure speculation, no string attached here… But looking at this Autopilot CSP Doc

WindowsAutoPilot CSP – Windows Client Management | Microsoft Docs

You will probably notice the “HardwareMismatchRemediationData” part as shown below

Text  Description automatically generated

This MS-Doc is telling us “This string is used as input for calling Windows Autopilot Service to remediate a device if the device underwent a hardware change that affects its ability to use Windows Autopilot”

So you would assume that there is an auto-remediation service that will fix the feature HardwareMismatches when using Autopilot? So maybe because it detected multiple enrollment issues, it tried to remediate the Hardware Hash and by doing so it broke completely?

Again, this is purely speculation… but it sure does sound like a possible option for me (now)

You could probably ask me WHY I didn’t delete the device object at first, at that point I would answer… As it was working yesterday, why should I remove the hash today? So far as I know it doesn’t have a max amount of attempts it could be re-used.

Waarom Maar Waarom GIF | GIFs.nl

Even when the solution is pretty simple I reached out to Microsoft Support to get to the bottom of this weird issue. Even when it is already solved I want to know what happened as this is NOT normal behavior and we don’t want this kind of weird behavior when enrolling devices at a large enterprise customer!!!

Please Note: If I get any information and if I have permission to share it, I will!

avatar
Rudy Oomshttps://call4cloud.nl/
Rudy is a Modern workplace architect and currently working for a company in the Netherlands, called Deltacom Steenbergen. He has been working in IT since he was 16 years old. Within these years, he gained a lot of experience in different kinds of expertise. I guess like most of you, he started working with active directory environments. In June 2021 he received the MVP status in the category Enterprise Mobility for the first time. The multi-tenant PowerShell scripted Deltacom-Cloud environment is one of his creations.

Related Articles

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Stay Connected

6,065FollowersFollow
5,933FollowersFollow

Subscribe to our newsletter

To be updated with all the latest news, offers and special announcements.

Latest Articles