Intune : comprendre et diagnostiquer les synchronisations MDM, IME et WinDC

Résumé opérationnel

Le canal MDM traite les politiques et actions OMA-DM. L’IME possède son propre service et ses propres charges, notamment Win32 et scripts. WinDC ajoute un enrôlement lié et un cycle déclaratif. Une action de synchronisation peut accélérer certains chemins sans effacer affectation, applicabilité, dépendance ou temporisation.

Je prouve d’abord l’identité et l’enrôlement, puis la réception du signal, la session du moteur concerné et le reporting. Un portail encore ancien n’indique pas forcément que le poste n’a rien reçu.

Je n’enchaîne pas les boutons Sync, Company Portal, redémarrage du service et suppression de clés. Sans chronologie, il devient impossible de savoir quel déclencheur a produit le résultat.

Le canal MDM traite les politiques et actions OMA-DM. L’IME possède son propre service et ses propres charges, notamment Win32 et scripts. WinDC ajoute un enrôlement lié et un cycle déclaratif. Une action de synchronisation peut accélérer certains chemins sans effacer affectation, applicabilité, dépendance ou temporisation.

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

Le vocabulaire simplifie plusieurs mécanismes sous le mot synchronisation. Le portail, l’application Paramètres, le Portail d’entreprise et une action Graph peuvent tous demander un check-in, mais les charges locales suivent ensuite leur propre planification.

Un appareil hors ligne, un certificat expiré, WNS bloqué, un service IME arrêté ou un enrôlement lié incomplet produisent des symptômes différents. L’objectif est de localiser la rupture plutôt que de réclamer un délai arbitraire.

• postes Windows gérés par Intune
• MDM OMA-DM, IME et Windows Declared Configuration
• sync portail, locale et Graph

Questions à résoudre et méthode de diagnostic

Pour Synchronisations MDM, IME et WinDC, l’enquête suit le parcours Trigger → MDM → IME → WinDC. 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 DeviceId et EnrollmentId, certificat MDM et déclencheur et heure. 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 « Sync portail sans événement local, Policy MDM reçue, Win32 inchangée et IME check-in sans installation » 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.

• cartographier les trois cycles
• identifier le déclencheur et la preuve de chaque session
• distinguer latence normale et rupture technique

Cartographie du flux à diagnostiquer

Le check-in MDM principal dépend de l’enrôlement Windows, de son certificat, des tâches EnterpriseMgmt et du service de gestion. Les événements DM-EDP racontent la session et les URI CSP.

L’IME est installé lorsqu’une charge le nécessite. Son service contacte Intune, évalue les politiques et écrit ses journaux sous ProgramData. Une synchronisation MDM n’implique pas que chaque application soit immédiatement réinstallée.

WinDC utilise un enrôlement OMA-DM lié au principal. Son cycle de document et de ressource est asynchrone; un transport accepté ne valide pas encore l’état déclaré.

État initial et prérequis de collecte

L’état initial de Synchronisations MDM, IME et WinDC doit couvrir DeviceId et EnrollmentId identifiés, heure locale et UTC notées, connectivité et proxy connus, certificat MDM valide. Cette photographie est prise avant de relancer un traitement ou de modifier une affectation.

Les couches Trigger, MDM, IME, WinDC 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.

• DeviceId et EnrollmentId identifiés
• heure locale et UTC notées
• connectivité et proxy connus
• certificat MDM valide
• service IME présent si attendu
• canaux DM-EDP accessibles
• charge WinDC confirmée avant diagnostic déclaratif

Collecte des preuves : journaux, registre et états

Je construis une chronologie à quatre colonnes: demande, début de session, décision locale, remontée. Pour l’IME, j’ajoute l’AppId; pour WinDC, le DocID; pour MDM, l’EnrollmentId et l’URI CSP.

Les chemins principaux sont le journal DM-EDP, %ProgramData%\Microsoft\IntuneManagementExtension\Logs et les tâches EnterpriseMgmt. Le registre Enrollment sert de corrélation, jamais de cible de nettoyage par défaut.

• DeviceId et EnrollmentId
• certificat MDM
• déclencheur et heure
• événement DM-EDP
• service et cycle IME
• AppId ou DocID
• connectivité WNS/HTTPS
• dernier reporting Intune

Investigation pas à pas

L’investigation suit l’ordre Trigger → MDM → IME → WinDC. La première divergence confirmée détermine la branche suivante et évite de multiplier les symptômes secondaires.

Pour Synchronisations MDM, IME et WinDC, les contrôles « Identifier le moteur attendu », « Capturer l’état avant sync », « Déclencher une seule action » précisent à la fois l’emplacement, le résultat attendu et la vérification à effectuer.

