Share via


Device Management Architecture

Send Feedback

You can manage a device by provisioning it. Provisioning a device involves creating a provisioning XML file that contains configuration information, and then sending the file to the device, Configuration Manager and Configuration Service Providers configure the device based on the contents of the provisioning XML file.

There are a number of options for delivering provisioning files to Windows Mobile-based devices. The following table shows various delivery methods.

Delivery Method Description
Send over the air (OTA) A device can be provisioned OTA by either a one-time push, or by using a two-way communication between server and client called continuous provisioning. Windows Mobile Version 5.0 uses Open Mobile Alliance (OMA) device management standards for OTA provisioning.

The form of the Provisioning file is dependent upon the protocol you use to manage devices. The following list shows the protocols used:

  • OMA Client Provisioning -- A one-way Wireless Application Protocol (WAP) push.
  • OMA Device Management (DM) -- Continuous provisioning.

The provisioning file can be sent over the air from a provisioning server to the device over a Global System for Mobile Communications (GSM) Short Message Service (SMS) wireless network that uses a WAP push gateway.

Service Indication (SI) and Service Loading (SL) can also be used to send and load provisioning XML files. The provisioning file is downloaded in a CAB Provisioning Format (.cpf) file.

A provisioning XML file in a cpf file can also be pulled by the device using the following mechanisms:

  • Over HTTP or HTTPS (Internet Explorer Mobile)
  • Using a Secure Digital Multimedia Card (SD/MMC).
Download in a CAB Provisioning Format (.cpf) file Provisioning XML can be downloaded in a CAB Provisioning Format (.cpf) file. For more information, see the Creating a .cpf File.
Send through Remote API (RAPI) Provisioning XML can be downloaded from the desktop, using the RAPI in ActiveSync to push the file to a device.
Send through DMProcessConfigXML API OEMs and application developers can provision a device by using the DMProcessConfigXML function. For information, see DMProcessConfigXML.
Provision during manufacture The OEM can burn the file in flash memory and configure the device such that the file is loaded during the cold or warm boot procedure. For more information, see Bootstrapping Windows Mobile-Based Devices.

The most common method of provisioning a device after deployment is OTA. The following figure shows the overall architecture of OTA provisioning. The actual path traveled will depend on the protocol used. The following sections explain this in more detail:

  • OMA Client Provisioning Device Management.

  • OMA Device Management.

    **Security Note   **For OMA Client Provisioning, configuration data is not encrypted when sent over the air (OTA). Be aware of this potential security risk when sending sensitive configuration data, such as passwords. OMA DM sessions are encrypted.

The following table shows the differences between how OMA Client Provisioning and OMA DM handle various features in Windows Mobile-based devices:

Feature OMA Client Provisioning OMA DM
Transport WAP-based Push over binary Short Message Service (SMS) HTTPr Secure Sockets Layer (SSL).
DM session One way push. There is no response channel, so you cannot get execution results or perform a remote query. Two way communication allows a request-response exchange.
Message format WAP Client Provisioning XML OMA-DM XML
Compression wbxml (tokenization) xml
DM commands Add

Windows Mobile extends the commands with update, delete, query-local usage.

Add, replace, get, exec, delete, and response
Managed settings Data connectivity, WAP gateway, and application access information

Windows Mobile extends with other custom settings.

DMAcc, DevInfo, DevDetail

No restriction, extendable DM tree. Windows Mobile extends with custom settings.

Security Data integrity and server authentication by using a OMA Client Provisioning standard, PIN signed message. There is no built-in encryption. For information about security roles, see Security Roles. Mutual authentication at the application and transport level. Encryption and data integrity check relies on SSL transport.
Access control None.

Windows Mobile extends with role-based access control.

Supports Windows Mobile role-base access control

For examples of OMA DM continuous provisioning, see OMA Device Management Provisioning.

See Also

Managing Devices | Security Roles

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.