Provisioning, policies, remote wipe, and the Allow/Block/Quarantine list in Exchange ActiveSync
In this article
Introduction
Understanding provisioning
Understanding policy settings
Understanding remote wipe
Understanding the Allow/Block/Quarantine list
Summary
Related resources
Introduction
Microsoft Exchange ActiveSync policy settings 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. Policy settings define the terms by which a client can synchronize mailbox data. The provisioning process is a communication between client and server that indicates whether the client can enforce the required policy settings.
In addition to policy settings, Microsoft Exchange Server 2010 introduces another tool for administrators, known as the Allow/Block/Quarantine (ABQ) list. The ABQ list enables administrators to control which devices or families of devices can synchronize data by using Exchange ActiveSync. Administrators can also use the ABQ list to block certain devices or all unknown devices from synchronizing data.
By using policy settings and the ABQ list, administrators can control how and whether data is synchronized onto a device. Additionally, the Remote Wipe feature of Exchange ActiveSync can be used to remove data from a device. This feature is useful 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.
In this article, I describe these features from the perspective of an Exchange ActiveSync developer:
Provisioning
Policy settings
Remote Wipe
Allow/Block/Quarantine
If you are creating an enterprise-class Exchange ActiveSync client, it is important that you understand and support these features.
Note
Information in this article about the following topics is important for the Exchange ActiveSync Logo Program:
-
Device manufacturer and model information
-
Password-related policy settings
-
MaxInactivityTimeDeviceLock policy
-
MaxDevicePasswordFailedAttempts policy
-
Remote Wipe
For more information about the logo program, see Exchange ActiveSync Logo Program.
Understanding provisioning
The client’s goal in provisioning is to obtain a policy key from the Exchange server. The policy key enables the client to synchronize with a mailbox. Provisioning involves the following steps:
Client and server exchange policy information.
The client submits a Provision command request to the server. The request includes information that identifies the client and specifies the policy format that the client wants the server to use.
The server responds with a Provision command response that contains policy settings that the client must enforce, and a temporary policy key.
Client acknowledges/applies policy settings and server provides policy key.
The client submits a Provision command request to the server to indicate its ability to enforce the security policy.
If the Provision command request indicates that the client can apply the security policy settings, the server responds with a Provision command response that contains a policy key that the client can use in subsequent requests to synchronize mailbox data.
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: Exchange ActiveSync provisioning process
.jpg "Exchange ActiveSync provisioning process")
Provisioning step 1: client and server exchange policy information
In the policy exchange process, the client submits a Provision command request, and the server responds with a Provision command response.
Client Provision request
The following example shows the Provision command request that the client submits when communicating with the Exchange server for the first time.
<?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 Provision command request contains information within two parent elements:
settings:DeviceInformation element
Policies element
We’ll discuss the settings:DeviceInformation element later in this article. The client uses information contained in the Policies element to specify the format of the policy information that the client wants the server to use. The client should always set the PolicyType element value to "MS-EAS-Provisioning-WBXML", 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 Provision command 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 |
settings:DeviceInformation element |
Provision command request |
|---|---|---|
Exchange ActiveSync version 12.1 |
Not supported |
The client should not include a settings:DeviceInformation element in the Provision command request because this element is not supported. |
Exchange ActiveSync version 14.0 |
Optional |
The settings:DeviceInformation element is optional in the Provision command request. However, in order to support ABQ, the client must submit the settings:DeviceInformation element in the Provision command request or in a Settings command request, as described in [MS-ASCMD]: ActiveSync Command Reference Protocol Specification section 2.2.3.43. |
Exchange ActiveSync version 14.1 |
Required |
The settings:DeviceInformation element is required in the Provision command request. The settings:Set child element is also required and must contain the settings:Model child element. |
For more information about the differences between Exchange ActiveSync protocol versions in client provisioning requests, see [MS-ASPROV] section 6.
Server Provision response
The following example shows the server response to the client’s Provision command request.
Note
The policy settings listed in this example do not represent all the possible policy settings that the server might send. For a complete list of policy settings, see [MS-ASPROV] section 2.2.2.
<?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 Provision command 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 the Understanding policy settings section later in this article.
Notice that the response contains two Status elements. The first Status element is a child element 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 policy settings. |
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 corrupted. 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 policy settings
After sending the Provision command response that contains the required policy settings, the server relies on the client to apply the policy settings as specified. After applying the security policy settings, the client sends another Provision command request to the server to acknowledge the policy settings and indicate its ability to apply them on the device.
Client Provision request
The following example shows the second Provision command request that the client sends to the server.
<?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 of the provisioning process. 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 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 an 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 indicate "success" are allowed to connect to the mailbox.
Important
When the client indicates "partial success" in its second Provision command request to the server, this means that the client failed to apply at least one of the security policy settings that the server returned in its initial response. Note, however, that there is a distinction between policy settings that are not relevant to the device and policy settings that the device was not able to apply. The policy settings 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 setting 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 indicate "partial success".
For any policy setting that requires a certain feature, the client must not indicate "success" if the policy setting cannot be applied. For example, the client should only indicate "success" for the RequireDeviceEncryption policy setting 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 policy settings, see the Understanding policy settings section later in this article.
Note
If the DevicePasswordEnabled policy setting is set to true, and the device is not able to enforce the password, it must indicate "failure" in its second Provision command request to the server, regardless of whether it can enforce any other policy setting. For any other policy setting that the client cannot enforce (that is, other than the DevicePasswordEnabled policy setting), the client can indicate "partial success" as long as it can enforce at least one other policy setting. For example, if the client enabled a password but failed to encrypt the device, it can indicate "partial success" rather than "failure".
Server Provision response
The following example shows the server response to the client’s second Provision command request.
<?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 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 should submit that policy key with all requests.
Note
Submitting the policy key is optional in the Ping command request and in HTTP OPTIONS commands.
The following example shows a FolderSync command request that includes the policy key.
<?xml version="1.0" encoding="utf-8"?>
<FolderSync xmlns="FolderHierarchy:">
<SyncKey>3942919513</SyncKey>
</FolderSync>
When should a client provision?
Clients should submit 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 that a client needs to provision again by responding to a client request with either a 449 HTTP error response or a success response with one of the status codes listed in the following table. The client should immediately submit a Provision command request after receiving one of these statuses in the server response.
Status code |
Name |
Description |
|---|---|---|
139 |
DeviceNotFullyProvisionable |
The device uses a protocol version that cannot send all the policy settings that the administrator enabled. The client should retry its request once per hour to determine whether the policy has changed. |
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. |
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 settings to the client every n hours and it is now time for the client to receive the policy settings again, regardless of whether the policy settings have changed. The client must 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 every 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 settings applied. The client should retry once per hour to determine whether the policy has changed. |
In version 12.1 of the Exchange ActiveSync protocol, the server sends an HTTP 449 response to indicate to the client that it needs to provision; the server does not send the status codes listed in the table earlier in this section. Because this error response does not enable the client to distinguish between transient and potentially non-transient provisioning errors, the client should try to provision if it receives an HTTP 449 response. If subsequent requests fail with additional HTTP 449 error responses, the client should suggest that the user contact the 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 comply with 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.
Understanding policy settings
Because the client is responsible for enforcing policy settings, it is important to understand the effects that each policy setting will have on the device when applied. For a list of the elements that contain policy setting information, see [MS-ASPROV] section 2.2.2. This information will help you determine acceptable values and expected results for each policy setting. For more information about policies in general, see Understanding Exchange ActiveSync Mailbox Policies.
The tables in this section list and describe some of the policy settings that are available; they do not provide a comprehensive list of all policy settings. For more information about policy settings, see [MS-ASPROV].
The following table lists policy settings that clients can ignore and describes the conditions in which they can be ignored. If the conditions apply, the client can indicate "success" in the Provision command request even though the policy setting is not applied. Policy settings that are not listed in this table cannot be ignored under any conditions.
Policy setting 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 0 (FALSE) 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 can encrypt the storage card. |
AllowSimpleDevicePassword |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). |
AlphanumericDevicePasswordRequired |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). |
DevicePasswordExpiration |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). |
DevicePasswordHistory |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). |
MinDevicePasswordComplexCharacters |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). Also can safely be ignored if the AlphanumericDevicePasswordRequired element is set to 0 (FALSE). |
MaxDevicePasswordFailedAttempts |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). |
MinDevicePasswordLength |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). |
PasswordRecoveryEnabled |
Ignored if the value of the DevicePasswordEnabled element is 0 (FALSE). |
The following table describes the expected behavior for additional policy settings.
Policy setting 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 (in kilobytes) at which to truncate email messages when synchronized to the client. 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 (in kilobytes) at which to truncate HTML email messages when synchronized to the client. 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. |
Understanding remote wipe
The remote wipe feature 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.
After an administrator requests a remote wipe, the next time that the client sends a request to the server, the server will respond with status code 140, RemoteWipeRequested. Upon receiving this response from the server, the client should submit a Provision command request. If the server's response contains a RemoteWipe element, the client should send an acknowledgement to the server to indicate that it will erase all data from the device. The client must send this acknowledgement before erasing all data from memory and storage because it will not have access to 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 status code 140, RemoteWipeRequested) to request that the client send a Provision command, to which the server will respond with a RemoteWipe element.
The following example shows a Provision command response from the server that includes the RemoteWipe element.
<?xml version="1.0" encoding="utf-8"?>
<Provision>
<Status>1</Status>
<RemoteWipe />
</Provision>
The following example shows a Provision command request from the client to acknowledge the remote wipe status.
<?xml version="1.0" encoding="utf-8"?>
<Provision xmlns="Provision:">
<RemoteWipe>
<Status>1</Status>
</RemoteWipe>
</Provision>
The following table lists valid values for the Status element in the Provision command request.
Status element value |
Meaning |
Description |
|---|---|---|
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.
Understanding the Allow/Block/Quarantine list
The Allow/Block/Quarantine (ABQ) list is a new feature introduced in Exchange 2010 that enables administrators to control device access to mailboxes based on device type. While provisioning and policy settings focus on managing device features such as passwords, cameras, encryption, and so on, ABQ simply controls access to the mailbox. Administrators use ABQ together with policy settings to manage Exchange ActiveSync clients. For more information, see Controlling Exchange ActiveSync device access using the Allow/Block/Quarantine list.
Microsoft Exchange manages access to the mailbox through the ABQ list 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 request, 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 following table lists and describes the elements that are set by the client in the Settings command request.
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 status code 5 because a phone number is required 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 that support 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.
Summary
In this article, we’ve explored how Exchange ActiveSync uses provisioning, policy settings, remote wipe, and ABQ to manage security settings, determine a client device’s permissions to synchronize mailbox data, and manage a client device’s access to mailbox data. For more information about these topics, see [MS-ASPROV], Understanding Exchange ActiveSync Mailbox Policies, Understanding Remote Device Wipe, and Controlling Exchange ActiveSync device access using the Allow/Block/Quarantine list.
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