Windows Phone and Exchange ActiveSync: What you need to know

The iPhone and Android provide more EAS security than Windows Phone 7 does, but you may still be able to support Microsoft's smartphones

Last week I explained why I couldn't "love" the Windows Phone from an enterprise perspective. On a personal level, I do love the smartphone, which offers a much more polished experience than my previous Android device. But that nicer interface doesn't address the issue Windows Phone poses to enterprises, which is its poor support of Microsoft's own Exchange ActiveSync (EAS) policies.

EAS is an essential part of Exchange and, soon, Microsoft System Center 2012. Being able to control your messaging environment lets you protect your organization and maintain compliance with regulatory requirements. The various EAS policy settings are what enable that protection and compliance. When a company like Apple or Google creates an OS lacking some of the EAS policy settings, you can almost understand it. But with Microsoft having control of both the mobile OS (in the case of Windows Phone) and of Exchange Server, its smartphone should be able to support every single EAS setting.

[ Learn how to manage mobile devices in InfoWorld's 20-page Mobile Management Deep Dive PDF special report. | Stay abreast of key Microsoft technologies in our Technology: Microsoft newsletter. ]

In fact, both Apple and Google provide more EAS support in their mobile OSes than Microsoft does. An iPhone or Android smartphone should never have an EAS capability that a Windows Phone smartphone doesn't have -- period.

Some people have excused Microsoft's poor EAS support by saying Windows Phone was designed for the consumer side, but that argument is absolutely meaningless. OK, so Windows Phone is designed primarily for consumer use, but it should still be operational in the enterprise -- just like the consumer-oriented iPhone and Android are. If a user doesn't access business email, then the EAS capabilities would do no harm, but if the user did want to connect to the business email, the EAS policy support would be there to allow it -- plain and simple.

Fortunately, it's gotten a little better. The 7.5 "Mango" release of Windows Phone last fall added several new policies, so Microsoft knows it is falling short on the EAS front. Furthermore, it's acknowledged one of the big enterprise omissions in Windows Phone 7 -- on-device encryption -- will be addressed in new devices that run the Windows Phone 8 "Apollo" OS expected in November. (Blog reports have indicated that Microsoft will add Windows' BitLocker encryption technology to Windows Phone 8.)

Which EAS policies each Exchange version supports
Let's take a quick look at each flavor of Exchange and see to what degree of EAS each supports. Because many organizations are still using Exchange 2003, they should know whether Windows Phone will support the EAS policies they can enforce in those environments. Microsoft tends to focus on just what its latest versions can do, but there's a great comparison of EAS client capabilities on Wikipedia. Here is what each version supports:

  • Exchange Server 2003 and EAS 2.5 have only a handful of features available, including remote wipe, direct push, and SSL-encrypted transmission. Windows Phone 7.5 supports all these EAS features.
  • Exchange Server 2007 (including Service Pack 2) and EAS 12 add several key policies, including on-device encryption and the ability to disable the camera, removable storage, infrared (IR) port, text messaging, Wi-Fi, Bluetooth, browsers, and a host of other features that may be necessary for your environment to meet regulatory compliance. Although Windows Phone 7's predecessors -- Windows Mobile 6.1 and 6.5 -- support all these features, Windows Phone 7.5 supports none; theoretically, you can disable IR, removable storage, and Internet sharing, but they don't seem to actually work. Of course, because only one Windows Phone 7 device (a Samsung Focus model) even has removable storage -- encrypted and locked to the device -- the lack of a removable-storage disablement policy is no problem.
1 2 Page 1