Autopilot 0x81036501 : MDM URI manquant dans le token Entra

Introduction : l'incident IT1420224 et l'erreur 0x81036501

Lorsqu'un appareil Windows Autopilot entre dans son flux d'enrollment et ne rejoint jamais Microsoft Intune, l'instinct premier est de vérifier la configuration locale : scope MDM, licence utilisateur, connectivité réseau. Mais que se passe-t-il lorsque tous ces paramètres sont corrects, que plusieurs appareils de plusieurs tenants échouent de façon identique, et que l'anomalie se situe entièrement côté backend Microsoft ?

C'est exactement ce qui s'est produit dans l'incident IT1420224, où des tenants hébergés sur l'Azure Scale Unit (ASU) 0102 ont subi une interruption totale de l'enrollment Intune via Autopilot, renvoyant systématiquement le code d'erreur 0x81036501 : Expected MDM URI was not found.

Cet article décortique la chaîne de causalité complète : de la lecture des logs de diagnostic jusqu'à l'architecture interne du service de politique MDM, en passant par la migration Azure AD Graph vers Microsoft Graph qui est à l'origine du problème.

Symptomatologie initiale : un enrollment silencieusement raté

Le premier signal perturbant dans ce type d'incident est l'absence de signal d'erreur visible en début de flow. Les appareils entrent normalement dans le flux Autopilot, progressent à travers l'étape d'enrollment Entra ID (Azure AD Join), mais ignorent complètement la phase d'enrollment Intune, y compris l'Enrollment Status Page (ESP).

Plusieurs appareils appartenant à des tenants distincts ont été analysés. Tous échouaient de façon parfaitement identique. Ce pattern est fondamental : lorsque des machines différentes, sur des tenants différents, produisent le même comportement défaillant, on élimine immédiatement les causes locales telles que :

• Un profil Autopilot mal configuré sur un tenant spécifique
• Un problème de pilote réseau ou de proxy sur un appareil particulier
• Une configuration incorrecte du scope MDM propre à un tenant
• Une licence Intune manquante pour un utilisateur donné

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

Délimitation du périmètre d'impact : l'importance de l'Azure Scale Unit

Avant d'analyser les logs, la première question opérationnelle est : quel est le rayon d'impact ? S'agit-il d'un tenant isolé, d'une région Azure, d'une Scale Unit spécifique, ou d'un problème global ?

La notion d'Azure Scale Unit (ASU) est centrale dans l'architecture d'Entra ID. Microsoft découpe son infrastructure d'identité en unités de mise à l'échelle indépendantes. Chaque tenant est assigné à une ASU spécifique. Les déploiements de code et les migrations de service peuvent être effectués de façon progressive par ASU, ce qui explique pourquoi un incident peut affecter certains tenants mais pas d'autres.

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

Dans ce cas, l'ensemble des tenants impactés étaient localisés sur l'ASU 0102. Cette corrélation est déterminante pour deux raisons :

1. Elle exclut définitivement toute cause locale ou de configuration tenant
2. Elle oriente l'investigation vers un changement de code ou de service déployé spécifiquement sur cette ASU

Analyse des logs : ModernDeployment Diagnostics et dsregcmd

Les logs ModernDeployment Diagnostics constituent la source d'information primaire pour le diagnostic Autopilot. Ils sont accessibles via l'outil de collecte de logs intégré à l'ESP ou manuellement sur le poste via :

1# Collecte des logs Autopilot et MDM
2mdmdiagnosticstool.exe -area Autopilot -cab C:\MDMLogs\AutopilotDiag.cab

Dans ces logs, les deux appareils analysés ont échoué lors de la phase DeviceDiscovery avec le même 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]

La ligne de log la plus significative précise : Mobile Device Management MDM is not configured. Ce message est bien plus informatif que le code d'erreur seul : il indique que Windows n'a pas trouvé de configuration MDM valide dans les informations reçues lors du join Entra.

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

La commande dsregcmd /status confirme le diagnostic côté appareil :

1# Exécuter en tant qu'administrateur local
2dsregcmd /status

Dans la sortie, le champ MDMUrl apparaît vide ou 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       :          <-- VIDE : cause de l'échec
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:]

