Exchange 2016: Is RPCoverHTTP still needed?

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:

RPCoverHTTP 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:

UTM

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?

7 thoughts on “Exchange 2016: Wird RPCoverHTTP noch benötigt?”

  1. Derzeit funktioniert es nur mit der Option „Enable hot-standby mode“ unter der jeweiligen Site Path Route:
    Enable hot-standby mode: Select this option if you want to send all requests to the first selected real webserver, and use the other webservers only as a backup. The backup servers are only used in case the main server fails. As soon as the main server is back working, the sessions will switch back—unless you selected the Enable sticky session cookie option.

    Dass es auch im Loadbalancing sauber funktioniert behandelt Sophos als Feature Request und es nicht absehbar, wann daran weiter gearbeitet wird :-(

    Reply
  2. Hi Frank,

    danke für die Rückmeldung :-)
    Habe herausgefunden, dass es mit einem einzigen Exchange Server unter „real webservers“ funktioniert (auch mit Negotiate). Sobald ich einen zweiten dazuschalte klappt die Auth wieder nicht. Genau das selbe Problem hab ich auch bei OWA. Da kann man das Kennwort 1000x eingeben aber immer HTTP 401. Wohl ein Bug in der UTM.

    Gruß,
    Markus

    Reply
    • Hi Markus,

      mehrere Exchange Server als Real Server hinter der WAF funktioniert leider nicht. Soweit ich weiß, ist das schon mehrfach an Sophos als Bug gemeldet worden, aber leider immer noch nicht behoben.

      Gruß,

      Frank

      Reply
  3. Hi Frank,

    was hast du denn bei dir für AuthenticationMethods für das MapiVirtualDirectory konfiguriert, damit die Authentifizierung durch die UTM WAF geht? Wir haben bei uns nur Negotiate konfiguriert (als Internal und External AuthenticationMethods). Über die WAF akzeptiert Outlook aber das Passwort nicht und im Log der UTM wird ein HTTP 401 (Unauthorized) geloggt. Bei direktem Zugriff ohne WAF funktioniert MAPIoverHTTP einwandfrei. WAF Ausnahmen helfen leider auch nicht weiter.

    Danke und viele Grüße,
    Markus

    Reply
    • Hi Markus,

      meine Auth. Methoden:

      IISAuthenticationMethods : {Ntlm, Negotiate}
      InternalAuthenticationMethods : {Ntlm, Negotiate}
      ExternalAuthenticationMethods : {Ntlm, Negotiate}

      In meiner Umgebung funktioniert der Zugriff ohne Probleme (WAF ohne ReverseAuth).

      Gruß, Frank

      Reply
  4. Guter Artikel! Danke!
    Leider bleibt noch das Problem das Outlook 2013/2016 im MAPIoverHTTP-Modus und im Domänennetzwerk den User des öfteren mal nach den Zugangsdaten fragt. Das ist mir bei Verwendung von RCPoverHTTP bisher noch nie passiert und hält mich bisher von einer MAPIoverHTTP Nutzung ab, leider…
    Gruss

    Reply

Leave a Comment