While testing Autopilot White glove for a customer project my test machines always got stuck within the “Registering your device for mobile management” step and timed out after 12 minutes and returned the error “0x81036501” just before showing the White Glove Failed screen. I was doing my tests with Windows 10 1903 DE (German) with the most recent cumulative update installed, meaning OS build: 18362.267.

The Issue

As normal Autopilot enrollments were working like a charm this one had to be related to the White Glove scenario. Here’s a screen capture showing the actual behavior (unfortunately with German display language):

By pressing [shift] + [F10] i opened a command prompt and launched the event viewer (eventvwr.msc). In the “Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot” event log I found the following error popping up multiple times, including a retry attempt and limit:

Autopilot discovery failed to find a valid MDM. Confirm that the AAD tenant is properly provisioned and licensed for exactly one MDM. HRESULT = 0x81036501

AutopilotManager failed during device enrollment phase DeviceDiscovery. HRESULT = 0x81036501

On the enrollment status page the error “0x81036501” got displayed for like one second before showing the red generic Autopilot White glove error screen.

I double checked the assigned license but the user had assigned a Microsoft 365 E3 license.

After some googling I saw a comment from EM+S MVP Zeng Yinghua (Sandy)who mentioned to check the registered MDM providers within the MDM and MAM section of the Azure Active Directory tenant and delete the “Microsoft Intune Enrollment” record.

I’ve already discovered this second Microsoft Intune Enrollment entry in the past but never noticed it’s purpose. The MDM and MAM scope were both configured on the “Microsoft Intune” entry and the “Microsoft Intune Enrollment” was never touched.

Registered MDM and MAM providers in AAD

After some research I actually found out that this entry is used to apply conditional access rules e.g. with the intention to enforce Multi Factor Authentication for the MDM enrollment (as documented in this Microsoft Docs Article).

If you look on the registration in detail you will probably notice that it has the same MDM discovery URL as the “real” Microsoft Intune registration.

Stale Microsoft Intune Enrollment MDM registration

So now it made sense why the Autopilot White Glove client discovered multiple MDM entries.

Workaround

Because the customer already enforces Multi Factor Authentication for registering Azure AD devices he had no requirement to use a conditional access policy for the Intune Enrollment.

So I deleted the entry and afterwards things rapidly changed - the “Prepare device phase” was now completed within a few seconds on my device and the provisioning actually started!

Please note that this is a workaround, provided as it is without any warranty. I opened a support case and hope to be in contact with the Intune team soon in order to get some more information or a suitable solution.