Policy Settings for Mobile Devices

Exchange stores the policy settings for mobile devices in the msExchOmaExtendedProperties attribute in its configuration data in Active Directory (AD). The attribute is a multivalued string that includes an XML blob that contains the policy elements to apply to mobile devices (the XML blob is in a format that mobile devices understand). Every time a mobile device attempts to execute an ActiveSync command, it sends its policy key in the request's HTTP header. Exchange compares the device’s policy key with its own value (which is stored in the PolicyKey portion of msExchOmaExtendedProperties), and if the two values don't match, Exchange returns a HTTP status code of 449 to cause the device to fetch the updated policy settings and apply them before it can continue to synchronize. You can cause devices to refresh their policy settings on a regular basis by setting a value in Refresh settings in the device (hours). Exchange holds the policy setting (in minutes; the UI shows the value in hours) in the PolicyDataRefreshInterval string in the msExchOmaExtendedProperties attribute and the timestamp when it sent the policy successfully to a device in the user’s mailbox. If you set a device refresh policy, try to come up with a value such as 144 (weekly) that doesn't cause devices to constantly refresh an unchanged policy.

The msExchOmaExtendedProperties attribute also includes a setting called PolicyDataSalt, which some random bytes encoded in base64 format. Exchange uses these bytes to create a hashed version of the timestamp for the last successful policy update and stores that value along with the timestamp in the user’s mailbox. Users don't know the random bytes, so they can't write applications to reset the last successful policy timestamp in their mailboxes because they can't generate the hash to sign the timestamp. Table 1 lists the other policy elements (or characteristics).

You could inadvertently cause Exchange to wipe your device by responding to requests to input your PIN. For example, some devices reset themselves to fix a hardware or software problem and require you to enter your PIN before the device can reconnect to Exchange. If the reset happens when the device is in your pocket, you probably won't notice that the device is requesting the PIN. And if you haven't locked the device, the movement of the device in your pocket can press various keys, leading to a number of unsuccessful PIN attempts. Another common situation that can cause a device reset is when a child picks up the device and plays with it. Children probably don't understand what a PIN is, nor do they care; all they're concerned about is playing with the device’s keypad. Exchange therefore includes a CodeWordFrequency setting that's set to half the value of DeviceWipeThreshold. When the device reaches the number of failed PIN attempts equivalent to the value of CodeWordFrequency, it outputs a request for a code word. The code word isn't actually a code; it's just a request for users to input the value the device displays to confirm that they're really attempting to enter a PIN. Inadvertently pressed keys shouldn't generate the correct code, and most children who play with a keypad won't enter the right code, so this mechanism prevents Exchange from wiping a device unless it's necessary.

End of Article