Vue d’ensemble du protocole de configuration déclaré par Windows

Le protocole De windows de configuration déclaré (WinDC) est un modèle de configuration d’appareil à état souhaité conçu pour une gestion efficace et fiable des appareils Windows. Il utilise le protocole SyncML OMA-DM pour fournir tous les paramètres nécessaires dans un seul lot via un serveur OMA-DM dédié. La pile cliente WinDC sur l’appareil traite ces paramètres pour atteindre l’état souhaité de la manière la plus efficace et fiable.

Le protocole WinDC nécessite qu’un appareil dispose d’une inscription OMA-DM distincte, qui dépend de l’inscription de l’appareil auprès du serveur OMA-DM principal. Le modèle d’état souhaité est un modèle différent du modèle actuel où le serveur est responsable de l’état souhaité de l’appareil. Cette double inscription n’est autorisée que si l’appareil est déjà inscrit sur un serveur de gestion des appareils mobiles (GPM) principal. Cette autre inscription sépare la fonctionnalité de gestion d’état souhaitée de la fonctionnalité principale.

L’inscription à WinDC implique deux phases :

• Détection de configuration déclarée : la phase de découverte initiale du protocole WinDC utilise un schéma JSON dédié pour interroger les détails de l’inscription à partir du point de terminaison du service de découverte (DS). Cette phase implique l’envoi de requêtes HTTP avec des en-têtes spécifiques et un corps JSON contenant des détails tels que le domaine de l’utilisateur, l’ID de locataire et la version du système d’exploitation. Le DS répond avec les URL du service d’inscription et les stratégies d’authentification nécessaires en fonction du type d’inscription (Microsoft Entra appareils joints ou inscrits).
• Inscription de configuration déclarée : la phase d’inscription utilise le protocole MS-MDE2 et les nouvelles stratégies CSP DMClient pour l’inscription double. Cette phase implique la définition et le LinkedEnrollment/DiscoveryEndpoint déclenchement de à l’aide LinkedEnrollment/Enroll des commandes SyncML. L’appareil peut ensuite gérer son état de configuration en interagissant avec le serveur OMA-DM via ces stratégies.

L’inscription WinDC offre les fonctionnalités de gestion d’état souhaitées :

• Accès aux ressources : fournit l’accès aux ressources nécessaires à la configuration.
• Extensibilité : permet d’étendre les fonctionnalités de configuration en fonction des besoins.

Une fois qu’un appareil est inscrit, le serveur OMA-DM peut envoyer une collection complète de noms de paramètres et de valeurs pour un scénario spécifié à l’aide du fournisseur de services de configuration DeclaredConfiguration. La pile WinDC sur l’appareil est chargée de gérer la demande de configuration et de maintenir son état, y compris les mises à jour du scénario.

L’avantage du modèle d’état souhaité WinDC est qu’il est efficace et précis, d’autant plus qu’il incombe à la pile cliente WinDC de configurer l’appareil. L’efficacité de WinDC est due au fait que le client peut traiter de manière asynchrone des lots de paramètres de scénario, ce qui libère les ressources du serveur pour effectuer d’autres tâches. Par conséquent, le protocole WinDC a une faible latence. En ce qui concerne la qualité et la précision de la configuration, la pile cliente WinDC possède une connaissance détaillée de la surface d’exposition de configuration de l’appareil. Ce comportement inclut la gestion appropriée des mises à jour continues des appareils qui affectent le scénario de configuration.

Plateformes prises en charge

L’inscription WinDC pour Microsoft Entra appareils joints est prise en charge pour toutes les versions de Windows 10/11.

L’inscription WinDC pour Microsoft Entra appareils inscrits est prise en charge pour Windows 10/11 avec les mises à jour suivantes :

• Windows 11, version 24H2 avec KB5040529 (build du système d’exploitation 26100.1301)
• Windows 11, version 23H2 avec KB5040527 (build du système d’exploitation 22631.3958)
• Windows 11, version 22H2 avec KB5040527 (build du système d’exploitation 22621.3958)
• Windows 10, version 22H2 avec KB5040525 (build du système d’exploitation 19045.4717)

Intervalle d’actualisation

La planification de l’actualisation WinDC est créée chaque fois qu’un document WinDC est présent sur l’appareil et qu’il n’existe actuellement aucune tâche de planification pour l’actualisation. La tâche s’exécute toutes les 4 heures par défaut et peut être configurée. Chaque fois que la tâche d’actualisation WinDC s’exécute, elle vérifie toutes les dérives de l’état souhaité en comparant la configuration système actuelle à l’intention du serveur dans les documents WinDC. S’il existe des dérives, le moteur WinDC tente de réappliquer les documents WinDC pour le corriger. Dans le cas où un document WinDC ne peut pas être réappliqué en raison d’instance données manquantes, le document WinDC est marqué dans un état dérivé et une nouvelle session de synchronisation est déclenchée pour signaler une dérive.

