Freigeben über

Übersicht über das von Windows deklarierte Konfigurationsprotokoll

Das Windows-Protokoll für deklarierte Konfiguration (Windows Declared Configuration, WinDC) ist ein Gerätekonfigurationsmodell für den gewünschten Zustand, das für eine effiziente und zuverlässige Verwaltung von Windows-Geräten entwickelt wurde. Es verwendet das OMA-DM SyncML-Protokoll, um alle erforderlichen Einstellungen in einem einzelnen Batch über einen dedizierten OMA-DM-Server bereitzustellen. Der WinDC-Clientstapel auf dem Gerät verarbeitet diese Einstellungen, um den gewünschten Zustand auf die effizienteste und zuverlässigste Weise zu erreichen.

Das WinDC-Protokoll erfordert, dass ein Gerät über eine separate OMA-DM-Registrierung verfügt, die davon abhängig ist, dass das Gerät beim primären OMA-DM-Server registriert wird. Das Gewünschte Zustandsmodell ist ein anderes Modell als das aktuelle Modell, bei dem der Server für den Wunschzustand des Geräts verantwortlich ist. Diese duale Registrierung ist nur zulässig, wenn das Gerät bereits bei einem primären MDM-Server (Mobile Device Management) registriert ist. Diese andere Registrierung trennt die gewünschte Zustandsverwaltungsfunktion von der primären Funktionalität.

Die WinDC-Registrierung umfasst zwei Phasen:

  • Deklarierte Konfigurationsermittlung: In der ersten Ermittlungsphase des WinDC-Protokolls wird ein dediziertes JSON-Schema verwendet, um Registrierungsdetails vom Ermittlungsdienstendpunkt (DS) abzufragen. Diese Phase umfasst das Senden von HTTP-Anforderungen mit bestimmten Headern und einem JSON-Text, der Details wie Benutzerdomäne, Mandanten-ID und Betriebssystemversion enthält. Der DS antwortet mit den erforderlichen Registrierungsdienst-URLs und Authentifizierungsrichtlinien basierend auf dem Registrierungstyp (Microsoft Entra eingebundenen oder registrierten Geräten).
  • Deklarierte Konfigurationsregistrierung: In der Registrierungsphase werden das MS-MDE2-Protokoll und neue DMClient-CSP-Richtlinien für die duale Registrierung verwendet. Diese Phase umfasst das Festlegen von LinkedEnrollment/DiscoveryEndpoint und das Auslösen von mithilfe von LinkedEnrollment/Enroll SyncML-Befehlen. Das Gerät kann dann seinen Konfigurationsstatus verwalten, indem es über diese Richtlinien mit dem OMA-DM-Server interagiert.

Die WinDC-Registrierung bietet die folgenden Features für die Verwaltung des gewünschten Zustands:

  • Ressourcenzugriff: Bietet Zugriff auf erforderliche Ressourcen für die Konfiguration.
  • Erweiterbarkeit: Ermöglicht die Erweiterung der Konfigurationsfunktionen nach Bedarf.

Diagramm, das das WinDC-Modell veranschaulicht.

Nachdem ein Gerät registriert wurde, kann der OMA-DM-Server mithilfe des DeclaredConfiguration-CSP eine vollständige Sammlung von Einstellungsnamen und -werten für ein bestimmtes Szenario senden. Der WinDC-Stapel auf dem Gerät ist für die Verarbeitung der Konfigurationsanforderung und die Aufrechterhaltung des Zustands einschließlich Updates des Szenarios verantwortlich.

Der Vorteil des WinDC-Modell für den gewünschten Zustand besteht darin, dass es effizient und genau ist, insbesondere da es in der Verantwortung des WinDC-Clientstapels liegt, das Gerät zu konfigurieren. Die Effizienz von WinDC liegt darin, dass der Client Batches von Szenarioeinstellungen asynchron verarbeiten kann, wodurch die Serverressourcen für andere Aufgaben freigegeben werden. Daher weist das WinDC-Protokoll eine geringe Latenz auf. Was die Konfigurationsqualität und -genauigkeit betrifft, verfügt der WinDC-Clientstapel über detaillierte Kenntnisse der Konfigurationsoberfläche des Geräts. Dieses Verhalten umfasst die ordnungsgemäße Behandlung kontinuierlicher Geräteupdates, die sich auf das Konfigurationsszenario auswirken.

Unterstützte Plattformen

Die WinDC-Registrierung für Microsoft Entra verbundene Geräte wird für alle Versionen von Windows 10/11 unterstützt.

Die WinDC-Registrierung für Microsoft Entra registrierte Geräte wird für Windows 10/11 mit den folgenden Updates unterstützt:

  • Windows 11, Version 24H2 mit KB5040529 (BS-Build 26100.1301)
  • Windows 11, Version 23H2 mit KB5040527 (BS-Build 22631.3958)
  • Windows 11, Version 22H2 mit KB5040527 (BS-Build 22621.3958)
  • Windows 10, Version 22H2 mit KB5040525 (BS-Build 19045.4717)

Aktualisierungsintervall

Der WinDC-Aktualisierungszeitplan wird immer dann erstellt, wenn auf dem Gerät ein WinDC-Dokument vorhanden ist und derzeit kein Zeitplan für die Aktualisierung vorhanden ist. Der Task wird standardmäßig alle 4 Stunden ausgeführt und kann konfiguriert werden. Jedes Mal, wenn der WinDC-Aktualisierungstask ausgeführt wird, überprüft er alle Abweichungen vom gewünschten Zustand, indem die aktuelle Systemkonfiguration mit der Serverabsicht in den WinDC-Dokumenten verglichen wird. Wenn Abweichungen auftreten, versucht die WinDC-Engine, die WinDC-Dokumente erneut anzuordnen, um sie zu beheben. Falls ein WinDC-Dokument nicht erneut angewendet werden kann, weil instance Daten fehlen, wird das WinDC-Dokument im abweichenden Zustand markiert, und eine neue Synchronisierungssitzung wird ausgelöst, um eine Abweichung zu benachrichtigen.

Verwenden Sie den RefreshInterval-URI , um den Aktualisierungszeitplan zu identifizieren, anzupassen oder zu entfernen:

  • Identifizieren des aktuellen Zeitplans:

    <?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>

  • Passen Sie den aktuellen Zeitplan an:

    <?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>

  • Löschen Sie den aktuellen Zeitplan, und verwenden Sie den Systemstandard:

    <?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>

Problembehandlung

Wenn die Verarbeitung des deklarierten Konfigurationsdokuments fehlschlägt, werden die Fehler in Windows-Ereignisprotokollen protokolliert:

  • Admin Ereignisse: Application and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin.
  • Betriebsereignisse: Application and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Operational.

Häufige Fehler

  • Wenn der Den Gerätebereich verwendet, während das <LocURI> Dokument DeclaredConfiguration den Benutzerkontext angibt, zeigt Admin Ereignisprotokoll eine Fehlermeldung ähnlich der folgenden an:

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

  • Wenn die Dokument-ID nicht mit und innerhalb des <LocURI> DeclaredConfiguration-Dokuments übereinstimmt, wird Admin Ereignisprotokoll eine Fehlermeldung ähnlich der folgenden angezeigt:

    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-1004336348-1177238915-682003330-1234), 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.

  • Jeder Tippfehler im OMA-URI führt zu einem Fehler. In diesem Beispiel wird anstelle von TrafficFilterListsangegeben, TrafficFilterList und Admin Ereignisprotokoll zeigt eine Fehlermeldung ähnlich der folgenden an:

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

    Es gibt auch eine weitere Warnmeldung im Betriebskanal:

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