OMA-DM et WinDC : comprendre la double inscription qui transforme la gestion Intune

Résumé : deux inscriptions, mais une seule autorité MDM principale

Windows Declared Configuration, que j’abrège WinDC dans cet article, introduit une manière différente de gérer certaines configurations Windows. Le modèle MDM classique demande au client d’exécuter une suite d’opérations : ajouter une valeur, la remplacer, la lire ou la supprimer. WinDC transmet plutôt un document décrivant l’état attendu. Le client interprète cette déclaration, applique les ressources correspondantes et contrôle ensuite que l’état reste conforme.

La différence ne signifie pourtant pas qu’OMA-DM disparaît. Le canal historique et le canal déclaratif reposent tous deux sur le client de gestion Windows, le protocole OMA-DM et des échanges SyncML. WinDC crée un enrôlement OMA-DM supplémentaire, appelé enrôlement lié, qui dépend de l’inscription MDM principale. Le poste est donc doublement inscrit du point de vue des canaux de gestion, sans être cogéré par deux tenants indépendants et sans recevoir deux autorités MDM principales concurrentes.

Cette nuance est importante pour analyser un poste Intune moderne. Voir deux identifiants d’enrôlement sous le registre ou deux ensembles de tâches EnterpriseMgmt ne prouve pas un enrôlement défectueux. Inversement, un succès HTTP ou SyncML sur le canal lié ne prouve pas que la déclaration a finalement été appliquée : le traitement WinDC est asynchrone et son résultat doit être lu dans les nœuds de résultats et dans les journaux Windows.

Le bon modèle mental est le suivant : une inscription Intune principale, un second enrôlement OMA-DM qui lui est lié, puis deux modèles de contrôle capables de cohabiter sur le même endpoint. WinDC n’est ni un second tenant, ni le co-management MECM, ni un remplacement immédiat de tout le moteur MDM historique.

Contexte : pourquoi Windows ajoute un modèle déclaratif

Le modèle OMA-DM classique a été conçu autour de sessions pendant lesquelles le serveur et le client échangent des commandes. Il reste robuste et largement utilisé : le serveur envoie une opération SyncML vers un URI de CSP, le client l’exécute, puis renvoie un statut et éventuellement une valeur. Cette approche fonctionne très bien tant que le serveur conserve la logique d’orchestration, connaît l’ordre des opérations et revient régulièrement vérifier ou corriger l’état.

À mesure que les politiques deviennent plus complexes, ce modèle montre une limite opérationnelle : un code de retour positif confirme surtout que la commande a été acceptée ou exécutée à cet instant. Il ne représente pas nécessairement l’intention complète de la configuration, ses dépendances ou sa conformité durable. Le service doit souvent relire l’état, comparer le résultat et réémettre une commande. Un conflit entre plusieurs profils peut également devenir difficile à expliquer si deux chemins écrivent successivement sur la même ressource.

WinDC déplace une partie de cette logique sur le poste. Le service transmet une déclaration complète avec un identifiant de document, un contexte, une version et des ressources. Windows construit l’état cible, applique ce qui manque, publie des résultats et réévalue périodiquement la déclaration. La documentation Microsoft indique un cycle de rafraîchissement par défaut de quatre heures pour les déclarations. Ce rythme ne doit pas être confondu avec le rythme de synchronisation Intune général, avec la tâche de certificat MDM ou avec la fonctionnalité distincte Config Refresh.

Dans Intune, cette architecture permet à Microsoft de faire évoluer certaines charges de travail sans réécrire immédiatement tout le plan de gestion historique. Des observations de terrain associent déjà le canal lié à des fonctions modernes comme l’inventaire enrichi ou certaines stratégies d’élévation. Je les traite comme des indices d’implémentation, pas comme une API publique stable : les noms internes, les déclencheurs et les charges de travail peuvent évoluer indépendamment de la documentation contractuelle.

