I was delighted to learn that RIM is preparing BlackBerry Enterprise Server (BES) to support Exchange 2013. The version that will be supported alongside Exchange 2013 is BES 5.0 SP4, with the caveat that support will first be available for “pure” Exchange 2013 environments (I think there will be relatively few of these deployments) and then for mixed-mode, meaning including Exchange 2010 and Exchange 2007. An updated version of the MAPI/CDO download will be required to allow BES to interact with Exchange 2013. That download is not yet available.
The same announcement covered BlackBerry Mobile Fusion and BlackBerry Enterprise Server 10, which use ActiveSync instead of RIM’s own protocols. The fact that RIM uses ActiveSync for some of its products is testimony to just how far ActiveSync has evolved.
A long time ago (at least in the last century), the first stirrings of ActiveSync were known as “AirSync,” a capability first shipped as part of Microsoft’s Mobile Information Server (MIS) product. MIS was sold in two versions, one to commercial customers and another to mobile phone operators, but was popular with neither target community. After the MIS project was wound down, Microsoft decided to incorporate AirSync into Exchange 2003 in an attempt to gain a competitive advantage over RIM, who were at that time the preeminent provider of mobile email services to Exchange customers.
Alas, the initial ActiveSync implementation in Exchange 2003 was not successful. One immediate issue was that the protocol was very chatty in comparison to RIM. Customers didn’t like this because they clocked up higher data charges to receive the same volume of email. Operators didn’t like it much either because they valued transmission efficiency highly as chatty clients can become a real problem when the number of devices scale up into the hundreds of thousands. The operators certainly gain a benefit by being able to charge more for all the data consumed, but they have to pay for the initial investment to build out the necessary infrastructure first. A chatty protocol is a technical problem that can be solved through tweaking over time, but investing billions in cellular infrastructure is an up-front issue that makes accountants go weak at the knees.
The way Exchange 2003 notified clients about new messages posed a bigger problem. Each time a new message arrived, Exchange would send an SMS message to the mobile device. Apart from the kludgy nature of the solution (called Always Up to Date or AUTD), it is only feasible when operators charge little or nothing for all the SMS messages that they were required to transport for new mail notifications. And when operators charge for SMS messages, users end up with large bills (maybe 5 cents per SMS) for each message notification, which didn’t seem like a good idea. Receiving a prompt to synchronize might have worked but it was not a success.
Exchange 2003 SP2, shipped in March 2005, changed everything with a solution largely similar to what is used today. SMS notifications disappeared in favour of HTTP transactions and some improvement was made in data consumption. These changes, along with the very important point that ActiveSync, or EAS, is provided as part of the Exchange product and is therefore free to customers insofar as no need exists to buy a heap of additional licenses before devices can connect to Exchange via EAS, as you have to do with RIM. Once companies realized the economic benefit of the EAS solution and Microsoft and mobile vendors began to ship functional devices (really from Windows Mobile 6 onwards), the tide began to turn against RIM. Like King Canute, RIM still struggles with that incoming tide today.
Microsoft often represents EAS as a “direct push” protocol. In other words, that the server “pushes” new messages to clients as soon as they arrive. In fact, this position is marketing speak that has been in place since the days when Microsoft and RIM started to battle for dominance in the mobile device space. RIM’s great advantage has always been its total control of the end to end transmission to the device, something that enables it to push new messages to BlackBerry devices as quickly as the messages can be processed by a RIM Network Operating Centre (NOC). Getting new messages fast was extremely important to many of the early adopters such as financial traders and analysts. Those of us who don’t quite function at a point where a few seconds make much difference might have a different view.
The choice of HTTP enabled great flexibility for EAS. However, HTTP is not a protocol specifically designed to maintain connectivity between mobile devices and servers. A method had to be established that allowed Exchange to send messages to mobile devices relatively quickly within the constraints of HTTP. The chosen option allows clients to register their interest in folders on the server, and then create a “long-lived” HTTP request that will expire after a heartbeat interval (usually between 10 and 15 minutes). The server notes the request and then waits for the heartbeat to elapse. If no new messages have arrived, the client simply sets up a new HTTP request with the server. However, if a new message is delivered, the server notifies the client by “breaking” the heartbeat and responding with some data to tell the client what’s happened. It is then up to the client to respond by fetching the new data from the server. This is what’s kind as an EAS “Ping” implementation, the type used by Apple iOS devices among others.
Windows Phone clients use a slightly different mechanism called “hanging Sync.” The big advantage gained is that devices receive new message data along with the notification, which speeds up delivery of messages. The technique is closest to a direct push implementation and works well, albeit perhaps still not as quickly as RIM, but well enough in the majority of cases.
RIM has had plenty of problems in the recent past. I’m sure that a loyal installed base of BlackBerry zealots still exists, but I do wonder how long they will last in the face of the EAS juggernaut.
Learn how to control user and device access to EAS in Paul Robichaux's "Managing Exchange ActiveSync Policies in Exchange 2010."
Follow Tony @12Knocksinna