A comment posted to my post wondering whether Apple’s release of iOS 6.1.2 would provide a long-term fix for the problem that causes excessive transaction log growth on Exchange servers (without introducing any new problems) asked a pertinent question:

“Maybe Microsoft could fix their ActiveSync protocol so this doesn’t happen again. This has been going on for YEARS now and Microsoft has simply shuffled the issue under the rug. The real cause of the issue is that ActiveSync has security bugs in it STILL after all these years. The fact that a client app can cause trouble for an Exchange server is indicative of a failure on the back-end services, which should handle the problem.”

I don’t believe that Exchange ActiveSync (EAS) running on Exchange 2010, Exchange 2013, or Exchange Online (Office 365) contains any security bugs that are known to compromise devices or force devices to behave strangely. At least, the current batch of iOS problems are not security related, unless you consider the imposition of excessive load by clients on a server to be a security bug. I can see how people might consider that a malfunctioning client could be a security concern, but it’s really not. Instead, I believe that the core issue is how can EAS provide a bullet-proof platform that cannot be compromised by misbehaving clients.

I’ve written before about the need for Microsoft to step up to the plate and take a more proactive stance with ActiveSync licensees. That article appeared when we were coping with the effect of the calendar hijacking problem, which seemed to have been knocking around since iOS 4. It’s hard to say that anything has really improved since October 2012, although I think the fact that Apple acknowledged an issue in the way that iOS interacts with Exchange is a positive step because it’s the first time that I can ever recall Apple admitting that the problem lies on their side. Indeed, the statement contained in Apple’s article that “the device may begin to generate excessive communication with Microsoft Exchange Server” is illuminating because it illustrates a problem that might continue even if Microsoft removes every single bug from the EAS code.

Exchange handles client connections using a number of protocols (HTTP, IMAP, POP, MAPI, EAS, and EWS). Even if the server implements its protocol stacks and code to handle connections perfectly, or as close to perfect as software engineering can ever achieve, the server is still exposed to a load generated by a client that runs amok. Think of what happens when a client sends data to Exchange to update a message (for example, set the status to Read) or calendar item (for example, accept a meeting request). These are transactions that have to be logged and recorded in a database. If all goes well, the client issues the relevant command, Exchange executes it, and a single transaction occurs. Or perhaps multiple transactions in certain instances, as in when a meeting request is updated and leads to messages being sent to inform attendees about the update. In any case, the number of transactions for specific client operations is predictable under normal circumstances. But if the client code is buggy, it’s possible that the simple flow of transactions to the server might become the “excessive communication” referred to in Apple’s article. And excessive communication leads to transactions, leading to transaction log accumulation and additional server load.

Another example of where ActiveSync clients behave in a way that can create an excessive load on servers is if they synchronize folders at short intervals. The logic here is that the client wants to make new messages and updates in the mailbox available to the end user as quickly as possible, so it continually checks with Exchange to determine if new mail has arrived or other updates have occurred. A client that synchronizes every minute is going to make sixty requests to the server every hour, something that might be acceptable if just a few clients are connected, but clearly a problem as you scale up to support hundreds or thousands of mobile devices. Think of how much worse the situation becomes if a client now attempts to synchronize every thirty seconds… or twenty seconds…

The server could, of course, attempt to recognize situations where a client is generating excessive load and terminate the connection, but the client could simply reconnect and start over. Exchange deals with this kind of problem with throttling policies that measure the load generated by clients and block connections when abnormal activity is detected. Although EAS incorporates comprehensive device access policies that can be deployed to block individual clients or complete families of clients, it’s not EAS that suppresses hyperactive clients. Instead this is done by the throttling policies operated by Exchange’s workload management.

I’m pretty sure that the Exchange developers are doing what they can to make sure that EAS behaves properly and doesn’t expose itself to client-initiated problems such as calendar hijacking. Fixes for these kind of issues will appear in the updates that Microsoft releases regularly for Exchange. But Microsoft faces a problem in that there are so many ActiveSync client applications running on devices that there’s no guarantee that a client might not expose a new problem at any moment. Apple does a good job of pushing out iOS updates to devices. And although there have been quite a few recently (iOS 6.1, 6.1.1, 6.1.2 and 6.1.3 coming soon), at least the updates are pushed out effectively via iTunes in such a way that a large percentage of devices in use run the latest version of iOS. The same situation does not pertain for Android clients.

At the end of the day, client-server systems can only work well when solid code runs on both platforms. It’s less complicated when a single company owns both clients and servers, which probably accounts for why you see fewer EAS problems with Windows Phone devices. But we live in the era of BYOD, a development that looks less attractive when clients run wild.

Even if Microsoft succeeds in making EAS relatively bullet-proof and also takes a more aggressive stance with ActiveSync licensees to make sure that their client code works as well as possible, I suspect that we will still have to be prepared to deal with client-provoked ActiveSync issues in the future (or on an ongoing basis, as some evidence suggests that the Exchange transaction log problem is not quite fixed in iOS 6.1.2).

If you accept that this is the case, you should acquaint yourself with the advice given in the very good “ActiveSync Troubleshooting Chalk Talk” session given by Austin McCollum of Microsoft Support as well as read up about how to manage iOS devices effectively when deployed with Exchange. Otherwise we might end up moving from BYOD meaning “bring your own device” to “bring your own disaster”.

Follow Tony @12Knocksinna

P.S. Following the news that LG has acquired webOS from HP to use in their “smart TV” platform, perhaps they’ll write a good ActiveSync client and show how it’s really done. Or maybe HP’s new Android-powered Slate 7 will include a properly functioning ActiveSync client. Just thinking…