• OMA-DM classique : le serveur orchestre une séquence d’actions et lit leur statut.
• WinDC : le serveur déclare l’état attendu et le client assure l’application et la réconciliation.
• Les deux chemins utilisent OMA-DM ; leur différence principale se situe dans le modèle de contrôle, le cycle de traitement et la propriété des ressources.
• La double inscription est une relation parent-enfant : l’enrôlement déclaratif n’existe pas seul.

Le moteur historique : OMA-DM, SyncML et les CSP

OMA Device Management 1.2 est le protocole de gestion pris en charge par Windows pour les scénarios MDM. La communication s’effectue en HTTPS. Chaque session comporte une phase d’authentification et d’initialisation, puis une phase de gestion pendant laquelle le serveur et le client échangent des messages SyncML. Le client Windows expose un arbre de gestion adressable sous des URI comme ./Device ou ./User ; les CSP traduisent ensuite ces opérations en modifications réellement comprises par Windows.

Les commandes les plus fréquentes sont Add, Replace, Get, Delete et Exec. Atomic et Sequence permettent de regrouper ou d’ordonner certaines actions. Chaque commande porte un CmdID, chaque cible utilise un LocURI et la réponse contient des codes d’état. Un statut 200 indique généralement que la commande a été traitée avec succès ; 202 indique une acceptation pour traitement. D’autres statuts OMA-DM, HRESULT ou codes propres au CSP doivent être interprétés avec le contexte de la session.

Le fichier de provisioning SyncML possède une enveloppe SyncHdr et un corps SyncBody. L’en-tête identifie la version du protocole, la session, le message, la source et la destination. Le corps contient les commandes, leurs identifiants et les URI cibles. Le LocURI Windows ne doit pas commencer par une barre oblique : ./Device/Vendor/MSFT/... est correct, /Device/Vendor/MSFT/... ne l’est pas.

Dans ce modèle, le serveur peut envoyer Replace aujourd’hui, recevoir un succès, puis envoyer Get lors d’une synchronisation ultérieure pour vérifier la valeur. Si une autre autorité locale ou un autre profil modifie la même ressource entre-temps, la plateforme doit arbitrer le conflit ou le service doit réappliquer son intention. La transaction décrit donc une action ; elle ne transporte pas toujours à elle seule la totalité du contrat de conformité attendu.

<SyncBody>
  <Get>
    <CmdID>10</CmdID>
    <Item>
      <Target>
        <LocURI>./Device/Vendor/MSFT/Policy/Config/Experience/AllowWindowsSpotlight</LocURI>
      </Target>
    </Item>
  </Get>
  <Replace>
    <CmdID>20</CmdID>
    <Item>
      <Target>
        <LocURI>./Device/Vendor/MSFT/Policy/Config/Experience/AllowWindowsSpotlight</LocURI>
      </Target>
      <Meta><Format xmlns="syncml:metinf">int</Format></Meta>
      <Data>0</Data>
    </Item>
  </Replace>
  <Final />
</SyncBody>

Le nouveau modèle : Windows Declared Configuration

WinDC ajoute une couche déclarative au-dessus du socle de gestion Windows. Le serveur ne décrit plus seulement une suite d’écritures ; il remet au client un document d’état souhaité. Ce document comporte un identifiant unique, un contexte Device ou User, une version et une collection de ressources. Le client conserve la déclaration, calcule ce qu’il doit appliquer, exécute les fournisseurs de ressources et publie un document de résultats.

Cette architecture sépare clairement trois temps. La découverte permet à Windows d’obtenir les points de terminaison et la politique d’authentification du service déclaratif. L’enrôlement lié crée ensuite le canal OMA-DM secondaire. Enfin, les sessions de gestion remettent les documents et lisent les états. La mise en œuvre reste donc dépendante d’OMA-DM, mais l’objet manipulé et la responsabilité du client sont différents.

