From 4f66822a2f59db87b26aee9de0de419c618d4dc2 Mon Sep 17 00:00:00 2001 From: Shesh <56231259+sheshachary@users.noreply.github.com> Date: Tue, 1 Feb 2022 18:53:33 +0530 Subject: [PATCH] updated the changes --- .../client-management/mdm/oma-dm-protocol-support.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/windows/client-management/mdm/oma-dm-protocol-support.md b/windows/client-management/mdm/oma-dm-protocol-support.md index 1fdbc0a4dd..5195faa1a4 100644 --- a/windows/client-management/mdm/oma-dm-protocol-support.md +++ b/windows/client-management/mdm/oma-dm-protocol-support.md @@ -25,11 +25,11 @@ The following table shows the OMA DM standards that Windows uses. |--- |--- | |Data transport and session|
  • Client-initiated remote HTTPS DM session over SSL.
  • Remote HTTPS DM session over SSL.
  • Remote DM server initiation notification using WAP Push over Short Message Service (SMS). Not used by enterprise management.
  • Remote bootstrap by using WAP Push over SMS. Not used by enterprise management.| |Bootstrap XML|OMA Client Provisioning XML.| -|DM protocol commands|The following list shows the commands that are used by the device. For more information about the OMA DM command elements, see "[OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/)" available from the OMA website.
  • Add (Implicit Add supported)
  • Alert (DM alert): Generic alert (1226) is used by enterprise management client when the user triggers an MDM unenrollment action from the device or when a CSP finishes some asynchronous actions. Device alert (1224) is used to notify the server some device triggered event.
  • Atomic: Performing an Add command followed by Replace on the same node within an atomic element is not supported. Nested Atomic and Get commands are not allowed and will generate error code 500.
  • Delete: Removes a node from the DM tree, and the entire subtree beneath that node if one exists
  • Exec: Invokes an executable on the client device
  • Get: Retrieves data from the client device; for interior nodes, the child node names in the Data element are returned in URI-encoded format
  • Replace: Overwrites data on the client device
  • Result: Returns the data results of a Get command to the DM server
  • Sequence: Specifies the order in which a group of commands must be processed
  • Status: Indicates the completion status (success or failure) of an operation

    If an XML element that is not a valid OMA DM command is under one of the following elements, the status code 400 is returned for that element:
  • SyncBody
  • Atomic
  • Sequence

    If no CmdID is provided in the DM command, the client returns blank in the status element and the status code 400.

    If Atomic elements are nested, the following status codes are returned:
  • The nested Atomic command returns 500.
  • The parent Atomic command returns 507.

    For more information about the Atomic command, see OMA DM protocol common elements.
    Performing an Add command followed by Replace on the same node within an Atomic element is not supported.

    LocURI cannot start with `/`.

    Meta XML tag in SyncHdr is ignored by the device.| +|DM protocol commands|The following list shows the commands that are used by the device. For more information about the OMA DM command elements, see "[OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/)" available from the OMA website.
  • Add (Implicit Add supported)
  • Alert (DM alert): Generic alert (1226) is used by enterprise management client when the user triggers an MDM unenrollment action from the device or when a CSP finishes some asynchronous actions. Device alert (1224) is used to notify the server some device triggered event.
  • Atomic: Performing an Add command followed by Replace on the same node within an atomic element isn't supported. Nested Atomic and Get commands aren't allowed and will generate error code 500.
  • Delete: Removes a node from the DM tree, and the entire subtree beneath that node if one exists
  • Exec: Invokes an executable on the client device
  • Get: Retrieves data from the client device; for interior nodes, the child node names in the Data element are returned in URI-encoded format
  • Replace: Overwrites data on the client device
  • Result: Returns the data results of a Get command to the DM server
  • Sequence: Specifies the order in which a group of commands must be processed
  • Status: Indicates the completion status (success or failure) of an operation

    If an XML element that isn't a valid OMA DM command is under one of the following elements, the status code 400 is returned for that element:
  • SyncBody
  • Atomic
  • Sequence

    If no CmdID is provided in the DM command, the client returns blank in the status element and the status code 400.

    If Atomic elements are nested, the following status codes are returned:
  • The nested Atomic command returns 500.
  • The parent Atomic command returns 507.

    For more information about the Atomic command, see OMA DM protocol common elements.
    Performing an Add command followed by Replace on the same node within an Atomic element isn't supported.

    LocURI can't start with `/`.

    Meta XML tag in SyncHdr is ignored by the device.| |OMA DM standard objects|DevInfo
  • DevDetail
  • OMA DM DMS account objects (OMA DM version 1.2)| |Security|
  • Authenticate DM server initiation notification SMS message (not used by enterprise management)
  • Application layer Basic and MD5 client authentication
  • Authenticate server with MD5 credential at application level
  • Data integrity and authentication with HMAC at application level
  • SSL level certificate-based client/server authentication, encryption, and data integrity check| |Nodes|In the OMA DM tree, the following rules apply for the node name:
  • "." can be part of the node name.
  • The node name cannot be empty.
  • The node name cannot be only the asterisk (*) character.| -|Provisioning Files|Provisioning XML must be well formed and follow the definition in [SyncML Representation Protocol](https://www.openmobilealliance.org/release/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf).

    If an XML element that is not a valid OMA DM command is under SyncBody, the status code 400 is returned for that element.
    **Note**
    To represent a Unicode string as a URI, first encode the string as UTF-8. Then encode each of the UTF-8 bytes using URI encoding.
    | +|Provisioning Files|Provisioning XML must be well formed and follow the definition in [SyncML Representation Protocol](https://www.openmobilealliance.org/release/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf).

    If an XML element that isn't a valid OMA DM command is under SyncBody, the status code 400 is returned for that element.
    **Note**
    To represent a Unicode string as a URI, first encode the string as UTF-8. Then encode each of the UTF-8 bytes using URI encoding.
    | |WBXML support|Windows supports sending and receiving SyncML in both XML format and encoded WBXML format. This is configurable by using the DEFAULTENCODING node under the w7 APPLICATION characteristic during enrollment. For more information about WBXML encoding, see section 8 of the [SyncML Representation Protocol](https://www.openmobilealliance.org/release/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf) specification.| |Handling of large objects|In Windows 10, version 1511, client support for uploading large objects to the server was added.| @@ -52,7 +52,7 @@ Common elements are used by other OMA DM element types. The following table list |MsgID|Specifies a unique identifier for an OMA DM session message.| |MsgRef|Specifies the ID of the corresponding request message. This element takes the value of the request message MsgID element.| |RespURI|Specifies the URI that the recipient must use when sending a response to this message.| -|SessionID|Specifies the identifier of the OMA DM session associated with the containing message.
    **Note**
    If the server does not notify the device that it supports a new version (through SyncApplicationVersion node in the DMClient CSP), the client returns the SessionID in integer in decimal format. If the server supports DM session sync version 2.0, which is used in Windows 10, the device client returns 2 bytes.
    | +|SessionID|Specifies the identifier of the OMA DM session associated with the containing message.
    **Note**
    If the server doesn't notify the device that it supports a new version (through SyncApplicationVersion node in the DMClient CSP), the client returns the SessionID in integer in decimal format. If the server supports DM session sync version 2.0, which is used in Windows 10, the device client returns 2 bytes.
    | |Source|Specifies the message source address.| |SourceRef|Specifies the source of the corresponding request message. This element takes the value of the request message Source element and is returned in the Status or Results element.| |Target|Specifies the address of the node, in the DM Tree, that is the target of the OMA DM command.| @@ -125,7 +125,7 @@ Below is an alert example: ``` -The server notifies the device whether it is a user targeted or device targeted configuration by a prefix to the management node’s LocURL, with ./user for user targeted configuration, or ./device for device targeted configuration. By default, if no prefix with ./device or ./user, it is device targeted configuration. +The server notifies the device whether it's a user targeted or device targeted configuration by a prefix to the management node’s LocURL, with ./user for user targeted configuration, or ./device for device targeted configuration. By default, if no prefix with ./device or ./user, it's device targeted configuration. The following LocURL shows a per user CSP node configuration: **./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall** @@ -135,7 +135,7 @@ The following LocURL shows a per device CSP node configuration: **./device/vendo ## SyncML response status codes -When using SyncML in OMA DM, there are standard response status codes that are returned. The following table lists the common SyncML response status codes you are likely to see. For more information about SyncML response status codes, see section 10 of the [SyncML Representation Protocol](https://openmobilealliance.org/release/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf) specification. +When using SyncML in OMA DM, there are standard response status codes that are returned. The following table lists the common SyncML response status codes you're likely to see. For more information about SyncML response status codes, see section 10 of the [SyncML Representation Protocol](https://openmobilealliance.org/release/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf) specification. | Status code | Description | |---|----|