Freigeben über

OMA-DM-Protokollunterstützung

Der OMA DM-Client kommuniziert mit dem Server über HTTPS und verwendet DM Sync (OMA DM v1.2) als Nachrichtennutzlast. In diesem Artikel wird die OMA DM-Funktionalität beschrieben, die der DM-Client im Allgemeinen unterstützt. Die vollständige Beschreibung des OMA DM-Protokolls v1.2 finden Sie auf der OMA-Website.

OMA DM-Standards

In der folgenden Tabelle sind die OMA DM-Standards aufgeführt, die von Windows verwendet werden.

Allgemeiner Bereich Unterstützter OMA DM-Standard
Datentransport und Sitzung
  • Vom Client initiierte HTTPS-Dm-Remotesitzung über TLS/SSL.
  • Remote-HTTPS-DM-Sitzung über TLS/SSL.
  • Initiierungsbenachrichtigung für remote dm server using WAP Push over Short Message Service (SMS). Wird nicht von der Unternehmensverwaltung verwendet.
  • Remote-Bootstrap mithilfe von WAP-Push über SMS. Wird nicht von der Unternehmensverwaltung verwendet.
    		•
    Bootstrap-XML OMA-Clientbereitstellungs-XML.
    DM-Protokollbefehle Die folgende Liste zeigt die Befehle, die vom Gerät verwendet werden. Weitere Informationen zu den OMA DM-Befehlselementen finden Sie auf der OMA-Website unter "OMA-Website".
  • Hinzufügen (implizites Hinzufügen unterstützt)
  • Warnung (DM-Warnung): Die generische Warnung (1226) wird vom Unternehmensverwaltungsclient verwendet, wenn der Benutzer eine MDM-Aufhebungsaktion auf dem Gerät auslöst oder wenn ein CSP einige asynchrone Aktionen beendet. Die Gerätewarnung (1224) wird verwendet, um den Server über ein vom Gerät ausgelöstes Ereignis zu benachrichtigen.
  • Atomic: Das Ausführen eines Add-Befehls gefolgt von "Ersetzen" auf demselben Knoten innerhalb eines atomaren Elements wird nicht unterstützt. Geschachtelte Atomic- und Get-Befehle sind nicht zulässig und generieren den Fehlercode 500.
  • Löschen: Entfernt einen Knoten aus der DM-Struktur und die gesamte Unterstruktur unter diesem Knoten, sofern vorhanden.
  • Exec: Ruft eine ausführbare Datei auf dem Clientgerät auf.
  • Abrufen: Ruft Daten vom Clientgerät ab. Bei inneren Knoten werden die Namen der untergeordneten Knoten im Data-Element im URI-codierten Format zurückgegeben.
  • Ersetzen: Überschreibt Daten auf dem Clientgerät
  • Ergebnis: Gibt die Datenergebnisse eines Get-Befehls an den DM-Server zurück.
  • Sequenz: Gibt die Reihenfolge an, in der eine Gruppe von Befehlen verarbeitet werden muss.
  • Status: Gibt den Abschluss status (Erfolg oder Fehler) eines Vorgangs an.

    Wenn sich ein XML-Element, das kein gültiger OMA DM-Befehl ist, unter einem der folgenden Elemente befindet, wird der status Code 400 für dieses Element zurückgegeben:
  • SyncBody
  • Atomic
  • Sequenz

    Wenn im DM-Befehl keine CmdID angegeben wird, gibt der Client leer im status-Element und den status Code 400 zurück.

    Wenn Atomic-Elemente geschachtelt sind, werden die folgenden status Codes zurückgegeben:
  • Der geschachtelte Atomic-Befehl gibt 500 zurück.
  • Der übergeordnete Atomic-Befehl gibt 507 zurück.

    Weitere Informationen zum Atomic-Befehl finden Sie unter Allgemeine Elemente des OMA DM-Protokolls.
    Das Ausführen eines Add-Befehls gefolgt von Replace auf demselben Knoten innerhalb eines Atomic-Elements wird nicht unterstützt.

    LocURI kann nicht mit /beginnen.

    Das Meta-XML-Tag in SyncHdr wird vom Gerät ignoriert.
    		•
    OMA DM-Standardobjekte DevInfo
  • DevDetail
  • OMA DM DMS-Kontoobjekte (OMA DM Version 1.2)
    		•
    Sicherheit
  • Benachrichtigung über die Dmd-Serverinitiierung per SMS authentifizieren (von der Unternehmensverwaltung nicht verwendet)
  • Standard- und MD5-Clientauthentifizierung auf Anwendungsschicht
  • Authentifizieren eines Servers mit MD5-Anmeldeinformationen auf Anwendungsebene
  • Datenintegrität und Authentifizierung mit HMAC auf Anwendungsebene
  • Zertifikatbasierte Client-/Serverauthentifizierung, Verschlüsselung und Datenintegritätsprüfung auf TLS-/SSL-Ebene
    		•
    Knoten In der OMA DM-Struktur gelten die folgenden Regeln für den Knotennamen:
  • "." kann Teil des Knotennamens sein.
  • Der Knotenname darf nicht leer sein.
  • Der Knotenname darf nicht nur das Sternchen (*) sein.
    		•
    Bereitstellen von Dateien Die XML-Bereitstellung muss wohlgeformt sein und der Definition im SyncML Representation Protocol folgen.

    Wenn sich unter SyncBody ein XML-Element befindet, das kein gültiger OMA DM-Befehl ist, wird der status Code 400 für dieses Element zurückgegeben.
    Hinweis
    Um eine Unicode-Zeichenfolge als URI darzustellen, codieren Sie die Zeichenfolge zuerst als UTF-8. Codieren Sie dann alle UTF-8-Bytes mithilfe der URI-Codierung.
    WBXML-Unterstützung Windows unterstützt das Senden und Empfangen von SyncML sowohl im XML-Format als auch im codierten WBXML-Format. Diese Unterstützung im dualen Format kann während der Registrierung mithilfe des Knotens DEFAULTENCODING unter dem w7 APPLICATION-Merkmal konfiguriert werden. Weitere Informationen zur WBXML-Codierung finden Sie in Abschnitt 8 der SyncML Representation Protocol-Spezifikation .
    Behandlung großer Objekte In Windows 10 wurde die Clientunterstützung für das Hochladen großer Objekte auf den Server hinzugefügt.

    Allgemeine Elemente des OMA DM-Protokolls

    Allgemeine Elemente werden von anderen OMA DM-Elementtypen verwendet. In der folgenden Tabelle sind die allgemeinen OMA DM-Elemente aufgeführt, die zum Konfigurieren der Geräte verwendet werden. Weitere Informationen zu allgemeinen OMA DM-Elementen finden Sie auf der OMA-Website unter "SyncML Representation Protocol Geräteverwaltung Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A).

    Element Beschreibung
    Chal Gibt eine Authentifizierungsanforderung an. Der Server oder Client kann eine Abfrage an den anderen senden, wenn in der ursprünglichen Anforderungsnachricht keine Anmeldeinformationen oder unzureichende Anmeldeinformationen angegeben wurden.
    Cmd Gibt den Namen eines OMA DM-Befehls an, auf den in einem Status-Element verwiesen wird.
    CmdID Gibt den eindeutigen Bezeichner für einen OMA DM-Befehl an.
    CmdRef Gibt die ID des Befehls an, für den status- oder Ergebnisinformationen zurückgegeben werden. Dieses Element nimmt den Wert des CmdID-Elements der entsprechenden Anforderungsnachricht an.
    Cred Gibt die Anmeldeinformationen für die Authentifizierung für den Absender der Nachricht an.
    Finale Gibt an, dass die aktuelle Nachricht die letzte Nachricht im Paket ist.
    LocName Gibt den Anzeigenamen in den Elementen Target und Source an, die zum Senden einer Benutzer-ID für die MD5-Authentifizierung verwendet werden.
    „LocURI“ Gibt die Adresse des Ziel- oder Quellspeicherorts an. Wenn die Adresse ein nicht alphanumerisches Zeichen enthält, muss sie gemäß dem URL-Codierungsstandard ordnungsgemäß mit Escapezeichen versehen werden.
    Msgid Gibt einen eindeutigen Bezeichner für eine OMA DM-Sitzungsnachricht an.
    MsgRef Gibt die ID der entsprechenden Anforderungsnachricht an. Dieses Element nimmt den Wert des MsgID-Elements der Anforderungsmeldung an.
    RespURI Gibt den URI an, den der Empfänger beim Senden einer Antwort auf diese Nachricht verwenden muss.
    Sessionid Gibt den Bezeichner der OMA DM-Sitzung an, die der enthaltenden Nachricht zugeordnet ist. Wenn der Server das Gerät nicht darüber benachrichtigt, dass eine neue Version unterstützt wird (über den SyncApplicationVersion-Knoten im DMClient-CSP), gibt der Client die SessionID als ganze Zahl im Dezimalformat zurück. Wenn der Server version 2.0 der DM-Sitzungssynchronisierung unterstützt, die in Windows verwendet wird, gibt der Geräteclient 2 Bytes zurück.
    Source Gibt die Nachrichtenquelladresse an.
    SourceRef Gibt die Quelle der entsprechenden Anforderungsnachricht an. Dieses Element nimmt den Wert des Source-Elements der Anforderungsmeldung an und wird im Status- oder Results-Element zurückgegeben.
    Ziel Gibt die Adresse des Knotens in der DM-Struktur an, der das Ziel des OMA DM-Befehls ist.
    TargetRef Gibt die Zieladresse in der entsprechenden Anforderungsnachricht an. Dieses Element nimmt den Wert des Target-Elements der Anforderungsmeldung an und wird im Status- oder Results-Element zurückgegeben.
    VerDTD Gibt den Haupt- und Nebenversionsbezeichner der OMA DM-Protokollspezifikation an, die zur Darstellung der Nachricht verwendet wird.
    VerProto Gibt den Haupt- und Nebenversionsbezeichner der OMA DM-Protokollspezifikation an, die mit der Nachricht verwendet wird.

    Geräteverwaltungssitzung

    Eine Geräteverwaltung(DM)-Sitzung besteht aus einer Reihe von Befehlen, die zwischen einem DM-Server und einem Clientgerät ausgetauscht werden. Der Server sendet Befehle, die Vorgänge angeben, die in der Verwaltungsstruktur des Clientgeräts ausgeführt werden müssen. Der Client antwortet, indem er Befehle sendet, die die Ergebnisse und alle angeforderten status Informationen enthalten.

    Eine kurze DM-Sitzung kann wie folgt zusammengefasst werden:

    Ein Server sendet einen Get-Befehl an ein Clientgerät, um den Inhalt eines der Knoten der Verwaltungsstruktur abzurufen. Das Gerät führt den Vorgang aus und antwortet mit einem Result-Befehl, der den angeforderten Inhalt enthält.

    Eine DM-Sitzung kann in zwei Phasen unterteilt werden:

    1. Setupphase: Als Reaktion auf ein Triggerereignis sendet ein Clientgerät eine initiierende Nachricht an einen DM-Server. Das Gerät und der Server benötigten Authentifizierungs- und Geräteinformationen. Diese Phase wird durch die Schritte 1, 2 und 3 dargestellt.
    2. Verwaltungsphase: Der DM-Server hat die Kontrolle. Es sendet Verwaltungsbefehle an das Gerät, und das Gerät reagiert. Phase 2 endet, wenn der DM-Server keine Befehle mehr sendet und die Sitzung beendet. Diese Phase wird durch die Schritte 3, 4 und 5 dargestellt.

    Die folgenden Informationen zeigen die Abfolge der Ereignisse während einer typischen DM-Sitzung.

    1. Der DM-Client wird aufgerufen, um den Verwaltungsserver zurückzurufen.

      Unternehmensszenario: Der Gerätetaskzeitplan ruft den DM-Client auf.

      Der MO-Server sendet eine Servertriggermeldung, um den DM-Client aufzurufen.

      Die Triggermeldung enthält die Server-ID und weist das Clientgerät an, eine Sitzung mit dem Server zu initiieren. Das Clientgerät authentifiziert die Triggernachricht und überprüft, ob der Server für die Kommunikation autorisiert ist.

      Unternehmensszenario: Zum geplanten Zeitpunkt wird der DM-Client in regelmäßigen Abständen aufgerufen, um den Unternehmensverwaltungsserver über HTTPS zurückzurufen.

    2. Das Gerät sendet eine Nachricht über eine IP-Verbindung, um die Sitzung zu initiieren.

      Diese Meldung enthält Geräteinformationen und Anmeldeinformationen. Client und Server führen die gegenseitige Authentifizierung über einen TLS/SSL-Kanal oder auf DM-Anwendungsebene durch.

    3. Der DM-Server antwortet über eine IP-Verbindung (HTTPS). Der Server sendet ggf. anfängliche Geräteverwaltungsbefehle.

    4. Das Gerät reagiert auf Serververwaltungsbefehle. Diese Meldung enthält die Ergebnisse der Ausführung der angegebenen Geräteverwaltungsvorgänge.

    5. Der DM-Server beendet die Sitzung oder sendet einen anderen Befehl. Die DM-Sitzung wird beendet, oder Schritt 4 wird wiederholt.

    Die Schrittnummern stellen keine Nachrichtenidentifikationsnummern (MsgID) dar. Alle Nachrichten vom Server müssen eine MsgID aufweisen, die innerhalb der Sitzung eindeutig ist, beginnend bei 1 für die erste Nachricht und für jede zusätzliche Nachricht um ein Inkrement von 1 erhöht wird. Weitere Informationen zu MsgID und dem OMA SyncML-Protokoll finden Sie unter OMA Geräteverwaltung Representation Protocol (DM_RepPro-V1_2-20070209-A).

    Wenn während der gegenseitigen Authentifizierung auf OMA DM-Anwendungsebene der Geräteantwortcode für das Cred-Element in der Serveranforderung 212 ist, ist für den Rest der DM-Sitzung keine weitere Authentifizierung erforderlich. Wenn die MD5-Authentifizierung erfolgt, kann das Chal -Element zurückgegeben werden. Dann muss die nächste Nonce in Chal für den MD5-Digest verwendet werden, wenn die nächste DM-Sitzung gestartet wird.

    Wenn eine Anforderung Anmeldeinformationen enthält und der Antwortcode für die Anforderung 200 ist, müssen die gleichen Anmeldeinformationen innerhalb der nächsten Anforderung gesendet werden. Wenn das Chal Element enthalten ist und die MD5-Authentifizierung erforderlich ist, wird ein neuer Digest erstellt, indem die nächste Nonce über das -Element für die Chal nächste Anforderung verwendet wird.

    Weitere Informationen zur Standard- oder MD5-Clientauthentifizierung: MD5-Serverauthentifizierung, MD5-Hash und MD5-Nonce, siehe OMA-Geräteverwaltung-Sicherheitsspezifikation (OMA-TS-DM_Security-V1_2_1-20080617-A), Authentifizierungsantwortcodebehandlung und Schrittweise Beispiele in der OMA Geräteverwaltung Protocol-Spezifikation (OMA-TS-DM_Protocol-V1_2_1-20080617-A), verfügbar auf der OMA-Website.

    Benutzerorientierte und geräteorientierte Konfiguration

    Für CSPs und Richtlinien, die die Konfiguration pro Benutzer unterstützen, kann der MDM-Server benutzerspezifische Einstellungswerte an das Gerät senden, bei dem ein MDM-registrierter Benutzer aktiv angemeldet ist. Das Gerät benachrichtigt den Server über die Anmelde-status über eine Gerätewarnung (1224) mit dem Warnungstyp = in DM pkg#1.

    Der Datenteil dieser Warnung kann eine der folgenden Zeichenfolgen sein:

    • Benutzer: Der Benutzer, der das Gerät registriert hat, ist aktiv angemeldet. Der MDM-Server kann eine benutzerspezifische Konfiguration für CSPs/Richtlinien senden, die die Konfiguration pro Benutzer unterstützen.
    • Andere: Ein anderer Benutzer kann sich anmelden, aber dieser Benutzer verfügt nicht über ein MDM-Konto. Der Server kann nur eine geräteweite Konfiguration anwenden, z. B. gilt die Konfiguration für alle Benutzer auf dem Gerät.
    • Keine: Es wird kein aktiver Benutzer angemeldet. Der Server kann nur eine geräteweite Konfiguration anwenden, und die verfügbare Konfiguration ist auf die Geräteumgebung beschränkt (keine aktive Benutzeranmeldung).

    Hier sehen Sie ein Warnungsbeispiel:

    <Alert>
    <CmdID>1</CmdID>
    <Data>1224</Data>
    <Item>
        <Meta>
            <Type xmlns="syncml:metinf">com.microsoft/MDM/LoginStatus</Type>
            <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Data>user</Data>
    </Item>