Une déclaration est traitée de manière asynchrone. Le serveur peut recevoir un statut OMA-DM positif pour la remise du document alors que Windows n’a pas encore terminé l’application de toutes les ressources. Il faut distinguer l’accusé de transport, l’état du document et le résultat de chaque ressource. Pour une validation sérieuse, je cherche au minimum l’identifiant du document, son état de traitement, le résultat par ressource et les événements corrélés.

Le modèle déclaratif permet aussi une correction de dérive. Lors du rafraîchissement, Windows reteste les ressources de la déclaration et réapplique celles qui ne correspondent plus à la cible. Cela réduit le besoin pour le service de reconstruire en permanence une séquence Get-Compare-Set. Cette capacité n’annule pas les conflits : elle impose au contraire une propriété explicite afin qu’un autre canal ne réécrive pas en parallèle sur la même ressource.

Comment la double inscription se construit

Le prérequis fondamental est l’existence d’une inscription MDM principale. La documentation Microsoft précise que la double inscription déclarative ne peut être demandée que lorsqu’un poste est déjà inscrit dans le MDM principal. Le serveur historique déclenche la découverte WinDC au moyen des nœuds LinkedEnrollment du DMClient CSP. Windows transmet alors un JSON de découverte au point de terminaison indiqué.

La requête décrit notamment le domaine utilisateur, l’UPN lorsque le contexte l’autorise, l’identifiant du tenant, l’identifiant MDM du terminal, le type d’enrôlement et la version du système. Le service répond avec les URL de découverte et d’enrôlement ainsi qu’une politique d’authentification. Pour un appareil joint à Microsoft Entra, le type est Device et le scénario documenté utilise une authentification fédérée avec jeton d’appareil. Pour un appareil enregistré dans Entra, le type est User et l’enrôlement peut s’appuyer sur le certificat MDM parent.

Le DMClient CSP expose DiscoveryEndpoint, Enroll, EnrollStatus, LastError et Unenroll dans la branche LinkedEnrollment. Le serveur configure le point de terminaison de découverte, déclenche Enroll, puis suit EnrollStatus. Les valeurs documentées vont de 0 à 8 : non défini, inscription non démarrée, en cours, en échec ou réussie, puis les quatre états équivalents pour la désinscription. LastError complète le diagnostic lorsque l’état indique un échec.

Après la réussite, Windows crée un nouvel identifiant d’enrôlement sous HKLM\SOFTWARE\Microsoft\Enrollments et un nouvel ensemble de tâches sous Microsoft\Windows\EnterpriseMgmt. Cet enrôlement reste relié au parent. Il possède son propre calendrier de communication et peut apparaître avec des marqueurs tels que MicrosoftManagementPlatformCloud dans les observations de terrain. Je n’utilise toutefois pas ce libellé comme contrat : l’enrôlement lié et son état documenté constituent la preuve durable, pas un nom interne isolé.

{
  "userDomain": "contoso.example",
  "upn": "utilisateur@contoso.example",
  "tenantId": "00000000-0000-0000-0000-000000000000",
  "emmDeviceId": "11111111-1111-1111-1111-111111111111",
  "enrollmentType": "Device",
  "osVersion": "10.0.26100.0000"
}

Cohabitation simultanée et propriété des ressources

Une fois le canal lié actif, les deux moteurs peuvent communiquer avec le poste à des moments différents. Le canal historique continue de gérer les politiques, certificats, applications et autres charges de travail qui lui sont attribuées. Le canal WinDC reçoit uniquement les déclarations prévues pour lui. La coexistence est donc une répartition de responsabilités, pas une course où les deux moteurs devraient écrire la même valeur.

La notion centrale est la propriété de la ressource. Lorsqu’une configuration historique est migrée vers WinDC, la plateforme doit transférer la propriété avant que la déclaration ne prenne le contrôle. Microsoft documente qu’une tentative d’écriture par le canal MDM historique sur une ressource désormais détenue par la configuration déclarative peut échouer avec 0x86000031. Ce code n’indique pas nécessairement que le CSP est cassé : il peut protéger l’état déclaré contre une écriture concurrente.

