Nothing to fear in MAPI over HTTP

Microsoft’s decision to move away from the time-honoured RPC interprocess connection mechanism and replace it with a new approach where Outlook clients can use a new protocol called MAPI over HTTP to connect to Exchange 2013 SP1 has caused a bit of fuss and bother. On reflection, this is a pretty normal situation in the technical sphere where, even though technologists might like to think of themselves as being open to change, transitions of this nature are sometimes unwelcome because of the fear, doubt, and uncertainty that the unknown generates. 

It wasn’t for nothing that IBM was famous for the ability of their salesforce to use FUD to influence customer discussions for years; so much so that buying the nice safe choice became a well-accepted practice. But that is long ago in the past and we’ve moved on since then. Or so you would hope.

Apart from a general desire for more information about performance and sizing versus RPC over HTTP. Microsoft has posted some initial advice but we await a more definitive assessment based on real-life customer deployments. The biggest issue I've seen is that MAPI over HTTP doesn't support connections to legacy public folders in Exchange 2013 SP1. The fix for this problem is included in Exchange 2013 CU5. Another known issue is that the archive belonging to a shared mailbox can't be accessed by Outlook over a MAPI over HTTP connection. Work is still ongoing on this issue, but I imagine that it has limited impact.

Some might be surprised that legacy public folders were unsupported for MAPI over HTTP in SP1. However, a heap of complexity exists in sorting out all the situations where clients would connect to Exchange 2013 SP1 for their mailbox and OAB (and perhaps some shared and site mailboxes) and then need a connection proxied to Exchange 2010 or 2007 for legacy public folders. In all honesty, I don't see having to wait until CU5 was released as making a heap of difference because it's likely that companies will have completed their migration (dirty as it is) to modern public folders before they have rolled out Outlook 2013 SP1 and be ready to switch over to MAPI over HTTP. 

Until the release of KB2899591 (December 12, 2014), which allows Outlook 2010 clients to use MAPI over HTTP, being forced to update all clients to use Outlook 2013 SP1 (including any hot fixes available for Outlook 2013 SP1) was the biggest pain point for most people in moving to the bright new world of MAPI over HTTP connectivity (or perhaps a rather old world, as really it’s Exchange and Outlook that are losing a mechanism designed for LAN networks). Butremember that once you switch every client to Outlook 2013 SP1, you still have to make an organization-wide configuration change to make Exchange update Autodiscover so that the clients learn that they can speak HTTP to Exchange.

Some Office 365 tenants who have updated to the latest version of Outlook have already moved across to MAPI over HTTP and the reports about the protocol's stability and performance are good. The rest of Office 365 will be moved over gradually as client updates permit. 

Older clients will work just fine for now and will connect to Exchange 2013 SP1+ without an issue. The "for now" piece in the last sentence is my wonderfully ambivalent or non-specific term that means “Microsoft is likely to switch over and require all clients to connect to Exchange via MAPI over HTTP in the future, but an awful lot of customers run an awful lot of older Outlook clients and that’s not going to change fast.” It will take time for the installed base to get to a point where it will be possible for Microsoft to be able to force such a change so I don't anticipate it happening soon.

We have been through a similar transition before when UDP support was initially discontinued in Exchange 2010, which caused older Outlook clients to stop working. Microsoft was forced to bring back UDP support as otherwise customers would not move to Exchange 2010. But you might have noticed that UDP support is missing in Exchange 2013...

“Exchange 16”, the next release of the product, is in the design and early coding phase at present. It is expected to show up sometime towards the end of 2015 and it is possible that Microsoft might use it as the opportunity to make the transition to MAPI over HTTP as the sole connection mechanism, much as they used Exchange 2013 to remove RPC over TCP/IP. Although we don’t know if this will be the case. I suspect that a strong possibility exists, especially because it would be a neat way to remove some complexity from support and design scenarios. Some indication of future directions might be seen in the decision to make two-factor authentication for Outlook only available when using MAPI over HTTP. However, on-premises won't get this capability for some time yet as multi-factor authentication will be supported in Office 365 first.

