Intune : diagnostiquer un enrôlement Windows incomplet ou défectueux

Résumé opérationnel

L’enrôlement vérifie licence, portée MDM, restrictions et autorisations Entra avant de découvrir le service, obtenir un certificat et créer le compte OMA-DM.

Les événements User Device Registration et DeviceManagement-Enterprise-Diagnostics-Provider, le certificat MS-Organization-Access et les tâches EnterpriseMgmt permettent de localiser la phase.

Un résidu d’une ancienne inscription doit être prouvé par les identifiants et dates. Une réinscription contrôlée n’est envisagée qu’après collecte et selon une procédure supportée.

L’enrôlement vérifie licence, portée MDM, restrictions et autorisations Entra avant de découvrir le service, obtenir un certificat et créer le compte OMA-DM.

Symptôme, contexte et périmètre de l’incident

L’auto-enrollment utilise la portée MDM et l’identité Entra. Une restriction de plateforme, une limite de devices ou une licence absente peut arrêter le processus avant tout artefact local.

La découverte renvoie les endpoints MDM. Le client s’authentifie, demande son certificat et crée l’enrôlement sous HKLM\SOFTWARE\Microsoft\Enrollments et Provisioning\OMADM.

Les tâches EnterpriseMgmt déclenchent les sessions. Le DM-EDP/Admin expose les codes tels que 0x8018002b; l’événement complet et la phase restent plus utiles que le code isolé.

• Intune, Enrollment, MDM
• Endpoint Lab — Identity, Discovery, Enrollment, Check-in
• compte et licence valides, version Windows supportée, portée MDM connue

Questions à résoudre et méthode de diagnostic

Pour Troubleshooting de l’enrôlement Windows, l’enquête suit le parcours Identity → Discovery → Enrollment → Check-in. L’étape utile n’est pas celle qui affiche le dernier message: c’est la première dont le résultat ne correspond plus au fonctionnement attendu.

Les premiers contrôles portent sur Lire dsregcmd et le type de jointure, Vérifier licence, portée MDM et restrictions et Corréler DM-EDP et User Device Registration. Ils permettent de dater le problème et de séparer un défaut de ciblage, de transport ou d’exécution avant d’envisager une correction.

Les symptômes « 0x8018002b, Already enrolled et Pas de tâches » peuvent se ressembler à l’écran tout en provenant de causes différentes. Chaque branche de diagnostic associe donc un signal, une preuve et une action de correction précise.

• Lire dsregcmd et le type de jointure.
• Vérifier licence, portée MDM et restrictions.
• Corréler DM-EDP et User Device Registration.

Cartographie du flux à diagnostiquer

L’auto-enrollment utilise la portée MDM et l’identité Entra. Une restriction de plateforme, une limite de devices ou une licence absente peut arrêter le processus avant tout artefact local.

La découverte renvoie les endpoints MDM. Le client s’authentifie, demande son certificat et crée l’enrôlement sous HKLM\SOFTWARE\Microsoft\Enrollments et Provisioning\OMADM.

Les tâches EnterpriseMgmt déclenchent les sessions. Le DM-EDP/Admin expose les codes tels que 0x8018002b; l’événement complet et la phase restent plus utiles que le code isolé.

État initial et prérequis de collecte

L’état initial de Troubleshooting de l’enrôlement Windows doit couvrir compte et licence valides, version Windows supportée, portée MDM connue, restrictions et limite devices contrôlées. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Identity, Discovery, Enrollment, Check-in sont contrôlées séparément. Un prérequis absent devient alors une cause identifiable, au lieu d’être noyé dans les effets des essais suivants.

• compte et licence valides
• version Windows supportée
• portée MDM connue
• restrictions et limite devices contrôlées
• HTTPS/proxy opérationnels
• clé BitLocker/LAPS disponible avant reset

Collecte des preuves : journaux, registre et états

La chronologie de Troubleshooting de l’enrôlement Windows relie Identity, Discovery, Enrollment, Check-in. Les heures et identifiants communs indiquent si les informations décrivent la même tentative.

Les états sont lus à partir de Lire dsregcmd et le type de jointure. Vérifier licence, portée MDM et restrictions. Corréler DM-EDP et User Device Registration. Relier certificat, EnrollmentId et tâches. Cette séquence sépare une absence de configuration d’un traitement en attente ou d’un échec confirmé.

Les causes « Auto-enrollment/identité », « Ancien certificat ou clone », « Enrôlement arrêté avant création », « MDM non terminé » restent des hypothèses jusqu’à ce que la preuve indiquée dans la matrice les confirme.

• Lire dsregcmd et le type de jointure.
• Vérifier licence, portée MDM et restrictions.
• Corréler DM-EDP et User Device Registration.
• Relier certificat, EnrollmentId et tâches.
• Contrôler l’objet Intune et son dernier check-in
• Collecter MDM diagnostics avant mutation
• Tester le réenrôlement sur pilote

Investigation pas à pas

L’investigation suit l’ordre Identity → Discovery → Enrollment → Check-in. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Troubleshooting de l’enrôlement Windows, les contrôles « Reproduire le symptôme », « Contrôler le ciblage », « Corréler les états » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

Fonctionnement détaillé et frontières de responsabilité