Cette protection explique pourquoi il ne faut pas corriger un échec apparent en recréant immédiatement la même configuration dans un profil OMA-URI. Si WinDC détient déjà la ressource, la nouvelle écriture historique augmente le conflit au lieu de le résoudre. Je commence par identifier le propriétaire, le document et le contexte. Je ne retire ou ne migre une politique qu’après avoir établi le chemin de retour arrière.

Certaines ressources de connectivité — VPN, Wi-Fi, certificats, ActiveSync, réseau filaire ou autorités racines — sont explicitement abordées par la documentation Resource Access. Ces scénarios illustrent la capacité de WinDC à regrouper plusieurs composants dépendants dans une déclaration cohérente. Ils montrent aussi pourquoi un rollback doit être conçu au niveau de chaque ressource : supprimer un document n’implique pas automatiquement que toutes les valeurs qu’il a posées disparaissent.

Si une écriture historique échoue avec 0x86000031, je vérifie d’abord si la ressource a été transférée à WinDC. Réessayer en boucle ou créer un second profil n’est pas une stratégie de correction.

Comparaison détaillée des deux moteurs

Comparer OMA-DM et WinDC uniquement comme un ancien et un nouveau protocole produit une conclusion incorrecte. OMA-DM reste le protocole de transport et de session dans les deux cas. La comparaison utile oppose le canal MDM principal orienté commandes au canal lié orienté état souhaité. Elle doit aussi distinguer ce que le serveur confirme immédiatement de ce que Windows a réellement appliqué.

Le tableau suivant résume les différences qui ont un impact direct sur l’exploitation. Il ne signifie pas que toutes les stratégies Intune ont déjà migré vers WinDC. L’affectation d’une charge de travail dépend du service, de la version Windows et de la disponibilité documentée. Un poste peut donc utiliser les deux modèles pendant longtemps.

Anatomie d’un document de configuration déclarative

Le DeclaredConfiguration CSP expose des nœuds permettant de soumettre un document complet et de lire ses résultats. L’URI contient un DocID, généralement un GUID. L’attribut id du document doit correspondre à cet identifiant. Le contexte Device ou User doit être cohérent avec la portée de l’enrôlement et des ressources. Une incohérence entre URI, identifiant et contexte entraîne des erreurs difficiles à interpréter si l’on ne conserve pas la corrélation.

Un document peut regrouper plusieurs ressources. Chaque ressource définit un type, un identifiant et des propriétés. Windows remet ces éléments aux fournisseurs déclaratifs intégrés ou extensibles, puis écrit un résultat global et des résultats détaillés. Dans un scénario réel, le schéma exact, les espaces de noms, les propriétés autorisées et la disponibilité doivent être validés dans la documentation de la ressource. L’exemple ci-dessous ne doit pas être envoyé à un poste.

La page publique du DeclaredConfiguration CSP affiche actuellement plusieurs nœuds comme disponibles en Windows Insider Preview. Cette mention oblige à séparer deux questions : Microsoft utilise et documente bien WinDC comme architecture Windows, mais la création libre de documents personnalisés via chaque nœud CSP n’est pas automatiquement un scénario supporté en production. Je classe donc toute expérimentation personnalisée comme NO-GO production tant que la version ciblée et le support officiel ne sont pas explicitement établis.

<?xml version="1.0" encoding="utf-8"?>
<DeclaredConfiguration
  id="22222222-2222-2222-2222-222222222222"
  context="device"
  schema="1.0"
  version="1.0">
  <Resources>
    <Resource id="ExampleResource" type="MSFT_ExampleResource">
      <Property name="DesiredValue">Enabled</Property>
    </Resource>
  </Resources>
</DeclaredConfiguration>

Prérequis, versions et limites de support