Contournement temporaire : injection manuelle des URLs MDM dans le registre

En situation d'urgence opérationnelle, il est possible de forcer manuellement l'enrollment Intune en injectant les URLs MDM directement dans le registre Windows. Cette approche est un workaround temporaire et ne substitue pas à la résolution du problème backend.

1# Script PowerShell - Injection manuelle des URLs MDM Intune dans le registre
2# À exécuter en contexte SYSTEM ou administrateur local
3# Référence : 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# Récupération dynamique du TenantId depuis le registre
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 "Chemin de registre ciblé : $path" -ForegroundColor Cyan
14 
15# Injection de l'URL d'enrollment MDM Intune
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 de l'URL des conditions d'utilisation
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 de l'URL de conformité
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 "URLs MDM injectées avec succès. Vérification :" -ForegroundColor Green
34Get-ItemProperty -LiteralPath $path | Select-Object MdmEnrollmentUrl, MdmTermsOfUseUrl, MdmComplianceUrl

Architecture du claim MDM_Enrollment_URL dans le token d'identité

Pour comprendre pourquoi l'absence d'un seul champ dans un token peut bloquer l'intégralité de l'enrollment, il faut comprendre le rôle du claim MDM_Enrollment_URL dans le flux Autopilot.

Lors d'un Entra ID Join initié par Autopilot, Windows effectue les opérations suivantes :

1. Device Discovery : Windows contacte le endpoint de découverte Autopilot
2. Entra Join : Le device obtient un token d'identité via le flux d'authentication Entra
3. Lecture du claim MDM : Windows inspecte le token pour extraire le claim MDM_Enrollment_URL
4. MDM Enrollment : Windows utilise cette URL pour initier l'enrollment vers 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 neededd]

Si le claim MDM_Enrollment_URL est absent du token, Windows peut tout de même compléter le join Entra (car ce claim n'est pas requis pour cette étape), mais l'enrollment MDM automatique est impossible. L'appareil devient Entra Joined sans être Intune Managed.

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

Voici comment interroger l'état actuel de la politique MDM via Microsoft Graph pour valider la configuration :

1# Vérification de la politique MDM via Microsoft Graph
2# Nécessite le module Microsoft.Graph ou une authentification OAuth 2.0
3 
4# Installation du module si nécessaire
5Install-Module Microsoft.Graph -Scope CurrentUser -Force
6 
7Connect-MgGraph -Scopes "Policy.Read.All"
8 
9# Récupération des politiques MDM configurées
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

La sortie attendue pour un tenant correctement configuré pour Intune :

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}

Analyse de la chaîne de lookup : Azure AD Graph vs Microsoft Graph

La compréhension de l'incident nécessite de disséquer les deux modèles de données utilisés successivement par le backend Microsoft pour résoudre les informations MDM.

L'ancien modèle Azure AD Graph (déprécié)

Dans l'architecture Azure AD Graph, le backend résolvait l'URL d'enrollment MDM via une chaîne de lookup en trois étapes :

Étape 1 — Lecture de la politique DefaultMDMPolicy

Le backend interrogeait Azure AD Graph pour récupérer l'objet DefaultMDMPolicy :

• policyType: 5
• tenantDefaultPolicy: 5
• Le champ policyDetail contenait une référence au 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:]

Étape 2 — Résolution du Service Principal Intune

L'AppId référencé dans DefaultMDMPolicy est 0000000a-0000-0000-c000-000000000000, soit le Service Principal Microsoft Intune.

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

Le backend résolvait ce Service Principal et lisait son champ appData, qui contenait les URLs d'enrollment réelles :

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

Étape 3 — Construction du claim token

Le backend extrayait la valeur EnrollmentUrl depuis appData et l'injectait dans le token d'identité sous le claim mdm_enrollment_url.

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

La chaîne complète était donc : DefaultMDMPolicy → AppId Intune → Service Principal → appData → EnrollmentUrl → claim token

Le nouveau modèle Microsoft Graph

Microsoft Graph expose la politique MDM via un endpoint dédié :

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