</Alert>

    Der Server benachrichtigt das Gerät, ob es sich um eine benutzer- oder geräteorientierte Konfiguration handelt, durch ein Präfix für die LocURL des Verwaltungsknotens, mit ./user für die benutzerorientierte Konfiguration oder ./device für die geräteorientierte Konfiguration. Wenn kein Präfix mit ./device oder vorhanden ./userist, handelt es sich standardmäßig um eine geräteorientierte Konfiguration.

    Die folgende LocURL zeigt eine CSP-Knotenkonfiguration pro Benutzer an: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

    Die folgende LocURL zeigt eine CSP-Knotenkonfiguration pro Gerät an: ./device/vendor/MSFT/RemoteWipe/DoWipe

    SyncML-Antwortcode status

    Wenn Sie SyncML in OMA DM verwenden, gibt es Standardantworten status Codes, die zurückgegeben werden. In der folgenden Tabelle sind die allgemeinen SyncML-Antworten status Codes aufgeführt, die Ihnen wahrscheinlich angezeigt werden. Weitere Informationen zu SyncML-Antwortcodes status finden Sie in Abschnitt 10 der Spezifikation des SyncML Representation Protocol.

    Statuscode Beschreibung
    200 Der SyncML-Befehl wurde erfolgreich abgeschlossen.
    202 Zur Verarbeitung akzeptiert. Dieser Code kennzeichnet einen asynchronen Vorgang, z. B. eine Anforderung zum Ausführen einer Remoteausführung einer Anwendung.
    212 Authentifizierung akzeptiert. Normalerweise wird dieser Code nur als Reaktion auf das SyncHdr-Element angezeigt (das für die Authentifizierung im OMA-DM-Standard verwendet wird). Dieser Code wird möglicherweise angezeigt, wenn Sie sich OMA DM-Protokolle ansehen, aber CSPs generieren diesen Code in der Regel nicht.
    214 Vorgang abgebrochen. Der SyncML-Befehl wurde erfolgreich abgeschlossen, aber innerhalb der Sitzung werden keine weiteren Befehle verarbeitet.
    215 Nicht ausgeführt. Aufgrund einer Benutzerinteraktion zum Abbrechen des Befehls wurde kein Befehl ausgeführt.
    216 Atomic Rollback OK. Ein Befehl befand sich in einem Atomic -Element und Atomic war fehlgeschlagen. Für diesen Befehl wurde ein Rollback erfolgreich ausgeführt.
    400 Ungültige Anforderung. Der angeforderte Befehl konnte aufgrund einer falsch formatierten Syntax nicht ausgeführt werden. CSPs generieren diesen Fehler in der Regel nicht, sie können jedoch angezeigt werden, wenn SyncML falsch formatiert ist.
    401 Ungültige Anmeldeinformationen. Fehler beim angeforderten Befehl, da der Anforderer eine ordnungsgemäße Authentifizierung bereitstellen muss. CSPs generieren diesen Fehler in der Regel nicht.
    403 Verboten. Der angeforderte Befehl ist fehlgeschlagen, aber der Empfänger hat den angeforderten Befehl verstanden.
    404 Nicht gefunden. Das angeforderte Ziel wurde nicht gefunden. Dieser Code wird generiert, wenn Sie einen Knoten abfragen, der nicht vorhanden ist.
    405 Der Befehl ist nicht zulässig. Dieser Antwortcode wird generiert, wenn Sie versuchen, auf einen schreibgeschützten Knoten zu schreiben.
    406 Optionale Funktion wird nicht unterstützt. Dieser Antwortcode wird generiert, wenn Sie versuchen, auf eine Eigenschaft zuzugreifen, die vom CSP nicht unterstützt wird.
    415 Nicht unterstützter Typ oder Format. Dieser Antwortcode kann aus XML-Analyse- oder Formatierungsfehlern resultieren.
    418 Ist bereits vorhanden. Dieser Antwortcode tritt auf, wenn Sie versuchen, einen bereits vorhandenen Knoten hinzuzufügen.
    425 Berechtigung verweigert. Der angeforderte Befehl ist fehlgeschlagen, weil der Absender nicht über ausreichende Zugriffssteuerungsberechtigungen (ACL) für den Empfänger verfügt. Fehler vom Typ "Zugriff verweigert" werden in der Regel in diesen Antwortcode übersetzt.
    500 Fehler beim Befehl. Generischer Fehler. Beim Empfänger ist eine unerwartete Bedingung aufgetreten, die die Erfüllung der Anforderung verhinderte. Dieser Antwortcode tritt auf, wenn die SyncML-DPU den ursprünglichen Fehlercode nicht zuordnen kann.
    507 Atomic Fehlgeschlagen. Bei einem der Vorgänge in einem Atomic -Block ist ein Fehler aufgetreten.
    516 Atomic Ein Rollback ist fehlgeschlagen. Ein Atomic Vorgang ist fehlgeschlagen, und für den Befehl wurde kein Rollback erfolgreich ausgeführt.

    Referenz zum Konfigurationsdienstanbieter