Avant d’associer un comportement au moteur déclaratif, je valide l’identité du poste, son édition et sa build. Les appareils Microsoft Entra joints sont documentés sur Windows 10 et Windows 11. Les appareils simplement enregistrés dans Entra ont des minima de maintenance précis : Windows 11 24H2 build 26100.1301, Windows 11 23H2 build 22631.3958, Windows 11 22H2 build 22621.3958 et Windows 10 22H2 build 19045.4717. Ces seuils proviennent de la documentation Microsoft consultée pour cet article et doivent être revérifiés au moment du diagnostic.

Le poste doit disposer d’une inscription MDM principale valide, de certificats utilisables, d’une connectivité HTTPS vers les points de terminaison concernés et d’une heure correcte. Côté serveur, les exigences OMA-DM Windows imposent notamment HTTPS et un certificat serveur valide. Une inspection TLS, un proxy authentifiant ou une rupture de chaîne de confiance peut casser la découverte ou l’enrôlement lié alors que la synchronisation principale semble encore partiellement fonctionnelle.

Je ne déduis pas la disponibilité d’une fonction Intune à partir de la seule présence de dcsvc, d’une tâche MMP-C ou d’une clé de registre. Ce sont des indices utiles, mais la disponibilité réelle dépend aussi du service cloud, de la licence, de la version Windows et du déploiement progressif. De même, la documentation d’extensibilité décrit un fournisseur WMI/MI natif avec GetTargetResource, TestTargetResource et SetTargetResource et limite ses propriétés aux chaînes ; elle ne transforme pas ce mécanisme en contrat de développement général pour toutes les éditions.

Observer la double inscription sur un poste Windows

Je commence par construire une chronologie plutôt que par supprimer des clés. Le registre des enrôlements se trouve sous HKLM\SOFTWARE\Microsoft\Enrollments\<GUID>. Les sous-clés et valeurs permettent d’identifier les inscriptions présentes et la relation LinkedEnrollment. Les tâches planifiées se trouvent sous Bibliothèque du Planificateur de tâches\Microsoft\Windows\EnterpriseMgmt\<GUID>. Chaque GUID doit être corrélé avec le registre, les certificats de gestion et les événements.

Les journaux principaux sont Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin et Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Operational. Le premier fournit les erreurs et événements importants ; le second offre une chronologie plus détaillée lorsque son activation est pertinente. J’utilise aussi MdmDiagnosticsTool.exe pour produire un rapport MDM, puis je recherche l’identifiant d’enrôlement, le DocID, l’URI CSP, le code d’erreur et l’horodatage commun.

Le script suivant est un exemple de diagnostic en lecture seule, niveau 1. Il inventorie les inscriptions, recherche une sous-clé LinkedEnrollment et compte les tâches associées. Il ne confirme pas à lui seul qu’une déclaration est appliquée. Il évite volontairement d’afficher UPN, URL de découverte ou données de certificat afin de limiter l’exposition d’informations d’organisation.

# Exemple pédagogique non testé — niveau 1
#Requires -Version 5.1

$ErrorActionPreference = 'Stop'

try {
    $enrollmentRoot = 'HKLM:\SOFTWARE\Microsoft\Enrollments'

    if (-not (Test-Path -LiteralPath $enrollmentRoot)) {
        throw "La racine des enrôlements MDM est introuvable."
    }

    $snapshot = foreach ($enrollmentKey in Get-ChildItem -LiteralPath $enrollmentRoot) {
        $properties = Get-ItemProperty -LiteralPath $enrollmentKey.PSPath
        $linkedEnrollmentPath = Join-Path -Path $enrollmentKey.PSPath -ChildPath 'LinkedEnrollment'
        $taskPath = "\Microsoft\Windows\EnterpriseMgmt\$($enrollmentKey.PSChildName)\"
        $tasks = @(Get-ScheduledTask -TaskPath $taskPath -ErrorAction SilentlyContinue)

        [PSCustomObject]@{
            EnrollmentId       = $enrollmentKey.PSChildName
            ProviderId         = $properties.ProviderID
            EnrollmentType     = $properties.EnrollmentType
            HasLinkedEnrollment = Test-Path -LiteralPath $linkedEnrollmentPath
            ScheduledTaskCount = $tasks.Count
        }
    }

    $snapshot | Sort-Object -Property EnrollmentId | Format-Table -AutoSize
}
catch {
    Write-Error "Échec de l’inventaire MDM : $($_.Exception.Message)"
    exit 1
}