MDM : identité, tâche et session OMA-DM

Je confirme AzureAdJoined ou DomainJoined, le DeviceId et l’URL MDM avec dsregcmd /status, puis je relie l’enrôlement actif aux tâches sous Microsoft\Windows\EnterpriseMgmt. Un dossier résiduel n’est pas automatiquement le compte actif.

DeviceManagement-Enterprise-Diagnostics-Provider/Admin et Operational indiquent le début de session, les commandes et les erreurs. Je repère l’EnrollmentId et les URI concernées avant de conclure à un problème global.

Une action Sync force un check-in mais ne contourne pas une affectation absente, un filtre, une édition Windows incompatible ou une autorité concurrente. Elle réduit une latence; elle ne change pas la décision.

IME : check-in, évaluation et temporisation

Je vérifie le service IntuneManagementExtension, sa version et l’heure de ses journaux. IntuneManagementExtension.log décrit le cycle général; AppWorkload.log et AppActionProcessor.log sont prioritaires pour les applications récentes.

Le cycle évalue exigences, dépendances, supersedence et détection avant l’installation. Une application déjà conforme n’est pas relancée parce qu’un administrateur a demandé une synchronisation.

L’amélioration de synchronisation à la demande peut rapprocher le signal MDM et le check-in IME, mais les détails internes comme DirectSync restent non contractuels. Je valide le résultat observable, pas un nom interne supposé permanent.

WinDC : enrôlement lié et résultat asynchrone

Je ne recherche WinDC que si la charge est documentée ou si les événements montrent DeclaredConfiguration. La présence de deux ensembles EnterpriseMgmt peut être normale dans ce scénario.

Le DMClient CSP expose LinkedEnrollment pour la découverte et l’état d’enrôlement. Ensuite, le document possède un DocID et des résultats par ressource. Un HTTP ou SyncML 200/202 ne clôt pas le traitement.

Le rafraîchissement déclaratif périodique ne doit pas être confondu avec Config Refresh ni avec la cadence IME. Pour vérifier une dérive, j’observe le document et la ressource sur plusieurs cycles sans écrire concurremment via OMA-DM historique.

Commandes et scripts de diagnostic en lecture seule

Les exemples ci-dessous contrôlent DeviceId et EnrollmentId, certificat MDM, déclencheur et heure, événement DM-EDP. Leur sortie doit être rapprochée de l’heure de l’incident et du contexte d’exécution concerné.

Pour Synchronisations MDM, IME et WinDC, 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-Service -Name 'IntuneManagementExtension' -ErrorAction SilentlyContinue |
        Select-Object Name, Status, StartType
    Get-ScheduledTask -TaskPath '\Microsoft\Windows\EnterpriseMgmt\*' -ErrorAction SilentlyContinue |
        Select-Object TaskPath, TaskName, State
    Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 80 |
        Select-Object TimeCreated, Id, LevelDisplayName, Message
}
catch { Write-Error "Inventaire des synchronisations impossible : $($_.Exception.Message)"; exit 1 }

$ErrorActionPreference = 'Stop'
try {
  Get-ScheduledTask -TaskPath '\Microsoft\Windows\EnterpriseMgmt\*' -ErrorAction SilentlyContinue |
    Select-Object TaskPath,TaskName,State
  Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 120 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
  Get-Service -Name IntuneManagementExtension -ErrorAction SilentlyContinue |
    Select-Object Name,Status,StartType
}
catch {
  Write-Error "Collecte impossible : $($_.Exception.Message)"
  exit 1
}

[10:00:00.100] MDM   EnrollmentId=<GUID-A> Trigger=ManualSync
[10:00:07.331] MDM   Session=<ID> Result=Success
[10:01:15.008] IME   PolicyCheck AppCount=4 ScriptCount=1
[10:02:02.714] WinDC EnrollmentId=<GUID-B> Document=<DOCID> State=Accepted
[10:06:11.040] Portal LastCheckIn=10:00:07

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

La matrice couvre notamment Sync portail sans événement local, Policy MDM reçue, Win32 inchangée, IME check-in sans installation, Deux EnrollmentId. 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 moteur correctement identifié, nouvelle session horodatée et décision locale comprise 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 Synchronisations MDM, IME et WinDC 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.

• moteur correctement identifié
• nouvelle session horodatée
• décision locale comprise
• charge traitée ou erreur précise
• reporting cohérent
• aucune suppression d’état diagnostique

Retour arrière, escalade et points de vigilance

Le retour arrière de Synchronisations MDM, IME et WinDC 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 à DeviceId et EnrollmentId, certificat MDM, déclencheur et heure, événement DM-EDP ainsi que les causes déjà écartées.