Autopilot 0x81036501: MDM URI Missing in Entra Token

Introduction: Incident IT1420224 and Error 0x81036501

When a Windows Autopilot device enters its enrollment flow and never joins Microsoft Intune, the first instinct is to check the local configuration: MDM scope, user license, network connectivity. But what happens when all these parameters are correct, multiple devices from multiple tenants fail identically, and the anomaly is entirely on the Microsoft backend side?

This is exactly what happened in incident IT1420224, where tenants hosted on the Azure Scale Unit (ASU) 0102 experienced a complete outage of Intune enrollment via Autopilot, consistently returning error code 0x81036501: Expected MDM URI was not found.

This article dissects the complete chain of causality: from reading diagnostic logs to the internal architecture of the MDM policy service, including the Azure AD Graph to Microsoft Graph migration that is at the root of the problem.

Initial Symptomatology: A Silently Failed Enrollment

The first disturbing signal in this type of incident is the absence of visible error signal at the beginning of the flow. Devices normally enter the Autopilot flow, progress through the Entra ID (Azure AD) enrollment step, but completely skip the Intune enrollment phase, including the Enrollment Status Page (ESP).

Multiple devices belonging to different tenants were analyzed. All failed in exactly the same way. This pattern is fundamental: when different machines, on different tenants, produce the same faulty behavior, we immediately eliminate local causes such as:

• An Autopilot profile misconfigured on a specific tenant
• A network driver or proxy problem on a particular device
• An incorrect MDM scope configuration specific to a tenant
• Missing Intune license for a given user