Lire les résultats, les journaux et les codes d’erreur

L’analyse WinDC doit séparer quatre couches. La couche réseau confirme que le client atteint le service en HTTPS. La couche OMA-DM confirme que la session et la commande SyncML sont acceptées. La couche DeclaredConfiguration confirme que le document est valide et traité. Enfin, la couche ressource confirme que chaque fournisseur a atteint l’état souhaité. Une erreur dans une couche supérieure ne doit pas être masquée par un succès inférieur.

Le code 0x86000031 est particulièrement important pendant la cohabitation : il peut signaler une ressource désormais possédée par WinDC. Le code 0x86000002 renvoie généralement à une URI ou un nœud introuvable. Des erreurs comme 0x82D00007 ou 0x8000FFFF apparaissent dans les exemples de diagnostic Microsoft et doivent être corrélées à l’événement complet, au document et à la build ; le code seul ne suffit pas à choisir une correction.

Je ne copie jamais une trace brute dans un ticket public. Les événements peuvent contenir UPN, TenantId, DeviceId, URL de service, empreinte de certificat ou contenu de politique. Je conserve l’original dans l’espace de support autorisé, puis je produis un extrait anonymisé avec l’heure, le canal, l’identifiant de corrélation, l’opération, l’URI raccourcie et le résultat.

[2026-08-15 09:14:22.118] Channel=LinkedEnrollment EnrollmentId={REDACTED-GUID}
[2026-08-15 09:14:22.409] Operation=Replace CSP=DeclaredConfiguration DocId={REDACTED-DOCID}
[2026-08-15 09:14:22.512] TransportStatus=200 Processing=Accepted
[2026-08-15 09:14:27.904] Resource=MSFT_ExampleResource State=Failed Result=0x82D00007
[2026-08-15 09:14:27.905] Conclusion=Transport_OK_Resource_FAILED

Dépannage étape par étape

Quand une charge Intune supposée déclarative ne produit pas le résultat attendu, je résiste à la tentation de lancer immédiatement une synchronisation répétée ou de supprimer l’enrôlement. La méthode la plus fiable consiste à localiser l’échec dans la chaîne. Chaque étape doit produire une preuve et déterminer la suivante.

Je vérifie d’abord si la fonctionnalité est réellement documentée pour la build et le type d’identité. Je confirme ensuite que l’inscription principale est saine. Puis je recherche la demande de découverte, l’état de l’enrôlement lié, la remise du document et le résultat de la ressource. Si l’échec concerne la propriété, je traite la migration ou le retrait de l’ancienne politique ; s’il concerne le fournisseur, je vérifie la ressource et son schéma ; s’il concerne le réseau, je corrige le chemin HTTPS avant de toucher aux politiques.

Rollback, abandon d’un document et points de vigilance

Le rollback WinDC ne doit jamais se résumer à supprimer le document. La documentation Microsoft précise que la suppression d’un document de configuration déclarative ne supprime pas nécessairement les paramètres qui ont été appliqués. Il faut connaître le comportement de chaque ressource : certaines nécessitent une nouvelle déclaration avec l’état précédent, d’autres une opération de suppression explicite, et d’autres encore un transfert de propriété vers le canal historique.

