Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
4/8/2010

The following diagram illustrates the architecture for device management through over-the-air (OTA) device configuration using the OMA Device Management protocol.

In the following scenario, the Windows Mobile device has already bootstrapped with access data to the DM server.

Note:
Microsoft does not provide an OMA DM server. The OEM, mobile operator, or a third party must create their own server. For information about server requirements, see Server Requirements for OMA Device Management.

The mobile operator wants to configure the device OTA such that the device can synchronize emails, contacts, and calendar with Sync Server.

With OMA, communication occurs over an HTTPS channel.

The numbers in the picture correspond to the following steps:

  1. Using a WAP push, the mobile operator sends a DM notification to the device.

  2. The device receives this message through Short Message Service (SMS). The message is finally routed to the Push Router.

  3. The push router authenticates the message, and then sends the message to the OMA DM transport client to initiate a DM session.

  4. The DM transport client sets up the secure transport channel with the server, sends the package to the server.

  5. The server parse the package to identify the device type, creates the configuration data, packages in DM message, and sends it back to the device

  6. The DM client receives the message, parses the SyncHdrelement, and passes the SyncBodyelement to OMA DM data process unit (DPU).

  7. The OMA DM DPU parses incoming SyncBody OMA DM XML, sends the DM request to the Configuration Manager2, and then creates a response SyncBody based on the result it receives from Configuration Manager2.

  8. Configuration Manager2 checks the access permit to find whether that action is permitted for designated objects by that particular server, and identifies which configuration service provider should be called.

  9. Configuration Manager2 routes the command to specific configuration service provider. The configuration service provider processes the command and sends processing result back to the Configuration Manager2.

  10. The Configuration Manager2 sends the result back to the data process unit (DPU). The DPU then parses the result and creates the corresponding status OMA DM element.

  11. After all commands are processed, the DPU sends the response back to OMA DM transport client.

  12. The OMA DM transport client then creates the response OMA message and sends back to the server.

  13. The server parses the package. When it finds that everything is configured correctly, it sends the last DM message to the device to close this session.

See Also