RPCoverHTTP, better known as Outlook Anywhere, was introduced with Exchange Server 2003. RPCoverHTTP is used to connect Outlook to Exchange Server without a VPN, but it was not always easy to realize or implement.
Essentially, RPCoverHTTP tunnels the remote procedure calls via the http protocol to transport RPC over the Internet. The different protocols (RPC and http) caused a few problems. http is a half-duplex protocol, whereas RPC is a full-duplex protocol, which requires synchronous incoming and outgoing connections. Outlook therefore uses two http connections, one for incoming data (RPC_IN_DATA) and one for outgoing data (RPC_OUT_DATA). Firewalls and load balancers always had to route these two http connections of a client to the same target server (session affinity), as otherwise no connection could be established. Unfortunately, some firewalls and load balancers still don't get this right today.
The next problem concerns modern firewalls, which analyze the underlying protocol more closely in order to ward off attacks. These firewalls suddenly found not only the http commands (get, head, put, post) in the http protocol, but also remote procedure calls and cut the connection due to protocol anomalies or filtered the connection accordingly. The result was usually no connection to Exchange via Outlook Anywhere.
The MAPIoverHTTP protocol was introduced with Exchange Service Pack 1 for Exchange 2013. Unlike RPCoverHTTP, MAPIoverHTTP does not require remote procedure calls, which eliminates the disadvantages mentioned above. Since all current Outlook versions also support MAPIoverHTTP, you could consider switching off the classic Outlook Anywhere (RPCoverHTTP) and only use the modern Outlook Anywhere (MAPIoverHTTP). The firewall rules could be tightened again and the load balancers would no longer have to observe session affinity.
Here is an overview of the clients that support MAPIoverHTTP:
Source: Microsoft Technet
However, there is a small error in the image from the Technet article: Outlook 2007 is not supported by Exchange 2016 at all, regardless of the protocol. The Mac versions are left out here, because Outlook for Apple's operating system uses the EWS interface and is not dependent on RPCoverHTTP or MAPIoverHTTP.
Unfortunately, RPCoverHTTP cannot be switched on or off separately from MAPIoverHTTP. MAPIoverHTTP can be switched on and off for Exchange 2013 and Exchange 2016, for example. RPCoverHTTP is always active and cannot be switched off easily. Perhaps this function will be added later with a CU.
However, if you only use Outlook versions that understand MAPIoverHTTP, you could tighten the rules on your firewall considerably. A Sophos UTM Web Protection, for example, requires far fewer exceptions. I was able to tighten the set of rules so much that only one exception for "Static URL Hardening" remains:
With a new Exchange organization, you could also think about whether RPCoverHTTP is still needed. A complete article for the configuration of the UTM without RPCoverHTTP will follow.
How do you see the issue? Do you prefer MAPIoverHTTP? RPCoverHTTP? Or both?