Provisioning, Policies, Remote Wipe, and ABQ in Exchange ActiveSync
This post is part of an ongoing series that covers Microsoft Exchange ActiveSync for developers.
Microsoft Exchange ActiveSync policies are the primary tool by which IT administrators can manage devices that connect to Microsoft Exchange mailboxes. Administrators can create policy settings to manage security settings such as PIN length, data encryption, and so on. Policies define the terms by which a client can synchronize mailbox data. The provisioning process is a communication that occurs between the client and server that indicates whether the client can enforces the required policies.
In addition to policies, Microsoft Exchange Server 2010 introduces another tool for administrators, known as Allow/Block/Quarantine (ABQ). ABQ enables administrators to control which devices or families of devices can synchronize data with Exchange ActiveSync. Administrators can also use ABQ to block certain devices or all unknown devices from synchronizing data.
Both ABQ and policies help administrators control how and whether data is synchronized onto a device. Remote Wipe is another Exchange ActiveSync feature that is used to remove data froma device. This feature is important when, for example, individuals leave the company, or a device is lost or stolen.
If you are creating an enterprise-class Exchange ActiveSync client, it is important for you to understand and support provisioning and policies, ABQ, and remote wipe. This post provides the information you need to know about these features, in the following sections:
- Provisioning
- Policies
- Remote wipe
- ABQ
Note
The following information, covered in this blog post, is important for the Exchange ActiveSync Logo Program: · Device manufacturer and model information · Password-related policies · MaxInactivityTimeDeviceLock policy · MaxDevicePasswordFailedAttempts policy · Remote Wipe
For more information about the logo program, see Exchange ActiveSync Logo Program on Microsoft TechNet. |
Provisioning
The client’s goal in provisioning is to obtain a policy key from the Exchange server. This policy key enables the client to synchronize with a mailbox. Provisioning involves the following steps:
- The client sends information to the server to identify itself.
- The server sends security policies to the client that the client must enforce.
- The client indicates whether it is able to enforce the security policies.
- If the policies are applied successfully, the client is given a policy key that it then submits with subsequent requests to synchronize the mailbox.
For a detailed description of this process, see [MS-ASPROV]: ActiveSync Provisioning Protocol Specification section 3.1.5.1.
The following figure shows the two-step provisioning process.
Figure 1: Two-step provisioning process
Provisioning step 1: policy exchange between client and server
The policy exchange process involves a client Provision command request and a server Provision command response.
Client provisioning request
In its first request to the Exchange server, the client sends a Provision command request, as shown in the following example.
POST /Microsoft-Server-ActiveSync?User=deviceuser&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=Provision HTTP/1.1
Accept-Language: en-us
MS-ASProtocolVersion: 14.0
Content-Type: application/vnd.ms-sync.wbxml
X-MS-PolicyKey: 0
User-Agent: ASOM
Host: EXCH-B-003
<?xml version="1.0" encoding="utf-8"?>
<Provision xmlns="Provision:" xmlns:settings="Settings:">
<settings:DeviceInformation>
<settings:Set>
<settings:Model>… </settings:Model>
<settings:IMEI>...</settings:IMEI>
<settings:FriendlyName>...</settings:FriendlyName>
<settings:OS>...</settings:OS>
<settings:OSLanguage>...</settings:OSLanguage>
<settings:PhoneNumber>...</settings:PhoneNumber>
<settings:MobileOperator>...</settings:MobileOperator>
<settings:UserAgent>...</settings:UserAgent>
</settings:Set>
</settings:DeviceInformation>
<Policies>
<Policy>
<PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>
</Policy>
</Policies>
</Provision>
The client Provision command request includes information contained within two parent elements:
- settings:DeviceInformation element
- Policieselement
I will discuss the settings.DeviceInformation element in more detail in the "ABQ" section later in this post.
In the Policies element section, the client indicates in the PolicyType element the format of the policy information that the client wants the server to use. The client should always send the “MS-EAS-Provisioning-WBXML” value, as described in [MS-ASPROV] section 2.2.2.42.
Provisioning request for different Exchange ActiveSync protocol versions
The use of the settings:DeviceInformation element in the provisioning request varies based on the version of the Exchange ActiveSync protocol the client is using, as described in the following table.
Exchange ActiveSync protocol version |
Provision command request |
Exchange ActiveSync version 12.1 |
The client should not include a settings:DeviceInformation element because this element is not supported. |
Exchange ActiveSync version 14.0 |
The settings:DeviceInformation element is optional. However, in order to support ABQ, the client must submit the DeviceInformation element with the Provision command request or with a Settings command request, as described in [MS-ASCMD]: ActiveSync Command Reference Protocol Specification section 2.2.3.43. |
Exchange ActiveSync version 14.1 |
The settings:DeviceInformation element is required. The settings:Set child element is also required and must contain the Model child element. |
For more information about the differences between Exchange ActiveSync protocol versions in client provisioning requests, see [MS-ASPROV] section 6.
Server provisioning response
The following example shows a server response to a client provisioning request.
Note: The policies listed in this example do not represent all the possible policies thatthe server might send. For a complete list of policies, see [MS-ASPROV] section 2.2.2.
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 1069
Date: Mon, 01 May 2006 20:15:15 GMT
Content-Type: application/vnd.ms-sync.wbxml
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
MS-Server-ActiveSync: 8.0
Cache-Control: private
<?xml version="1.0" encoding="utf-8"?>
<Provision xmlns:A0="AirSync:" xmlns:A1="POOMCONTACTS:" xmlns:A2="POOMMAIL:" xmlns:A3="AirNotify:" xmlns:A4="POOMCAL:" xmlns:A5="Move:" xmlns:A6="GetItemEstimate:" xmlns:A7="FolderHierarchy:" xmlns:A8="MeetingResponse:" xmlns:A9="POOMTASKS:" xmlns:A10="ResolveRecipients:" xmlns:A11="ValidateCert:" xmlns:A12="POOMCONTACTS2:" xmlns:A13="Ping:" xmlns:A15="Search:" xmlns:A16="Gal:" xmlns:A17="AirSyncBase:" xmlns:A18="Settings:" xmlns:A19="DocumentLibrary:" xmlns:A20="ItemOperations:" xmlns:A21="ComposeMail:" xmlns:A22="POOMMAIL2:" xmlns:A23="Notes:" xmlns:A24="RightsManagement:" xmlns="Provision:">
<Status>1 Success</Status>
<Policies>
<Policy>
<PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>
<Status>1 Success</Status>
<PolicyKey>2488355417</PolicyKey>
<Data>
<eas-provisioningdoc>
<DevicePasswordEnabled>1</DevicePasswordEnabled>
<AlphanumericDevicePasswordRequired>0</AlphanumericDevicePasswordRequired>
<PasswordRecoveryEnabled>0</PasswordRecoveryEnabled>
<RequireStorageCardEncryption>0</RequireStorageCardEncryption>
<AttachmentsEnabled>1</AttachmentsEnabled>
<MinDevicePasswordLength>4</MinDevicePasswordLength>
<MaxInactivityTimeDeviceLock>900</MaxInactivityTimeDeviceLock>
<MaxDevicePasswordFailedAttempts>8</MaxDevicePasswordFailedAttempts>
<MaxAttachmentSize/>
<AllowSimpleDevicePassword>1</AllowSimpleDevicePassword>
<DevicePasswordExpiration/>
<DevicePasswordHistory>0</DevicePasswordHistory>
<AllowStorageCard>1</AllowStorageCard>
<AllowCamera>1</AllowCamera>
<RequireDeviceEncryption>0</RequireDeviceEncryption>
<AllowUnsignedApplications>1</AllowUnsignedApplications>
<AllowUnsignedInstallationPackages>1</AllowUnsignedInstallationPackages>
<MinDevicePasswordComplexCharacters>1</MinDevicePasswordComplexCharacters>
<AllowWiFi>1</AllowWiFi>
<AllowTextMessaging>1</AllowTextMessaging>
<AllowPOPIMAPEmail>1</AllowPOPIMAPEmail>
<AllowBluetooth>2</AllowBluetooth>
<AllowIrDA>1</AllowIrDA>
<RequireManualSyncWhenRoaming>0</RequireManualSyncWhenRoaming>
<AllowDesktopSync>1</AllowDesktopSync>
<MaxCalendarAgeFilter>0</MaxCalendarAgeFilter>
<AllowHTMLEmail>1</AllowHTMLEmail>
<MaxEmailAgeFilter>0</MaxEmailAgeFilter>
<MaxEmailBodyTruncationSize>-1</MaxEmailBodyTruncationSize>
<MaxEmailHTMLBodyTruncationSize>-1</MaxEmailHTMLBodyTruncationSize>
<RequireSignedSMIMEMessages>0</RequireSignedSMIMEMessages>
<RequireEncryptedSMIMEMessages>0</RequireEncryptedSMIMEMessages>
<RequireSignedSMIMEAlgorithm>0</RequireSignedSMIMEAlgorithm>
<RequireEncryptionSMIMEAlgorithm>0</RequireEncryptionSMIMEAlgorithm>
<AllowSMIMEEncryptionAlgorithmNegotiation>2</AllowSMIMEEncryptionAlgorithmNegotiation>
<AllowSMIMESoftCerts>1</AllowSMIMESoftCerts>
<AllowBrowser>1</AllowBrowser>
<AllowConsumerEmail>1</AllowConsumerEmail>
<AllowRemoteDesktop>1</AllowRemoteDesktop>
<AllowInternetSharing>1</AllowInternetSharing>
<UnapprovedInROMApplicationList/>
<ApprovedApplicationList/>
</eas-provisioningdoc>
</Data>
</Policy>
</Policies>
</Provision>
The response includes the following:
- A PolicyKey element, which contains a policy key that the client should retain and submit to the server with its next request.
- A Data element and its child elements, which contain the policy settings that the server requires the client to apply. For more information about individual policy settings, see "Policies" later in this blog post.
Notice that the response contains two Status elements. The first Status element is a child of the Provision element and indicates the general status of the Exchange server’s ability to process the client’s request. The following table lists the possible values for the first Status element.
Status element value |
Meaning |
Description |
1 |
Success |
The Policies element contains the information about the security policies. |
2 |
Protocol error |
The request was malformed. |
3 |
General server error |
A transient error occurred. The client should retry the request over a period of time. |
The second Status element is a child of the Policy element and indicates whether the policy settings were applied correctly. The following table lists the possible values for the Status element.
Status element value |
Meaning |
Description |
1 |
Success |
The Data element contains the policy settings to apply. |
2 |
No policy |
The server doesn't have a policy. The device doesn't need to submit a second request; it can proceed to sync data. |
3 |
Unknown policy type |
The device sent an invalid value for the PolicyType element. The only valid value for the PolicyType element is “MS-EAS-Provisioning-WBXML”. |
4 |
Policy data is corrupt |
The policy data on the server is corrupt. The device should suggest that the user contact the administrator. |
5 |
Policy key mismatch |
The policy key sent in the last request does not match the key stored on the server. Either the device sent the wrong policy key or the policy changed on the server since the first response. The device should re-initiate the provisioning process from the beginning. |
Provisioning step 2: client acknowledges and applies policies
At this point, the server relies on the client to apply the policies as requested. After applying the security policy settings, the client sends another Provision command request to the server to acknowledge the policies and indicate its ability to apply them on the device.
The following example shows the second Provision request that the client sends to the server.
POST /Microsoft-Server-ActiveSync?User=deviceuser&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=Provision HTTP/1.1
Accept-Language: en-us
MS-ASProtocolVersion: 14.0
Content-Type: application/vnd.ms-sync.wbxml
X-MS-PolicyKey: 1307199584
User-Agent: ASOM
Host: EXCH-B-003
<?xml version="1.0" encoding="utf-8"?>
<Provision xmlns="Provision:">
<Policies>
<Policy>
<PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>
<PolicyKey>1307199584</PolicyKey>
<Status>1</Status>
</Policy>
</Policies>
</Provision>
This request contains the policy key value that the server sent to the client in step 1. It also contains a Status element that indicates whether the client was able to apply the policy settings. The following table lists the possible values of the Status element.
Status element value |
Meaning |
Description |
1 |
Success |
The client was able to apply all the policy settings. |
2 |
Partial success |
The client was able to apply some of the policy settings but failed to apply others. |
3 |
Failure |
The client was not able to apply any of the policy settings. |
4 |
Externally managed |
The client was provisioned by a third party. |
Note: If a Microsoft Exchange administrator sets the "Allow non-provisionable devices" option in the Exchange ActiveSync policy, the server will allow all clients to synchronize mailbox data regardless of whether the client asked for policy settings or applied them successfully. However, if the administrator chooses to disable the "Allow non-provisionable devices" option, only clients that respond with "Success" are allowed to connect to the mailbox.
Important: When the client indicates "partial success" in its second request to the server, this means that the client failed to apply at least one of the security policies that the server returned in its initial response. Note, however, that there is a distinction between policies that are not relevant to the device and policies that the device was not able to apply. The policies that “allow” and “disallow” certain features of the device do not have to be applied if they are not relevant to the device in order for the client to indicate "success" in its request. For example, if the device does not support Bluetooth, the client can safely ignore the AllowBluetooth policy and report back “success” instead of “partial success”. Conversely, if AllowBluetooth is set to false and the device supports Bluetooth but cannot disable it, the device can return “partial success”. For any policy that requires a certain feature, the client must not return success if the policy cannot be applied. For example, the client should only indicate "success" for the RequireDeviceEncryption policy when the client supports device encryption. If the device doesn’t support encryption, the client should indicate "partial success" or "failure", depending on the status of the other policies. For more information about specific policies, see "Policies" later in this blog post. |
Note: If the DevicePasswordEnabled policy is set to true, and the device is not able to enforce the password, it must return "failure" in response to the Provision command, regardless of whether it can enforce any other policy. The client can return "partial success" if it cannot enforce any other policies. For example, if the client enabled a password but failed to encrypt the device, it can return "partial success" rather than "failure".
The following example shows the server's response to the second client Provision request.
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 63
Date: Mon, 01 May 2006 20:15:17 GMT
Content-Type: application/vnd.ms-sync.wbxml
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
MS-Server-ActiveSync: 8.0
Cache-Control: private
<?xml version="1.0" encoding="utf-8"?>
<Provision xmlns="Provision:">
<Status>1</Status>
<Policies>
<Policy>
<PolicyType> MS-EAS-Provisioning-WBXML </PolicyType>
<Status>1</Status>
<PolicyKey>3942919513</PolicyKey>
</Policy>
</Policies>
</Provision>
This response does not include a Data element that contains the list of policy settings. The server simply responds with a Status element (the values for which are listed in the "Server provisioning response" section) and a new policy key. This new policy key is the permanent key that the client should save and resubmit when it sends subsequent requests to the server.
Client handling of the policy key
The policy key represents the current security policy settings that are applied on the client. It can be up to 64 characters long and can contain any of the characters that are allowed in an HTTP header. The client should retain only the latest policy key that it has received from the server and submit it with all requests.
Note: Submitting the policy key is optional the Ping command and the HTTP OPTIONS commands.
The following example shows a client request that includes the policy key.
POST /Microsoft-Server-ActiveSync?User=deviceuser&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=FolderSync HTTP/1.1
Accept-Language: en-us
MS-ASProtocolVersion: 14.0
Content-Type: application/vnd.ms-sync.wbxml
X-MS-PolicyKey: 3942919513
User-Agent: ASOM
Host: EXCH-B-003
<?xml version="1.0" encoding="utf-8"?>
<FolderSync xmlns="FolderHierarchy:">
<SyncKey>0</SyncKey>
</FolderSync>
When should a client provision?
Clients should send a Provision command request when they first contact the server. In some scenarios, the server may require the client to provision again, after an initial provision sequence. The server indicates this by sending a 449 HTTP error response or a success response with one of the status codes listed in the following table in response to any client request. The client should immediately send a Provision command request after receiving one of these statuses in a response.
Status code |
Name |
Description |
139 |
DeviceNotFullyProvisionable |
The device uses a protocol version that cannot send all the policy settings the administrator enabled. The client should retry its request once per hour to determine whether the policy has changed. Important: This is status code indicates a condition that will not be resolved until the administrator changes the policy. The client should display a warning that it cannot synchronize due to current policy settings and recommend that the user contact their administrator |
140 |
RemoteWipeRequested |
The server requests that the client wipe all data. The client should send a Provision command request so that it can acknowledge the wipe request. |
141 |
LegacyDeviceOnStrictPolicy |
The client is not capable of provisioning and the administrator has decided to make the policy a strict requirement. The client cannot synchronize until the policy changes. The client should retry once per hour to determine whether the policy has changed. Important: This is status indicates a condition that will not be resolved until the administrator changes the policy. The client should display a warning that it cannot synchronize due to current policy settings and recommend that the user contact their administrator. |
142 |
DeviceNotProvisioned |
The client has not provisioned yet and must send a Provision command request immediately. |
143 |
PolicyRefresh |
The server is configured to send the policy to the client every n hours and it is now time for the client to receive the policy again, regardless of whether the policy has changed. The client has to resend the Provision command request to obtain a new policy key. |
144 |
InvalidPolicyKey |
The policy key sent by the client is no longer valid. This occurs when the policy is changed on the server (a new policy key is generated each time the policy changes). The client has to resend the Provision command request to get the new policy. |
145 |
ExternallyManagedDevicesNotAllowed |
The client indicated that it was provisioned through another mechanism but the server is configured to require that the client have the server's policy applied. The client should retry once per hour to determine whether the policy has changed. Important: This status indicates a condition that will not be resolved until the administrator changes the policy. The client should display a warning that it cannot synchronize due to current policy settings and recommend that the user contact their administrator. |
In version 12.1 of the Exchange ActiveSync protocol, the server only sends an HTTP 449 response to inform the client that it needs to provision; it does not send the status codes listed in the previous table. Because this error response does not enable the client to distinguish between transient and potentially nontransient provisioning errors, the client should try to provision. If subsequent requests fail with additional HTTP 449 error respon ses, the client should suggest that the user contact their administrator. At that point, the client may choose to try to provision once per hour to determine whether the policy has changed.
Important: The client should compare existing device settings against policy updates to ensure that it is compliant with the updated policy. For example, if a password is set on the client, the client should compare the existing password (length, complexity, and so on) against the updated policy settings requested by the server. If the existing password does not conform to these updated policy settings or if the client cannot verify that the current password meets the requirements, the client should prompt the user to configure a new password. |
Policies
Because it is up to the client to enforce policies, it is important to understand the effects that each policy will have on the device when applied. For a list of the elements that contain policy information, see [MS-ASPROV] section 2.2.2. This information will help you to determine acceptable values and expected results for each policy. For more information about policies in general, see Understanding Exchange ActiveSync Mailbox Policies on Microsoft TechNet.
This section lists and describes some of the policies that are available; it does not provide a comprehensive list of all policies. For more information about policies, see [MS-ASPROV].
The following table lists policies that clients can ignore and describes the conditions in which they can be ignored. If the conditions apply, the client can return "success" although the policy is not applied. Policies that are not listed in this table cannot be ignored under any conditions.
Policy name |
Condition |
AllowBluetooth |
Ignored if the device does not support Bluetooth. |
AllowCamera |
Ignored if the device does not have a camera and a camera cannot be attached to the device. |
AllowDesktopSync |
Ignored if the device does not support connecting to a personal computer. |
AllowInternetSharing |
Ignored if the device does not support sharing its Internet connection with other devices. |
AllowIrDA |
Ignored if the device cannot transmit or receive infrared signals. |
AllowRemoteDesktop |
Ignored if the device does not support connecting remotely to a personal computer. |
AllowStorageCard |
Ignored if the device does not support storing data on removable storage. |
AllowTextMessaging |
Ignored if the device is not capable of using SMS messaging. |
AllowWifi |
Ignored if the device does not have Wi-Fi capability. |
PasswordRecoveryEnabled |
Ignored if the DevicePasswordEnabled element is set to FALSE (0) or if the client does not support recovery passwords. |
RequireStorageCardEncryption |
Ignored if the device does not support removable storage. If the device supports removable storage, it must reply to this policy request based on whether it is able to encrypt the storage card. |
AllowSimpleDevicePassword, AlphanumericDevicePasswordRequired, DevicePasswordExpiration, DevicePasswordHistory, MinDevicePasswordComplexCharacters, MaxDevicePasswordFailedAttempts, MinDevicePasswordLength, PasswordRecoveryEnabled |
Ignored if the value of the DevicePasswordEnabled element is FALSE (0). In addition, the MinDevicePasswordComplexCharacters policy can safely be ignored if the AlphanumericDevicePasswordRequired policy is set to false. |
The following table lists additional policies and describes the expected behavior:
Policy name |
Expected behavior |
AllowSimpleDevicePassword |
The server does not define a simple password. In general, simple passwords can include sequential digits (1234), repeating digits (1111), letters in keyboard order (qwerty), and so on. |
AlphanumericDevicePasswordRequired |
If the device can only enforce a numeric PIN, the client must fail to apply this policy if it is enabled. |
DeviceEncryptionEnabled |
The client should encrypt any data received from the server, including email messages, contacts, attachments, and so on. The client is not required to encrypt other data, such as photos or music. |
DevicePasswordEnabled |
If this policy is enabled, the client must require that the user enter a password before accessing any data obtained from the server, including email messages, contacts, attachments, and so on. |
MaxDevicePasswordFailedAttempts |
Specifies the number of consecutive attempts a user can make to enter the correct password for the device. After this number of attempts, the device must wipe all data obtained from the server. The device can (and should) implement a mechanism to prevent accidental button presses from causing a device wipe. |
MaxEmailBodyTruncationSize |
Specifies the maximum size at which to truncate email messages when synchronized to the client. The value is in kilobytes (KBs). The client must not allow the user to choose a value larger than this setting. This value does not restrict the size of items returned by the ItemOperations command. The device can download the full items. |
MaxEmailHTMLBodyTruncationSize |
Specifies the maximum size at which to truncate HTML email messages when synchronized to the client. The value is in KBs. The device must not allow the user to choose a value larger than this setting. This value does not restrict the size of items returned by the ItemOperations command. The device can download the full items. |
MaxInactivityTimeDeviceLock |
Specifies the length of time (in seconds) that the device can be inactive before the password is required to reactivate it. The user can choose a value that is smaller than this, but cannot choose a value that is larger. |
PasswordRecoveryEnabled |
A recovery password is a second password that can be used to unlock the device if the user forgets their original password. When the user enters the recovery password, the client should prompt the user to create a new password immediately. The client should then create a new recovery password and send it to the server by using the Settings command as soon as possible. This is not technically a policy, because the client can still synchronize even if the device does not send a recovery password to the server. The purpose of this setting is to indicate to the client whether the server is willing to store a recovery password for the client. If the value for this policy is zero, the client should not send a recovery password to the server. |
Remote Wipe
The remote wipe process enables administrators to request that the client erase all data from a device. Remote wipe is used in scenarios in which a device is lost or stolen or when a user has left the company or no longer has permission to synchronize corporate data. Administrators can use the Exchange Management Shell or the Exchange Management Console (EMC) to request a remote wipe. For more information, see Understanding Remote Device Wipe on Microsoft TechNet.
After an administrator requests a remote wipe, the next time the client sends a request to the server, the server will respond with status code 140, RemoteWipeRequested. The client should then submit a Provision command request. If the server's response contains a RemoteWipe element, the client should send an acknowledgement that it is about to wipe the device first. Because the wipe will erase all data from memory and storage, the client sends the acknowledgement first because it will not have the information it needs to send requests after it wipes the device. For examples of the requests and responses that are sent during the remote wipe process, see [MS-ASPROV] section 4.2.
Note: In version 12.1 of the Exchange ActiveSync protocol, the server sends an HTTP 449 response instead of the 140 status code to request that the client send a Provision command to which the server will respond with a RemoteWipe element. |
The following is an example of a server response to a Provision command request that includes a RemoteWipe element.
Content-Type: application/vnd.ms-sync.wbxml
Date: Wed, 25 Mar 2009 01:23:58 GMT
Content-Length: 14
<?xml version="1.0" encoding="utf-8"?>
<Provision>
<Status>1</Status>
<RemoteWipe />
</Provision>
The following example shows a Provision command request from the client that contains the remote wipe status.
POST /Microsoft-Server-ActiveSync?Cmd=Provision&User=T0SyncUser1v14.0&DeviceId=Device1&DeviceType=PocketPC HTTP/1.1
Content-Type: application/vnd.ms-sync.wbxml
MS-ASProtocolVersion: 14.0
X-MS-PolicyKey: 0
User-Agent: ASOM
Host: EXCH-B-003
<?xml version="1.0" encoding="utf-8"?>
<Provision xmlns="Provision:">
<RemoteWipe>
<Status>1</Status>
</RemoteWipe>
</Provision>
The client should include one of the following values in the Status element:
- 1 (Success) — Indicates that the client will wipe the device shortly after sending.
- 2 (Failure) — Indicates that the client could not wipe the device.
Important: Wiping the device resets the device to factory default conditions, including removing all data on the device and any data on the storage card if one is included. |
ABQ
Allow/Block/Quarantine (ABQ) is a new feature introduced in Exchange 2010 that enables administrators to control device access to mailboxes based on device type. While provisioning and policies focus on managing device features such as passwords, cameras, encryption, and so on, ABQ simply controls access to the mailbox. Administrators use ABQ along with policies to manage Exchange ActiveSync clients. For more information, see Controlling Exchange ActiveSync device access using the Allow/Block/Quarantine list on the Exchange Team Blog.
Microsoft Exchange manages access to the mailbox through ABQ by using device information that it relies on the client to provide. The client sends this information in the Provision command request or as part of the Settings command, as shown in the following example.
<?xml version="1.0" encoding="utf-8"?>
<Settings xmlns="Settings:">
<DeviceInformation>
<Set>
<Model>CONTOSO</Model>
<IMEI>123456789012345</IMEI>
<FriendlyName>Matt's Phone</FriendlyName>
<OS>Contoso Phone1.0.1234</OS>
<OSLanguage>English</OSLanguage>
<PhoneNumber>555-555-1234</PhoneNumber>
<MobileOperator>ContosoTelecom</MobileOperator>
<UserAgent>ContosoPhone1</UserAgent>
<EnableOutboundSMS>1</EnableOutboundSMS>
</Set>
</DeviceInformation>
</Settings>
The elements set by the client are listed in the following table:
Element name |
Description |
Model |
Indicates the manufacturer and model name or number of the device. |
FriendlyName |
Describes the device in a way that is meaningful to a user. |
IMEI |
Uniquely identifies the device. |
OS |
Precisely specifies the operating system version that the client is running. The OS element value is structured as follows: <Operating System Name> <Operating System Major Version> <Operating System Minor Version>. |
OSLanguage |
Indicates the language used by the client. The server displays this information when it lists device properties. |
PhoneNumber |
Can be provided to help with troubleshooting or device management. This element is optional unless the EnableOutboundSMS element is set to 1, in which case the server returns a status code 5 because a phone number is required in order for the server to try to send SMS messages. |
MobileOperator |
Indicates the name of the operator that a mobile device is connected to. |
UserAgent |
The value of this element should match the User-Agent header values that are submitted with each request. |
EnableOutboundSMS |
This element should have a value of either 1 or 0 to indicate whether the client can be used to send outbound SMS messages composed by the server. |
Note: Clients thatsupport versions 12.1 and 14.0 of the Exchange ActiveSync protocol should use the Settings command to send device information. The client should send the Settings command as soon as possible after provisioning and before sending the first FolderSync command. |
Related Resources
[MS-ASCMD]: ActiveSync Command Reference Protocol Specification
[MS-ASPROV]: ActiveSync Provisioning Protocol Specification
Understanding Exchange ActiveSync Mailbox Policies
Understanding Remote Device Wipe
Controlling Exchange ActiveSync device access using the Allow/Block/Quarantine list
Post authored by: Matt Stehle, Microsoft Corporation
Comments
Anonymous
September 20, 2011
Moving along with Exchange ActiveSync on my own blog I have utilised parts of the info above when producing C# code samples on how to perform the provisioning process: mobilitydojo.net/.../exchange-activesync-building-blocks-provisioningAnonymous
September 28, 2011
This week I have added sample code for the remote wipe bits along with explanations: mobilitydojo.net/.../exchange-activesync-building-blocks-remote-wipe