Last week I explained why I couldn't 'love' the Windows Phone from an enterpriseperspective . On a personal level, I do love the smartphone, which offers amuch more polished experience than my previous Android device. Butthat nicer interface doesn't address the issue Windows Phone posesto 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 protectyour organization and maintain compliance with regulatoryrequirements.
The various EAS policy settings are what enable thatprotection and compliance. When a company like Apple or Googlecreates an OS lacking some of the EAS policy settings, you canalmost understand it. But with Microsoft having control of both themobile 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 technologiesin 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'thave -- period. Some people have excused Microsoft's poor EAS support by sayingWindows Phone was designed for the consumer side, but that argumentis absolutely meaningless. OK, so Windows Phone is designedprimarily for consumer use, but it should still be operational inthe enterprise -- just like the consumer-oriented iPhone andAndroid are.
If a user doesn't access business email, then the EAScapabilities would do no harm, but if the user did want to connectto the business email, the EAS policy support would be there toallow 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 isfalling short on the EAS front. Furthermore, it's acknowledged oneof the big enterprise omissions in Windows Phone 7 -- on-deviceencryption -- 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' BitLockerencryption 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 whatdegree of EAS each supports. Because many organizations are stillusing Exchange 2003, they should know whether Windows Phone willsupport 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 featuresavailable, including remote wipe, direct push, and SSL-encryptedtransmission. Windows Phone 7.5 supports all these EAS features.
Exchange Server 2007 (including Service Pack 2) and EAS 12 addseveral key policies, including on-device encryption and theability to disable the camera, removable storage, infrared (IR)port, text messaging, Wi-Fi, Bluetooth, browsers, and a host ofother features that may be necessary for your environment to meetregulatory 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, butthey don't seem to actually work. Of course, because only oneWindows Phone 7 device (a Samsung Focus model) even has removablestorage -- encrypted and locked to the device -- the lack of a removable-storage disablement policy is noproblem.