Pour identifier, ajuster ou supprimer la planification d’actualisation, utilisez l’URI RefreshInterval :

• Identifier la planification actuelle :

  <?xml version="1.0" encoding="utf-8"?>
  <SyncML xmlns="SYNCML:SYNCML1.1">
    <SyncBody>
      <Get>
        <CmdID>2</CmdID>
        <Item>
          <Target>
            <LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/ManagementServiceConfiguration/RefreshInterval</LocURI>
          </Target>
        </Item>
      </Get>
      <Final />
    </SyncBody>
  </SyncML>
  

• Ajuster la planification actuelle :

  <?xml version="1.0" encoding="utf-8"?>
  <SyncML xmlns="SYNCML:SYNCML1.1">
    <SyncBody>
      <Replace>
        <CmdID>2</CmdID>
        <Item>
          <Meta>
            <Format>int</Format>
            <Type>text/plain</Type>
          </Meta>
          <Target>
            <LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/ManagementServiceConfiguration/RefreshInterval</LocURI>
          </Target>
          <Data>30</Data>
        </Item>
      </Replace>
      <Final />
    </SyncBody>
  </SyncML>
  

• Supprimez la planification actuelle et utilisez la valeur par défaut du système :

  <?xml version="1.0" encoding="utf-8"?>
  <SyncML xmlns="SYNCML:SYNCML1.1">
    <SyncBody>
      <Delete>
        <CmdID>2</CmdID>
        <Item>
          <Target>
            <LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/ManagementServiceConfiguration/RefreshInterval</LocURI>
          </Target>
        </Item>
      </Delete>
      <Final />
    </SyncBody>
  </SyncML>
  

Résolution des problèmes

Si le traitement du document de configuration déclaré échoue, les erreurs sont consignées dans les journaux des événements Windows :

• Administration événements : Application and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin.
• Événements opérationnels : Application and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Operational.

Erreurs courantes

• Si utilise l’étendue de l’appareil, tandis que le <LocURI> document DeclaredConfiguration spécifie le contexte utilisateur, Administration journal des événements affiche un message d’erreur similaire à :

  MDM ConfigurationManager: Command failure status. Configuration Source ID: (DAD70CC2-365B-450D-A8AB-2EB23F4300CC), Enrollment Name: (MicrosoftManagementPlatformCloud), Provider Name: (DeclaredConfiguration), Command Type: (SetValue: from Replace), CSP URI: (./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/DCA000B5-397D-40A1-AABF-40B25078A7F9/Document), Result: (The system cannot find the file specified.)

• Si l’ID de document ne correspond pas à et à l’intérieur du <LocURI> document DeclaredConfiguration, Administration journal des événements affiche un message d’erreur semblable à celui-ci :

  MDM Declared Configuration: End document parsing from CSP: Document Id: (DCA000B5-397D-40A1-AABF-40B25078A7F91), Scenario: (MSFTVPN), Version: (A0), Enrollment Id: (DAD70CC2-365B-450D-A8AB-2EB23F4300CC), Current User: (S-1-5-21-3436249567-4017981746-3373817415-1001), Schema: (1.0), Download URL: (), Scope: (0x1), Enroll Type: (0x1A), File size: (0xDE2), CSP Count: (0x1), URI Count: (0xF), Action Requested: (0x0), Model: (0x1), Result:(0x8000FFFF) Catastrophic failure.

• Toute faute de frappe dans OMA-URI entraîne un échec. Dans cet exemple, TrafficFilterList est spécifié au lieu de TrafficFilterLists, et Administration journal des événements affiche un message d’erreur similaire à :

  MDM ConfigurationManager: Command failure status. Configuraton Source ID: (DAD70CC2-365B-450D-A8AB-2EB23F4300CC), Enrollment Type: (MicrosoftManagementPlatformCloud), CSP Name: (vpnv2), Command Type: (Add: from Replace or Add), CSP URI: (./user/vendor/msft/vpnv2/Test_SonicWall/TrafficFilterLists), Result: (Unknown Win32 Error code: 0x86000002).

  Il existe également un autre message d’avertissement dans le canal opérationnel :

  MDM Declared Configuration: Function (DeclaredConfigurationExtension_PolicyCSPConfigureGivenCurrentDoc) operation (ErrorAtDocLevel: one or more CSPs failed) failed with (Unknown Win32 Error code: 0x82d00007)