L’auto-enrollment utilise la portée MDM et l’identité Entra. Une restriction de plateforme, une limite de devices ou une licence absente peut arrêter le processus avant tout artefact local.

La découverte renvoie les endpoints MDM. Le client s’authentifie, demande son certificat et crée l’enrôlement sous HKLM\SOFTWARE\Microsoft\Enrollments et Provisioning\OMADM.

Les tâches EnterpriseMgmt déclenchent les sessions. Le DM-EDP/Admin expose les codes tels que 0x8018002b; l’événement complet et la phase restent plus utiles que le code isolé.

• compte et licence valides
• version Windows supportée
• portée MDM connue
• restrictions et limite devices contrôlées

Mise en œuvre, exploitation et cas limites

Je compare l’EnrollmentId entre registre, tâche et événement. Des branches sans tâche ni certificat, anciennes et sans objet actif sont candidates à une analyse de résidu, pas à une suppression automatique.

mdmdiagnosticstool produit un CAB comprenant rapport, événements et registre. Il peut contenir des identifiants et politiques; je le conserve dans l’espace support autorisé.

La correction traite d’abord licence, restriction, réseau, identité ou certificat. Je ne retire le poste d’Entra/Intune qu’avec un plan de réenrôlement, une sauvegarde et l’évaluation de BitLocker/LAPS.

• Contrôler l’objet Intune et son dernier check-in
• Collecter MDM diagnostics avant mutation
• Tester le réenrôlement sur pilote

Méthode de validation à l’échelle du parc

Pour troubleshooting de l’enrôlement windows, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Les mesures portent sur Lire dsregcmd et le type de jointure. Vérifier licence, portée MDM et restrictions. Corréler DM-EDP et User Device Registration. Relier certificat, EnrollmentId et tâches. Elles sont définies avant le pilote de Troubleshooting de l’enrôlement Windows afin que les seuils ne soient pas déplacés après l’observation.

Les cas « 0x8018002b », « Already enrolled », « Pas de tâches », « Objet Entra sans Intune » servent de scénarios négatifs. Ils vérifient que l’échec reste visible, localisable et associé à une correction précise.

La généralisation de Troubleshooting de l’enrôlement Windows tient compte de pas de suppression récursive Enrollment, protéger les diagnostics, évaluer BitLocker et LAPS avant suppression device, un clone peut répliquer des artefacts. Chaque vague se ferme après lecture de ces points et validation du retour à l’état connu.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent Lire dsregcmd et le type de jointure. Vérifier licence, portée MDM et restrictions. Corréler DM-EDP et User Device Registration. Relier certificat, EnrollmentId et tâches. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Troubleshooting de l’enrôlement Windows, les données utiles se lisent dans les états locaux, les journaux et les rapports cités dans chaque exemple. Une valeur isolée ne remplace pas cette corrélation.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
 dsregcmd.exe /status
 Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Enrollments' | Select-Object PSChildName, LastWriteTime
 Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 120 | Select-Object TimeCreated,Id,LevelDisplayName,Message
}
catch { Write-Error "Collecte MDM impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  dsregcmd.exe /status
  Get-ChildItem Cert:\LocalMachine\My |
    Where-Object Subject -Match 'Microsoft Intune MDM Device CA' |
    Select-Object Subject,Thumbprint,NotBefore,NotAfter
  Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 120 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[08:22:10.441] Entra       AzureAdJoined=YES DeviceAuthStatus=SUCCESS
[08:22:15.209] Discovery   Endpoint=<MDM-URL> Status=200
[08:22:18.984] Enrollment  EnrollmentId=<GUID> Certificate=Created
[08:22:19.771] Task        EnterpriseMgmt=<GUID> State=Ready
[08:22:25.110] DMClient    FirstSession=Success

Arbre de décision : symptômes, causes et corrections

La matrice couvre notamment 0x8018002b, Already enrolled, Pas de tâches, Objet Entra sans Intune. Ces symptômes servent de points d’entrée; la preuve indiquée dans la même ligne confirme ou écarte la cause.

Après correction, les contrôles Lire dsregcmd et le type de jointure, Vérifier licence, portée MDM et restrictions et Corréler DM-EDP et User Device Registration sont rejoués dans les mêmes conditions pour vérifier que le problème n’a pas simplement changé de phase.

Validation de la correction et critères de clôture

La correction de Troubleshooting de l’enrôlement Windows est validée avec les mêmes points de mesure que le diagnostic initial. Le résultat local et l’état remonté dans le service doivent raconter la même chronologie.

• Lire dsregcmd et le type de jointure.
• Vérifier licence, portée MDM et restrictions.
• Corréler DM-EDP et User Device Registration.
• Relier certificat, EnrollmentId et tâches.
• Contrôler l’objet Intune et son dernier check-in
• Collecter MDM diagnostics avant mutation
• Tester le réenrôlement sur pilote

Retour arrière, escalade et points de vigilance

Le retour arrière de Troubleshooting de l’enrôlement Windows restaure l’état connu décrit ci-dessous. Sa réussite se vérifie sur le poste et dans le service, pas seulement par la disparition d’une affectation.

Une escalade conserve les preuves correspondant à Lire dsregcmd et le type de jointure. Vérifier licence, portée MDM et restrictions. Corréler DM-EDP et User Device Registration. Relier certificat, EnrollmentId et tâches. ainsi que les causes déjà écartées.