When we embarked last year upon upgrading our Exchange infrastructure from Exchange 2007 to Exchange 2010, one thing we had to do make that transition go smoothly was to rip out the Default Exchange ActiveSync Mailbox Policy. The reason for removing this default policy was to avoid issues with Android devices operating in a mixed 2007/2010 environment, the Android implementation of ActiveSync being based upon an obsolete version of the protocol. The removal of this policy had always been intended to be temporary, but we had held off since our testing revealed that re-application of the policy would result in a rather scarily-worded alert being generated on Android devices, causing end-user confusion.

Fast-forward to this last weekend. We applied Service Pack 2 and Update Rollup 4 to our Exchange environment. The process went smoothly, and we encountered no problems. But something unexpected happened, something that went quietly unnoticed in our testing.

The Default Exchange ActiveSync Mailbox Policy got re-created. And it got re-applied to all mailboxes.

Something that we had wanted to eventually happen happened, but not at the time and manner of our choosing. And the Android devices issued that scary alert, with its implied message that we are taking complete control of their phone.

Among some of our users, this raised privacy concerns, and illuminated some gaps in our published documentation. Where is the written policy that we wouldn’t abuse the control offered to us by this policy object? There is none, something which we are in the midst of rectifying.

“So what exactly is an ActiveSync Mailbox Policy?” you might quite rightly ask.

When a device connects to Exchange via ActiveSync, the ActiveSync mailbox policy pushes down rules to the device about what it can and cannot do so long as that device is associated with the Exchange server. This includes rules which are very desirable in corporate or government environments, such as turning off cameras, forbidding removable storage, requiring device passwords, and giving users (and Exchange administrators) the ability to remotely wipe devices in the even that they are lost or stolen.

For most of these remote administration features, we are frankly not interested in using them. The default, out-of-box policy has these set in the most non-restrictive manner imaginable, and we have no plans to change that.

But, the part that we are interested in, remotely wiping devices, we wish to make available to our users. If it weren’t for that feature, we could quite happily get along without having a device policy in place on our servers. But that is an important one. The ability to remotely erase a lost or stolen device is critical, and it has been missing while we’ve been without that device policy.

There is an important point to be made here: remote wipes are user-initiated, exposed via the Exchange Control Panel (under Options -> See All Options in OWA, then selecting “Phone” in the left-hand navigation bar). While the policy also gives the Exchange administrators to the ability to initiate these wipes as well, we long ago, after extensive consultation with the Information Security Office, reached a consensus that WE would not initiate device wipes ourselves, leaving this to the device users. (One potential exception would be the instance of an explicit request from a user who has had a device lost or stolen and who is not where they are able to access OWA to initiate the wipe themselves.) There have been court cases where companies and institutions have been held liable for data remotely erased from user-owned devices. That is not where we wish to be.

In short, we aren’t trying to hijack your phones. This is a case of the association between an ActiveSync device and the Exchange server going into its normal state. Feel free to click the “Activate” button….