Of course, Office 365 tenants don’t ever get to vote about what happens behind the scenes. Microsoft has rolled out MAPI over HTTP pretty broadly but its deployment is gated by client support. Now that Outlook 2010 can connect, the use of MAPI over HTTP should become much more widespread. 

The content presented by Microsoft's Joe Warren at their 2013 Plugfest event explains some of the advantages gained in the transition to MAPI over HTTP, especially when computers "hop" from network to network, change the adapter used (for instance, from Ethernet to Wi-FI), or resume after hibernation. When you think about it, these are very common operations in today's work environment and it makes sense to use mechanisms that are fit for purpose, which is basically the case advanced by Microsoft to justify the change. These messages were reinforced in the MEC session "Outlook Connectivity: Current and Future", the recording and presentation for which should be available for download as you read this.

On a more esoterically technical level, I’ve also heard complaints that Microsoft did a dumb thing when they created MAPI over HTTP. Apparently, a much better idea would have been to make Outlook use Exchange Web Services (EWS), just like Outlook for Mac 2011 does.

Everyone is entitled to their opinion (and I certainly take maximum advantage of that liberty in this blog) but I think those who hold this opinion are plain wrong. First, Outlook for Mac 2011 is a sad and faded client when compared to Outlook 2013. There are just so many things that don’t work as well in the Mac version as they do in Windows, a fact that is drummed into my head several times a week by my wife, who mostly enjoys using Outlook on her MacBook Air. EWS is not as functional (yet) as MAPI. End of story.

But it’s also true that replacing RPC over HTTP with MAPI over HTTP is much simpler at the architectural and code level than having to rip out all the MAPI code and rewrite it using EWS. The same Plugfest featured a short introduction to how Outlook 2013 SP1 uses the WinHTTP interface (a high level interface to the HTTP 1.1 protocol) to transport Outlook’s ROPs (Remote Operations invoked by MAPI calls) to Exchange. It seems very much like Outlook has been able to replace RPC with WinHTTP in a very elegant and smart manner and so avoided the need for wholesale code updates scattered across the product.

If you decide that MAPI over HTTP is not for you, it can be blocked by updating the system registry to create a new DWORD value under KEY_CURRENT_USERSoftwareMicrosoftExchange. Set the value of MapiHttpDisabled to 1 and Outlook 2013 SP1 clients will forget all about MAPI over HTTP and keep on using good 'ol RPCs.

To close on a note of caution, we are very much in the early days of this particular transformation. Expect some bumps along the way before MAPI over HTTP is as well-known and as well-supported as its predecessor. Performance and sizing information is still unavailable and the experience gained through field deployments doesn't exist. These things will come in time (Microsoft is working on the performance and sizing documentation) but I would pause to consider before diving in to be the first to move a large on-premises deployment over to use MAPI over HTTP.

One example of a MAPI over HTTP bump is seen in the issue described by a UK company who couldn't get their Outlook 2013 SP1 clients to connect to Exchange 2013 SP1 (on-premises). Some good detection work established that Outlook uses the IE proxy server settings when they attempted to connect to Exchange. If the proxy settings were disabled, Outlook would connect - but no other web access was available (not a good thing). The solution is to add every Exchange 2013 Client Access Server to the proxy exception list to force Outlook to connect to a CAS without attempting to go near a proxy. Each CAS has to be specified in the format ; ;. For example:

10.0.0.1;ExCAS1;ExCAS1.contoso.com

Clearly this is not a good thing and the Exchange engineers are looking into the problem to come up with a better fix than having to update IE settings on all client machines.

Like everything else, time will bring familiarity and wisdom. On-premises customers will not be in a hurry to deploy MAPI over HTTP because of the need to upgrade client desktops. Until they do, I suspect that Microsoft will gain a lot of experience internally and from “the service” that will allow them to slipstream bug fixes and improvements into future cumulative updates. The FUD will have cleared by the time the bulk of on-premises customers are ready to embrace MAPI over HTTP and we’ll all be much happier. At least, I hope so.

Follow Tony @12Knocksinna