[IMAGE:2:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20624%20267'%3E%3C/svg%3E:]

Delimiting the Impact Scope: The Importance of Azure Scale Unit

Before analyzing logs, the first operational question is: what is the radius of impact? Is it an isolated tenant, an Azure region, a specific Scale Unit, or a global problem?

The concept of Azure Scale Unit (ASU) is central to Entra ID architecture. Microsoft divides its identity infrastructure into independent scaling units. Each tenant is assigned to a specific ASU. Code deployments and service migrations can be performed progressively by ASU, which explains why an incident can affect some tenants but not others.

[IMAGE:4:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20658%20259'%3E%3C/svg%3E:]

In this case, all impacted tenants were located on ASU 0102. This correlation is decisive for two reasons:

1. It definitively excludes any local or tenant configuration cause
2. It directs the investigation toward a code change or service deployment specific to this ASU

Log Analysis: ModernDeployment Diagnostics and dsregcmd

ModernDeployment Diagnostics logs are the primary source of information for Autopilot diagnosis. They are accessible via the integrated log collection tool in the ESP or manually on the device via:

1# Collection of Autopilot and MDM logs
2mdmdiagnosticstool.exe -area Autopilot -cab C:\MDMLogs\AutopilotDiag.cab

In these logs, both analyzed devices failed during the DeviceDiscovery phase with the same HRESULT:

1HRESULT: 0x81036501
2Message: Expected MDM URI was not found

[IMAGE:5:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20658%20249'%3E%3C/svg%3E:0x81036501]

The most significant log line specifies: Mobile Device Management MDM is not configured. This message is far more informative than the error code alone: it indicates that Windows did not find a valid MDM configuration in the information received during Entra join.

[IMAGE:7:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20658%20165'%3E%3C/svg%3E:]

The command dsregcmd /status confirms the diagnosis on the device side:

1# Run as local administrator
2dsregcmd /status

In the output, the MDMUrl field appears empty or absent:

1+----------------------------------------------------------------------+
2| Device State                                                         |
3+----------------------------------------------------------------------+
4 
5             AzureAdJoined : YES
6          EnterpriseJoined : NO
7              DomainJoined : NO
8               Device Name : DESKTOP-XXXXXXX
9 
10+----------------------------------------------------------------------+
11| Device Details                                                       |
12+----------------------------------------------------------------------+
13 
14                  TenantId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
15               Tenant Name : contoso.onmicrosoft.com
16              MDMUrl       :          <-- EMPTY: cause of failure
17           MDMToUrl        :
18        MDMComplianceUrl   :

[IMAGE:6:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20658%20129'%3E%3C/svg%3E:]

Temporary Workaround: Manual Injection of MDM URLs into Registry

In an operational emergency situation, it is possible to forcefully initiate Intune enrollment by injecting MDM URLs directly into the Windows registry. This approach is a temporary workaround and does not substitute for resolving the backend problem.

1# PowerShell script - Manual injection of Intune MDM URLs into registry
2# To be executed in SYSTEM context or local administrator
3# Reference: https://learn.microsoft.com/en-us/windows/client-management/mdm/mdm-enrollment-of-windows-devices
4 
5$key = 'SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo\*'
6 
7# Dynamic retrieval of TenantId from registry
8$keyinfo = Get-Item "HKLM:$key"
9$url = $keyinfo.name
10$url = $url.Split("\\")[-1]
11$path = "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo\$url"
12 
13Write-Host "Target registry path: $path" -ForegroundColor Cyan
14 
15# Injection of Intune MDM enrollment URL
16New-ItemProperty -LiteralPath $path `
17    -Name 'MdmEnrollmentUrl' `
18    -Value 'https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc' `
19    -PropertyType String -Force -ea SilentlyContinue
20 
21# Injection of Terms of Use URL
22New-ItemProperty -LiteralPath $path `
23    -Name 'MdmTermsOfUseUrl' `
24    -Value 'https://portal.manage.microsoft.com/TermsofUse.aspx' `
25    -PropertyType String -Force -ea SilentlyContinue
26 
27# Injection of Compliance URL
28New-ItemProperty -LiteralPath $path `
29    -Name 'MdmComplianceUrl' `
30    -Value 'https://portal.manage.microsoft.com/?portalAction=Compliance' `
31    -PropertyType String -Force -ea SilentlyContinue
32 
33Write-Host "MDM URLs injected successfully. Verification:" -ForegroundColor Green
34Get-ItemProperty -LiteralPath $path | Select-Object MdmEnrollmentUrl, MdmTermsOfUseUrl, MdmComplianceUrl

Architecture of the MDM_Enrollment_URL Claim in the Identity Token

To understand why the absence of a single field in a token can block the entire enrollment, we must understand the role of the MDM_Enrollment_URL claim in the Autopilot flow.

During an Entra ID Join initiated by Autopilot, Windows performs the following operations:

1. Device Discovery: Windows contacts the Autopilot discovery endpoint
2. Entra Join: The device obtains an identity token via the Entra authentication flow
3. Reading the MDM claim: Windows inspects the token to extract the MDM_Enrollment_URL claim
4. MDM Enrollment: Windows uses this URL to initiate enrollment to Intune

[IMAGE:8:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20336%20229'%3E%3C/svg%3E:mdm_enrollment_URL needed]

If the MDM_Enrollment_URL claim is absent from the token, Windows can still complete the Entra join (as this claim is not required for this step), but automatic MDM enrollment is impossible. The device becomes Entra Joined without being Intune Managed.

[IMAGE:9:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%201024%20576'%3E%3C/svg%3E:]

Here's how to query the current state of the MDM policy via Microsoft Graph to validate the configuration:

1# Verification of MDM policy via Microsoft Graph
2# Requires Microsoft.Graph module or OAuth 2.0 authentication
3 
4# Install module if necessary
5Install-Module Microsoft.Graph -Scope CurrentUser -Force
6 
7Connect-MgGraph -Scopes "Policy.Read.All"
8 
9# Retrieval of configured MDM policies
10$mdmPolicies = Invoke-MgGraphRequest -Method GET `
11    -Uri "https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies"
12 
13$mdmPolicies.value | Select-Object displayName, isValid, appliesTo, discoveryUrl, complianceUrl, termsOfUseUrl

The expected output for a correctly configured Intune tenant:

1{
2  "displayName": "Microsoft Intune",
3  "isValid": true,
4  "appliesTo": "all",
5  "discoveryUrl": "https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc",
6  "complianceUrl": "https://portal.manage.microsoft.com/?portalAction=Compliance",
7  "termsOfUseUrl": "https://portal.manage.microsoft.com/TermsofUse.aspx"
8}

Analysis of the Lookup Chain: Azure AD Graph vs Microsoft Graph

Understanding the incident requires dissecting the two data models used successively by the Microsoft backend to resolve MDM information.

The Old Azure AD Graph Model (Deprecated)

In the Azure AD Graph architecture, the backend resolved the MDM enrollment URL via a three-step lookup chain:

Step 1 — Reading the DefaultMDMPolicy policy

The backend queried Azure AD Graph to retrieve the DefaultMDMPolicy object:

• policyType: 5
• tenantDefaultPolicy: 5
• The policyDetail field contained a reference to the Microsoft Intune AppId

[IMAGE:12:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%201024%20157'%3E%3C/svg%3E:]

Step 2 — Resolution of the Intune Service Principal

The AppId referenced in DefaultMDMPolicy is 0000000a-0000-0000-c000-000000000000, the Microsoft Intune Service Principal.

[IMAGE:13:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20364%20219'%3E%3C/svg%3E:]

The backend resolved this Service Principal and read its appData field, which contained the actual enrollment URLs:

[IMAGE:14:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20866%20234'%3E%3C/svg%3E:]

Step 3 — Token Claim Construction

The backend extracted the EnrollmentUrl value from appData and injected it into the identity token under the mdm_enrollment_url claim.

[IMAGE:15:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20265%201024'%3E%3C/svg%3E:]

The complete chain was therefore: DefaultMDMPolicy → AppId Intune → Service Principal → appData → EnrollmentUrl → claim token

The New Microsoft Graph Model

Microsoft Graph exposes MDM policy via a dedicated endpoint:

1GET https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies

The data model is structurally different. The mobileDeviceManagementPolicy resource exposes URLs directly without going through an intermediate Service Principal:

[IMAGE:16:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%201024%2099'%3E%3C/svg%3E:]

1{
2  "@odata.type": "#microsoft.graph.mobilityManagementPolicy",
3  "id": "0000000a-0000-0000-c000-000000000000",
4  "displayName": "Microsoft Intune",
5  "discoveryUrl": "https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc",
6  "complianceUrl": "https://portal.manage.microsoft.com/?portalAction=Compliance",
7  "termsOfUseUrl": "https://portal.manage.microsoft.com/TermsofUse.aspx",
8  "appliesTo": "all",
9  "isValid": true,
10  "isMdmEnrollmentDuringRegistrationDisabled": false
11}

Official Reference: mobileDeviceManagementPolicy resource type — Microsoft Learn

Root Cause of Incident IT1420224

Microsoft confirmed in incident IT1420224 that the migration of the Mobility Management Policy Service from Azure AD Graph to Microsoft Graph omitted the MDM_Enrollment_URL claim in tokens issued during device enrollment on ASU 0102.

[IMAGE:10:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20658%20106'%3E%3C/svg%3E:0x81036501 IT1420224]

The failure sequence can be reconstructed as follows:

[IMAGE:17:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20354%201024%3E%3C/svg%3E:]

1GET https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies

1HRESULT: 0x81036501
2Expected MDM URI was not found

Context: The Azure AD Graph to Microsoft Graph Migration

Azure AD Graph has been officially retiring for several years. Microsoft's deprecation schedule is as follows:

• June 2023: End of three-year deprecation period, entering retirement phase
• August 2024: New applications can no longer use Azure AD Graph without explicit opt-in
• 2025-2026: Progressive migration of Microsoft internal services

[IMAGE:11:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20658%20209'%3E%3C/svg%3E:]

Official Reference: Migrate your apps from Azure AD Graph to Microsoft Graph — Microsoft Learn

What this incident demonstrates in a particularly striking way is that an API migration perceived as technical and transparent can have critical functional consequences when it affects a code path involved in the construction of authentication tokens. The fact that the Microsoft Graph data model is different from that of Azure AD Graph does not mean that the final behavior (the claim injected into the token) can be reproduced identically without exhaustive validation.

Complete Diagnosis: Recommended Verification Procedure

For any administrator facing the 0x81036501 error in an Autopilot context, here is the recommended systematic verification procedure:

Verification 1: Device State with dsregcmd

1# Run in local session on the device in question
2dsregcmd /status
3 
4# Key fields to verify in the Device State section
5# AzureAdJoined : YES (Entra join successful)
6# MDMUrl        : (must contain Intune enrollment URL)
7# MDMToUrl      : (Terms of Use URL)
8# MDMComplianceUrl : (Compliance URL)

Verification 2: CloudDomainJoin Registry Content

1# Read MDM information stored in registry post-join
2$key = 'SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo\*'
3$keyinfo = Get-Item "HKLM:$key"
4$tenantId = $keyinfo.name.Split("\\")[-1]
5$path = "HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\TenantInfo\$tenantId"
6 
7Get-ItemProperty -LiteralPath $path | Select-Object MdmEnrollmentUrl, MdmTermsOfUseUrl, MdmComplianceUrl
8# If MdmEnrollmentUrl is empty or absent: the MDM claim was missing from the token

Verification 3: MDM Policy via Microsoft Graph

1# Validate MDM configuration on tenant side
2Connect-MgGraph -Scopes "Policy.Read.All"
3 
4$response = Invoke-MgGraphRequest -Method GET `
5    -Uri "https://graph.microsoft.com/beta/policies/mobileDeviceManagementPolicies"
6 
7$response.value | ForEach-Object {
8    [PSCustomObject]@{
9        DisplayName     = $_.displayName
10        IsValid         = $_.isValid
11        AppliesTo       = $_.appliesTo
12        DiscoveryUrl    = $_.discoveryUrl
13        ComplianceUrl   = $_.complianceUrl
14        TermsOfUseUrl   = $_.termsOfUseUrl
15        EnrollmentDisabled = $_.isMdmEnrollmentDuringRegistrationDisabled
16    }
17} | Format-List

Verification 4: Collection of Autopilot Diagnostic Logs

1# Complete collection of MDM and Autopilot logs
2# To be executed from elevated session on the device in question
3mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -cab C:\Temp\AutopilotDiag.cab
4 
5# Extraction and search for error code
6Expand-Archive -Path C:\Temp\AutopilotDiag.cab -DestinationPath C:\Temp\AutopilotLogs
7Get-ChildItem C:\Temp\AutopilotLogs -Recurse -Include *.log, *.etl | ForEach-Object {
8    Select-String -Path $_.FullName -Pattern "0x81036501|MDM URI|DeviceDiscovery" -ErrorAction SilentlyContinue
9}

Technical References

• Microsoft Learn — mdmdiagnosticstool and MDM log collection
• Microsoft Learn — mobileDeviceManagementPolicy resource type (Graph API)
• Microsoft Learn — Migrate from Azure AD Graph to Microsoft Graph
• Microsoft Learn — Windows Autopilot troubleshooting
• Microsoft Learn — dsregcmd reference
• Call4Cloud — Wrath of the 0x81036501 MDM Error (cross-reference on the history of this error)

Summary of the Incident

Incident IT1420224 illustrates a particularly insidious failure scenario: no visible component was faulty. The device was functional. The tenant was correctly configured. The Intune license was present. The MDM scope was correct.

The failure lay in an omission during a backend migration, on a specific Scale Unit, in a code path responsible for constructing a single claim in a JWT token. This missing claim was sufficient to make automatic Intune enrollment impossible for all tenants on ASU 0102.

This incident also confirms that the migration from Azure AD Graph to Microsoft Graph, while technically justified, continues to generate non-trivial side effects when it touches critical paths in identity infrastructure. Proactive monitoring of Microsoft 365 Service Health and implementing alerts on Intune enrollment failures remain essential practices for any large-scale managed environment.