Le modèle de données est structurellement différent. La ressource mobileDeviceManagementPolicy expose directement les URLs sans passer par un Service Principal intermédiaire :

[IMAGE:16:data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%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}

Référence officielle : mobileDeviceManagementPolicy resource type — Microsoft Learn

Cause racine de l'incident IT1420224

Microsoft a confirmé dans l'incident IT1420224 que la migration du Mobility Management Policy Service depuis Azure AD Graph vers Microsoft Graph avait omis le claim MDM_Enrollment_URL dans les tokens émis lors de l'enrollment des appareils sur l'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]

La séquence de défaillance peut être reconstituée comme suit :

[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

Contexte : la migration Azure AD Graph vers Microsoft Graph

Azure AD Graph est officiellement en cours de retrait depuis plusieurs années. Le calendrier de dépréciation Microsoft est le suivant :

• Juin 2023 : Fin de la période de dépréciation de trois ans, entrée en phase de retirement
• Août 2024 : Les nouvelles applications ne peuvent plus utiliser Azure AD Graph sans opt-in explicite
• 2025-2026 : Migration progressive des services internes Microsoft

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

Référence officielle : Migrate your apps from Azure AD Graph to Microsoft Graph — Microsoft Learn

Ce que cet incident démontre de façon particulièrement frappante, c'est qu'une migration d'API perçue comme technique et transparente peut avoir des conséquences fonctionnelles critiques lorsqu'elle touche un chemin de code impliqué dans la construction de tokens d'authentification. Le fait que le modèle de données de Microsoft Graph soit différent de celui d'Azure AD Graph ne signifie pas que le comportement final (le claim injecté dans le token) peut être reproduit à l'identique sans une validation exhaustive.

Diagnostic complet : procédure de vérification recommandée

Pour tout administrateur confronté à l'erreur 0x81036501 dans un contexte Autopilot, voici la procédure de vérification systématique recommandée :

Vérification 1 : état de l'appareil avec dsregcmd

1# Exécuter en session locale sur l'appareil concerné
2dsregcmd /status
3 
4# Champs clés à vérifier dans la section Device State
5# AzureAdJoined : YES (join Entra réussi)
6# MDMUrl        : (doit contenir l'URL enrollment Intune)
7# MDMToUrl      : (URL Terms of Use)
8# MDMComplianceUrl : (URL Compliance)

Vérification 2 : contenu du registre CloudDomainJoin

1# Lecture des informations MDM stockées dans le registre 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# Si MdmEnrollmentUrl est vide ou absent : le claim MDM était manquant dans le token

Vérification 3 : politique MDM via Microsoft Graph

1# Validation de la configuration MDM côté tenant
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

Vérification 4 : collecte des logs diagnostics Autopilot

1# Collecte complète des logs MDM et Autopilot
2# À exécuter depuis une session elevated sur l'appareil concerné
3mdmdiagnosticstool.exe -area Autopilot;DeviceEnrollment;DeviceProvisioning -cab C:\Temp\AutopilotDiag.cab
4 
5# Extraction et recherche du code d'erreur
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}

Références techniques

• Microsoft Learn — mdmdiagnosticstool et collecte de logs MDM
• 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 (référence croisée sur l'historique de cette erreur)

Synthèse de l'incident

L'incident IT1420224 illustre un scénario d'échec particulièrement insidieux : aucun composant visible n'était défaillant. L'appareil était fonctionnel. Le tenant était correctement configuré. La licence Intune était présente. Le scope MDM était correct.

La défaillance résidait dans une omission lors d'une migration backend, sur une Scale Unit spécifique, dans un chemin de code responsable de la construction d'un unique claim dans un token JWT. Ce claim manquant a suffi à rendre l'enrollment Intune automatique impossible pour l'ensemble des tenants de l'ASU 0102.

Cet incident confirme également que la migration depuis Azure AD Graph vers Microsoft Graph, bien que techniquement justifiée, continue de générer des effets de bord non triviaux lorsqu'elle touche des chemins critiques d'infrastructure d'identité. La surveillance proactive du Service Health Microsoft 365 et la mise en place d'alertes sur les échecs d'enrollment Intune restent des pratiques essentielles pour tout environnement managé à grande échelle.