This blog will be about the error 0x81036501 we got during the MDM enrollment while enrolling a device with Autopilot white-glove AKA Pre-Provisioning.

1. Introduction

Today we were called in to take a look at an issue on an old device a customer wanted to reenroll but this time with Autopilot for pre-provisioning deployments. All other devices that were enrolled earlier with a normal Autopilot were giving no issues at all!

Please Note: This was the first time the customer want to use the pre-provisioning Autopilot option instead of the normal Autopilot. But at that point, we didn’t have that piece of information.

2. The Issue

A colleague of mine was just a few miles away from that specific customer, so we asked him to pay the customer a visit to solve the issue. Besides the issue itself, a one-on-one talk in person with the customer is always good!

Once on-site, we tried to do the same, but before we started we made sure there wasn’t a lingering Intune device record. As we all probably know by now that with the MC289488 Update we must remove the Intune object when using Autopilot in pre-provisioning mode. Otherwise, the MDM enrollment will fail and we will end up with the error code 0x80180014

But there wasn’t any lingering object… okay that’s weird. So we decided to wipe the device ourselves and install the device with the latest 21h2 Windows 10 build and started the pre-provisioning autopilot enrollment.

After a couple of minutes, we ended up at a stuck screen. “Preparing your device for mobile management”

This time it wasn’t a VM as I showed you in this blog. If you are interested in what could cause the 0x800705b4 error please read my blow below!

We started the provisioning but after some time, the famous Red autopilot screen was shown. This red screen was giving us the error code: 0x81036501. MDM information is not found for this Azure-Ad Device

3. Troubleshooting the issue

I guess this is the perfect reason why sometimes disabling Shift+F10 isn’t always a good solution. Luckily we totally wiped the device so we could still use the shift+F10 option this time!

So the first thing we did, was to take a look at the dsregcmd /status output and as shown below.. the MDMUrl and information were indeed missing?

When you need to troubleshoot something, the event logs are always the first place to start. So I opened the “Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot” event log

As shown above, we noticed this error in the event log: “Autopilot discovery failed to find a valid MDM. Confirm that the AAD tenant is properly provisioned and licensed for exactly one MDM. HRESULT = 0x81036501”

Okay.. that sounds exactly like the error we got on the red screen but let’s look further if we could find something useful.

I guess so because this error above ”AutopilotManager failed during device enrollment phase DeviceDiscovery. HRESULT = 0x81036501” is exactly the same error we got during Autopilot.

To be sure the MDM scope and settings were still configured we opened Intune to check it out. As shown below… it was set to “All”.

Please Note: I prefer to assign it to a specific group but this setting wasn’t the issue

Of course, Google “could” be your best friend. So we tried to find some useful information or clues. The first post on google showed us the blog from Nicola Suter

Windows Autopilot White Glove Error 0x81036501 – nicolonsky tech

Small summary: There could be multiple MDM entries configured in the Mobility (MDM and MAM) settings.

Okay, that sounded like a possible solution… So we opened Portal.Azure.com to check it out.

Too bad!.. as shown above, only Microsoft Intune exists. I guess we can be pretty sure the problem with multiple MDM entries wasn’t our issue. What to do next?

When using Autopilot, the Autopilot profile will be downloaded to your device with all of the settings in it. So we opened the registry to check it out: HKLM:\Software\Microsoft\Provisioning\Diagnostics\Autopilot

(sorry for the blurry screenshot, a little bit in a hurry to fix it) It’s mentioning this REG_SZ registry value

CloudAssignedMdmId: “fa3d9a0c-3fb0-42cc-9193-47c7ecd2edbd”

That’s definitely weird as I don’t recognize that Cloud Assigned MDM! So we wiped the device again but this time we didn’t choose the Autopilot Pre provisioning option but just a normal user-based autopilot. Within a couple of minutes, it passed the MDM enrollment part and started the device phase!

Again we opened the registry to check out that same value. On a normal working device as shown below you should expect this CloudAssignedMdmId value to be configured to “9cb77803-d937-493e-9a3b-4b49de3f5a74”,

So there is just a tiny difference between these 2 ids. Let me translate them for you

“fa3d9a0c-3fb0-42cc-9193-47c7ecd2edbd” = Microsoft Partner Center API

“9cb77803-d937-493e-9a3b-4b49de3f5a74” = Microsoft Intune Service Discovery

I guess this is definitely the reason why the device fails to register itself into MDM. Even while the device received its Autopilot profile we totally forgot to check out if the device was assigned to an Autopilot Profile.

As shown above, the Autopilot profile was configured to: “Assigned externally”? Owww.. my. that’s one thing we totally forgot. It looks like this device was uploaded from the Partner Center.

So we fetched our Partner login and searched for the proper tenant. Duhhh… there was still an Autopilot profile configured. As shown below… It’s missing the allow white-glove OOBE option.

This stupid upload is the reason why a normal user-based Autopilot was working and a white glove/pre-provisioning didn’t!

4. Fixing it!

I guess the fix is pretty easy. It also made me laugh out loud because this problem device was literally the only device assigned this profile! So we removed the profile from the device

And removed the “Old” Windows Autopilot profile in the partner center, because we already had a working one in Microsoft Intune!

After some nice talks with the customer, it became pretty obvious that that specific device was the first one that got enrolled at the time they migrated to Microsoft 365. Somehow that device ended up in the Microsoft Partner portal and got that stupid Autopilot profile assigned.

Please read this blog from Nestori about dealing with Microsoft Partners connection.

Microsoft partners: The Good, The Bad, or The Ugly? (o365blog.com)

Conclusion:

I guess I say it quite often but knowing how to troubleshoot Autopilot could help you in some situations. Even while writing this blog I am still laughing about what caused it