Last Update: Sep 04, 2024 | Published: Nov 15, 2016
Microsoft released MAPI over HTTP (the “Alchemy” project) as part of Exchange 2013 SP1 in May 2014. Well before that time, MAPI over HTTP had been running inside Office 365 to shake down the new protocol before it was released to on-premises customers. The replacement for the long-established RPC over HTTP (aka “Outlook Anywhere”) protocol, MAPI over HTTP is designed to accommodate the demands of modern networking environments where devices hop from network to network and seamless mobility is everything.
The natural conclusion for the process has now come to pass. Microsoft is giving Office 365 tenants almost a year’s warning that RPC over HTTP connections will not be supported for Exchange Online after October 31, 2017. Outlook Anywhere is heading for the rubbish heap, but only for Office 365 as on-premises Exchange will continue to support this venerable protocol.
When you consider what’s happening, the process seems fair. Outlook Anywhere was designed to transport the Remote Procedure Calls (RPCs) used by Outlook desktop clients across an internet connection. Only HTTPS needed to be enabled for firewalls and no VPNs were necessary.
When it was released, Outlook Anywhere was an immediate hit, especially when used with the then-new Outlook 2003 client and its “drizzle mode synchronization.” The protocol, client, and growing availability of Wi-Fi networks made mobility a reality for many and released users from the need for tiresome dial-up connections and extended synchronization sessions.
That was some thirteen years ago. When you consider what’s happened since, especially in the areas of mobile devices and networks, a case can be advanced to change the default protocol used by Outlook to something more modern and discard a protocol designed for LAN connections.
Microsoft has a lot of experience with clients that are based on HTTP. Both Exchange ActiveSync (EAS) and Outlook Web App (OWA) clients use longstanding HTTP connections to communicate with Exchange. These connections don’t require the complicated handshaking used when RPC connections are made, which means that they work much better than Outlook over low-quality links.
According to Microsoft, MAPI over HTTP:
All sounds good. And MAPI over HTTP works and works well. I’ve been using it exclusively for the last two years and haven’t experienced any problems. That being said, Outlook desktop still remains the fat pig of Exchange clients and the new protocol does little to restrain the demands the client makes on network resources. If you’re in a network-constrained environment, such as using Wi-Fi on an airplane, OWA usually delivers a better user experience.
It’s easier for Microsoft to enforce change inside Office 365 than it is in the on-premises world. It controls all the necessary server upgrades (all of which are done) and can force tenants to upgrade clients to remain supported. Some work might be necessary to upgrade Outlook desktop software to one of the supported versions:
In all cases, clients should be updated with the latest patches. In particular, the December 2015 updates contain several important fixes to improve the stability and performance of MAPI over HTTP. These updates should be considered the baseline version for deployment. Outlook 2007 was never updated with MAPI over HTTP capability, so you won’t be able to use this client to connect to Exchange Online after the deadline. Microsoft has a useful Outlook Updates article that outlines the minimum version requirements for Office 365 and on-premises connectivity.
It is possible that some Outlook 2016 or Outlook 2013 clients might be blocking MAPI over HTTP connections. This is done by setting the MapiHttpDisabled registry key to 1 (one). Clients might have been configured for on-premises users to force the use of RPC over HTTP connections before their mailboxes were moved to Exchange Online and forgotten about since. The fix is easy (set the value to zero or delete it from the registry), but it’s wise to check before users start to report that they can’t connect on October 31, 2017.
No out-of-the-box method exists inside Office 365 to discover whether any Outlook clients need to be patched or updated. The Get-ConnectionByClientTypeDetailReport cmdlet tells you what users have used MAPI clients to connect to Exchange Online, but those MAPI clients can connect using either MAPI over HTTP or RPC over HTTP. Figuring out version numbers for clients that connect to Exchange is straightforward in an on-premises environment, but is more complex for Office 365 as Microsoft controls the required information. Curiously, although the Get-LogonStatistics cmdlet is available for Exchange Online, any attempt to pass it a mailbox identity fails.
Perhaps the new “Email clients used report” promised in the “What’s new in Office 365 Admin October 2016” post will provide all the necessary information. We shall see.
With respects to on-premises Exchange, you obviously have more control over when you upgrade both server and desktop software, so you can persist in using RPC over HTTP for as long as it’s supported. In some cases, software that can’t use MAPI over HTTP is supported for some time to come. Outlook 2007 leaves extended support on October 10, 2017 (one of the reasons why Microsoft never backported MAPI over HTTP to this client). Outlook 2010 lingers until October 13, 2020 and Outlook 2013 until April 11, 2023. This site provides a useful overview of support dates.
In some respects, this transition is simply an example of Microsoft changing the internal plumbing for the cloud. You shouldn’t have any concerns if modern clients are deployed. Some pain might be in prospect if ancient clients persist. Such is what happens with old (but still useful) software.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros,” the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.