Le nœud Abandoned mérite une vigilance supplémentaire. Dans la page Microsoft consultée, le tableau de valeurs et les exemples d’opérations ne décrivent pas le sens de 0 et 1 de manière parfaitement cohérente : les exemples indiquent qu’une valeur 1 abandonne le document et qu’une valeur 0 le réactive. Je considère cette divergence documentaire comme un blocage pour toute automatisation non pilotée. Avant usage, je revalide la version actuelle de la page, la build Windows et le comportement sur un poste de laboratoire.

La désinscription liée via Unenroll est une opération de cycle de vie, pas un remède générique. Elle peut interrompre les charges dépendantes et sera éventuellement recréée par le service si l’inscription principale la redemande. De même, supprimer manuellement une clé Enrollment, un certificat ou un dossier de tâches rompt la corrélation et rend le diagnostic plus difficile. Je réserve ces opérations à une procédure Microsoft ou éditeur explicitement supportée, avec sauvegarde des preuves et plan de réinscription.

Pour une migration pilote, mes critères GO sont : version supportée, inscription parent saine, enrôlement lié stable, document et ressources en succès sur deux cycles, absence d’écriture concurrente, dérive corrigée comme prévu et rollback testé. Mes critères NO-GO sont : documentation CSP encore limitée à Insider pour le scénario personnalisé, propriété inconnue, statut asynchrone non corrélé, dépendance réseau non maîtrisée, résultat différent entre deux postes identiques ou retour arrière non démontré.

• Hypothèse : la charge de travail étudiée utilise réellement WinDC ; je la confirme avec les résultats et les événements, pas avec un simple nom de tâche.
• Risque : une ancienne politique OMA-DM continue d’écrire sur une ressource transférée ; je retire l’affectation concurrente uniquement sur pilote.
• Impact : la désinscription ou l’abandon peut arrêter l’application et la réconciliation de plusieurs ressources liées.
• Rollback : restaurer l’état de chaque ressource, sa propriété et l’affectation précédente, puis vérifier les deux canaux.
• Généralisation : étendre par anneaux après deux cycles stables et conservation des preuves de conformité.

Ce qu’il faut retenir pour Intune

La double inscription WinDC marque une évolution profonde, mais progressive, de la gestion Windows. Le poste ne passe pas brutalement d’OMA-DM à une technologie entièrement séparée. Il conserve son enrôlement principal et le transport OMA-DM, puis ajoute un canal lié pour les configurations déclaratives. Cette continuité permet à Intune et à Windows de faire cohabiter les charges historiques et modernes sans migrer tout le catalogue en une seule fois.

Pour l’ingénieur endpoint, le changement principal concerne la preuve. Dans le modèle historique, je suis la session, la commande, l’URI CSP et le statut. Dans WinDC, j’ajoute l’enrôlement lié, le DocID, le contexte, la propriété, le résultat du document, le résultat de la ressource et le cycle de réconciliation. Une investigation fiable relie ces éléments dans le temps.

Le second changement concerne les corrections. Réémettre une commande ou créer un OMA-URI concurrent peut être contre-productif si WinDC possède déjà la ressource. Avant toute action, je détermine quelle voie contrôle la valeur, si le document est toujours actif et comment la ressource revient à son état précédent. Cette discipline protège à la fois la configuration et la possibilité de revenir en arrière.

Enfin, je garde une séparation stricte entre architecture documentée et indices de terrain. Les observations MVP sont précieuses pour reconnaître les tâches, services et rythmes réellement vus sur des appareils Intune, mais je les recoupe avec les pages Microsoft et je n’en fais pas un contrat de support. C’est ce croisement qui permet d’expliquer WinDC sans inventer ce que le service cloud ne publie pas encore.

En une phrase : WinDC utilise un deuxième enrôlement OMA-DM pour faire appliquer et maintenir un état déclaré, tandis que le canal MDM principal continue de gérer les ressources qui lui appartiennent. La cohabitation est normale ; l’écriture concurrente sur une même ressource ne l’est pas.