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

Résumé

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.

Contexte, objectif et périmètre

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.

Je traite « Synchronisations MDM, IME et WinDC » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

Ma méthode part du symptôme observable, formule plusieurs hypothèses concurrentes, puis cherche la preuve capable d’en éliminer une. Je ne commence pas par vider un cache, supprimer une clé ou réinstaller un agent : ces actions modifient précisément l’état qui permettrait de comprendre l’incident. La collecte initiale reste donc en lecture seule.

Une correction n’est proposée qu’après localisation de la phase en échec. Je distingue toujours le contournement temporaire, la correction causale et la correction structurelle. Le retour arrière est préparé avant la modification, puis le résultat est contrôlé sur un pilote représentatif avant toute généralisation.

• Objectif : cartographier les trois cycles
• Objectif : identifier le déclencheur et la preuve de chaque session
• Objectif : distinguer latence normale et rupture technique
• Périmètre : postes Windows gérés par Intune
• Périmètre : MDM OMA-DM, IME et Windows Declared Configuration
• Périmètre : sync portail, locale et Graph

Architecture et fonctionnement général

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é.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• 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

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

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.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$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 }

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• 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

Journaux, diagnostic et constitution des preuves

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

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : aucun rollback pour une simple lecture ou sync
• Rollback : restaurer affectation si un test pilote l’a modifiée
• Rollback : réinscrire uniquement via procédure supportée si cette action était planifiée
• Vigilance : ne pas lancer plusieurs triggers simultanés
• Vigilance : ne pas supprimer Enrollment ou tâches
• Vigilance : ne pas confondre délai et échec
• Vigilance : ne pas présenter DirectSync comme une API stable