Microsoft’s Exchange ActiveSync protocol (EAS) is one of the best things to come out of the efforts to extend Exchange beyond a purely Microsoft ecosystem. Sure, Windows phones use EAS to connect to Exchange, but Microsoft licenses the protocol to anyone who wants to use it in their products, so customers can use iPhones (as well as iPads and iPods) or Droids, and starting with the next generation operating system, even BlackBerries. Yes, RIM has decided to put an end to the need for BES and will be using EAS as the native protocol starting with version 10 of their O/S.
While Microsoft did make the choice to license EAS to other manufacturers, they did not choose to implement a strict set of requirements for it, and there is no “Certified to work with EAS” program. As such, vendors are left to their own devices when it comes to how, or even how much, of the EAS specification they wish to embrace, and that has led to a number of problems over the years. In this first part of our series on troubleshooting EAS, let’s look at some light background and a couple of useful resources.
Many of you may be familiar with the problem Exchange admins had when first looking to extend EAS to iPhone users. Their security policy may have required that all mobiles devices support encryption. The iPhones didn’t but the implementation of their EAS client told Exchange that they did, so they were deemed compliant with policy and allowed to connect. That’ what I call cheating.
Some customers of cloud based services are finding challenges when trying to support phones running Google’s Android operating system. Again, vendors are left to their own to decide just which parts they want to use and which they don’t, and some made the assumption that email address and User Principal Name are the same. For most customers that might be safe, but for others, that’s not the case, and if your mail provider is Office 365 or one of the other cloud based providers, you have a problem. Users must authenticate using their UPN, and if it doesn’t match their SMPT address and the particular Droid they are using doesn’t expose one field for SMTP and another for UPN, they are not going to be able to authenticate.
There are other issues with third party Exchange ActiveSync clients, and when you need to troubleshoot them, there are two great resources you want to have close at hand.
The first is a KB article you want to bookmark and refer to whenever you are dealing with a potential ActiveSync issue. Microsoft KnowledgeBase article 2563324 is one of the few KBs that will see frequent updates. In its 21st update so far, “Current issues with Microsoft Exchange ActiveSync and third-party devices” lists all the known issues third party implementations of EAS have with the currently supported versions of Exchange. Before you spend any time troubleshooting an ActiveSync client beyond confirming username and password, refer to this article to see if you are dealing with a known issue. Note that in most cases where you are, you will need to look to the device manufacturer for resolution.
The second is an article on Wikipedia that even Microsoft will refer you to if you have questions regarding EAS. The article “Comparison of Exchange ActiveSync clients” is basically just a table of all the major EAS client implementations that are out there that clearly shows you what features are or are not available for a particular implementation with a specific version of Exchange. It’s a great place to go if you are considering a particular device, and maximum compatibility with EAS is going to be a factor in your decision.
In the next part of this mini-series, we’ll take a look at some tools for better/deeper troubleshooting of EAS. Stay tuned.