Exchange 2013 SP1: MapiHttp
One of the major features of Exchange 2013 SP1 is codenamed “Alchemy”. “Alchemy” is Microsoft’s codename for the new MapiHttp communications mechanism in Exchange 2013 SP1. Before we can get into Alchemy, we first need to do a quick refresher on Microsoft Remote Procedure Call (RPC).
RPC is a decades old communications mechanism (not protocol) used by Exchange. RPC uses other transport protocols, like TCP, to establish communications channels between the client and the server. Once the communication channel is established, the client and server both use that same transport protocol to send RPCs to each other. For a more complete explanation of RPC, see THIS article on TechNet.
So why replace RCP over HTTP? The biggest problem with RPC is the large number of “moving parts”. If you skim through that article, you’ll see there is a lot of different things that have to happen correctly for RPCs to work. That means there are a lot of places for things to go wrong, and a lot of things to troubleshoot when things do go wrong. The other major problem is that RPC is decades old, and owned by the Server team. That makes support more difficult in “The Service” (Exchange Online).
For comparison’s sake, I have listed the two communication paths below.
RPC over HTTP
Application > Client Stub > Client Runtime Library > Client Transport > Server Transport > Server Runtime > Server Stub > Application
MapiHttp
Outlook > HTTPS > HTTPS > Exchange
The new MapiHttp protocol that is being introduced in Exchange 2013 SP1 and Outlook 2013 SP1 changes how Outlook connects to Exchange. Exchange (and Outlook) will no longer have to maintain those old and messy intermediary RPC components. Instead Outlook and Exchange will communicate directly using HTTPS. Outlook submits Remote Operations (ROPs) to Exchange to modify the mailbox. Alchemy does not change those ROPs, the ROP pipelines, or ROP buffers. Alchemy allows those ROPs to be communicated to the server without the need for all the additional RPC complexity, only the transport method of those ROPs is changed.
So the biggest benefit of Alchemy is simplicity. If there is one lesson I have learned in the last twenty years it’s that complexity is the enemy of availability.
Another benefit of MapiHttp is that it makes the process of establishing, and re-establishing in the case of short network interruptions, a session between the client and server much less resources intensive. Microsoft’s plan is that MapiHttp will give us the ability to exchange diagnostic information between the client and server using HTTP headers. This will, in turn, make the process of troubleshooting connection issues much easier. There is certainly great incentive for Microsoft to implement this change into Exchange Online, as client connectivity issues is one of their biggest support categories.
However, all this does not mean that as soon as you install SP1 to your Exchange 2013 servers you’re going to see improved server function and reliability. The new MapiHttp communication only works between Exchange 2013 SP1 and Outlook 2013 SP1. That means all the RPC components still need to exist on your Exchange servers until Outlook 2013 SP1 is the oldest supported client that connects to your Exchange servers, unless Microsoft adds MapiHttp support to Outlook 2010 in a future update. While it is expected that MapiHttp will reduce the workload on Exchange 2013 servers, thus allowing more and/or larger mailboxes on the same hardware, Microsoft does not currently have any data to support that.
One additional thing to note is that RCP over HTTP provides some benefits today because of a long-lived connections. This means that RCP over HTTP is expected to produce fewer auth requests than MapiHttp. Microsoft believes that this overhead will be negated by the other gains provided by MapiHttp, but as of this writing we just don’t have enough data to support that clam. As of this writing, Microsoft does not have guidance on the resource usage changes that Alchemy will cause on Exchange servers. This guidance is being produced now, and is expected to be public at some point in the fairly short-term future, though I have no idea what that means in real time.
So now the bad news. Remember how one of the big improvements in Exchange 2013 was that users no longer connect to a CASArray object, but to an individual GUID? That meant that once a user’s mailbox was moved to Exchange 2013, she would never again get that pop-up saying “An administrator has made a change to your mailbox, please close and reopen Outlook” Turns out, you’ve not see that pop-up for the last time. Switching communications methods is going to require restarting Outlook. In my testing during the TAP, I’ve had to restart Outlook multiple times after turning on MapiHttp before the change took effect. Users don’t like it when they get pop-ups, so I’ll be very careful about how and where I enable MapiHttp.
Another big problem with MapiHttp in TAP has been profile corruption. I didn’t have this problem myself, but it was reported by others. Again, this is a problem that will affect user experience and affecting user experience is not a great idea for people like me.
All-in-all I think MapiHttp will turn out to be a positive change for Exchange, but I personally don’t plan on rushing out and turning it on for all my customers. It’ll still be there in a few months, why not wait a while before flipping that switch?
Should you want to turn on MapiHttp, below are instructions on how to accomplish that task.
Enabling MapiHttp
The process to turn on MapiHttp is pretty simple. There is just one command to run after you upgrade all your Exchange 2013 server to SP1.
Set-OrginizationConfig –MapiHttpEnable $true
You can check is MapiHttp is turned on in your organization with this command
Get-OrgnizationConfig | FL *mapi*
Running the command to turn on MapiHttp can take up to 3 hours to fully take effect in your organization, and of course you Outlook clients need to be Outlook 2013 SP1 to use MapiHttp. Once MapiHttp is fully running in your environment, your Outlook 2013 SP1 clients will discover it through AutoDiscover.