Service Pack 1 for Exchange 2013 includes a new protocol for communication between Outlook and Exchange: MAPIoverHTTP. Previously, MAPIoverHTTP was only supported by Outlook 2013 with SP1 and Exchange 2013 SP1. Therefore
How does MAPIoverHTTP work?
With Service Pack 1 for Office 2013 and MAPIoverHTTP activated, Exchange now knows 2 protocols to communicate with Outlook. Previously, the protocol used was RPCoverHTTP, which was already used with Outlook Anywhere. Since Exchange 2013 RTM, RPCoverHTTP has also been used as the standard for the internal connection from Outlook to Exchange.
In contrast to RPCoverHTTPS, MAPIoverHTTP works without RPC calls. I have created the following graphic to illustrate how it works:
On the left you can see in simplified form how RPCoverHTTP works. Outlook wraps the RPC calls in HTTPS and sends them to the Exchange server, the Exchange server in turn has to unpack the RPC calls from the HTTPS connection in order to process them. With Exchange 2010, Outlook could also communicate directly with Exchange via RPC.
The difference can now be seen on the right: RPC communication is completely eliminated. Outlook communicates directly with the Exchange server via HTTPS. I will go into the advantages of this communication later. Here we will first look at how it works.
The IIS directory /RPC was used for RPCoverHTTPS. The /MAPI directory has been added for MAPIoverHTTP. The directory is created with the installation of Service Pack 1 for Exchange 2013
The MAPI directory can be configured and displayed via the Exchange Management Shell:
Get-MapiVirtualDirectory -Server EX1
'
The configuration parameters are similar to those for RPCoverHTTPS, there are essentially internal URLs, external URLs and the authentication settings.
The Exchange organization now also has a new parameter, here MAPIoverHTTP is still switched off:
Get-OrganizationConfig | fl name,mapi*
Outlook finds out whether it can use MAPIoverHTTP via Autodiscover.
This means that no settings need to be changed manually on the Outlook client, although Outlook does request a restart when MAPIoverHTTP is activated.
Advantages of MAPIoverHTTP
The advantages of MAPIoverHTTP are quickly explained: MAPIoverHTTP does not have the disadvantages of RPCoverHTTP. With RPCoverHTTP, an RPC connection had to be tunneled via the HTTP protocol, which led to a few problems:
- Not all firewalls understand RPCoverHTTP
- If the connection is lost, the RPC connection must also be terminated
Notebook users are particularly familiar with the second point. In the office, Outlook is not closed, but the notebook is simply plugged in quickly, you arrive at the customer and Outlook takes what feels like an eternity to re-establish a connection to the Exchange server.
MAPIoverHTTP therefore has the advantage that it works regardless of the location or type of connection, as RPC connections do not have to be terminated and re-established. Most firewalls with content inspection probably also wave the connections through as "normal" HTTPS traffic 
but I haven't tested that yet.
How is MAPIoverHTTP activated?
As already mentioned, MAPIoverHTTP (as of 03.2014) can currently only be used with Exchange 2013 SP1 and Outlook 2013 SP1.
Setting up MAPIoverHTTP is simple: configure internal and external URL, switch on, done.
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl "https://outlook.frankysweb.de/mapi" -ExternalUrl "https://outlook.frankysweb.de/mapi" -IISAuthenticationMethods Ntlm, OAuth, Negotiate
The command above configures MAPIoverHTTP to the URL outlook.frankysweb.org. I select the same configuration here as for Outlook Anywhere (RPCoverHTTPS). In my case, "outlook.frankysweb.org" is the VirtualService of the load balancer. The host name must be present on the certificate.
Now all that remains is to activate MAPIoverHTTP:
Set-OrganizationConfig -MapiHttpEnabled $true
Whether the connection is established with MAPIoverHTTP or RPCoverHTTP can be determined on the Outlook client. Here first a connection via RPCoverHTTPS:
And here via MAPIoverHTTP:
Important: Outlook requires a restart when MAPIoverHTTP is activated:
What options are there for error analysis?
Probably the easiest way to test the function of MAPIoverHTTP is to call up the Healthcheck page. However, this does not test much more than the IIS server:
The test Outlook CMDlet, which can be executed using the following command, goes a little further:
Test-OutlookConnectivity -RunFromServerId EX1 -ProbeIdentity OutlookMapiHttpSelfTestProbe
However, the logfies are the most informative:
- C:\Program Files\Microsoft\Exchange Server\V15\Logging\MAPI Client Access
- C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Mapi
It remains to be seen what problems will arise with MAPIoverHTTP.
Hallo,
Zuerst einmal ein großer Dank an Frank für die vielen tollen und vor allem hilfreichen Artikel.
Wir haben die Migration von 2013 nach 2019 abgeschlossen. Lief eigentlich ganz gut. Nun stehen wir vor der Officemigration (2013 nach 2021)
In der Testphase Outlook 2021 auf den Ex2019 stellten wir fest, dass die Performance des Outlook absolut schlecht ist. Das ist niemanden zuzumuten. Wir haben mal den Reg-Wert MapiHttpDisabled am Client gesetzt. Alle Verbindungen laufen nun wieder über RPC und endlich performant.
Hat jemand ähnliche Erfahrungen gemacht?
Grüße in die Runde
Andreas
Hallo
Ich hatte im Zuge der Migration von Exchange 2013 auf 2019 ein Problem bei der Aktivierung von MAPI over HTTP – vielleicht hilft es ja jemand:
Ich wollte eigentlich, wie im Migrations-Artikel empfohlen, vor der Installation des 2019ers schon MAPIoHttp aktivieren. Hier hatte ich dann auch das Problem, dass Outlook nach Login fragt. Ich hatte es dann erst mal nochmal deaktiviert um mir das genauer anzuschauen und ggfs. die User vorzuwarnen.
Ich meine, dass es mir im EAC bei den virtuellen Verzeichnissen auch keines für MAPI angezeigt hat, im IIS war es vorhanden.
Ich habe dann doch den neuen Exchange installiert und konfiguriert – dann war auch für den alten Exchange ein MAPI-Verzeichnis da. Gestern Abend habe ich MAPI o. H. aktiviert und anscheinend hat es jetzt problemlos geklappt – bisher keine Meldungen von Usern.
Viele Grüße,
Alex
Hallo Zusammen,
ich bin gerade noch über ein „Problem“ gestolpert für Firmen die einen Proxy eingetragen haben im Internet Explorer. Gibt es einen Bug der ist zwar für Outlook 2013 und höher behoben.
Bei Office 2010 wohl nicht
Siehe diesen KB Eintrag
https://support.microsoft.com/en-us/help/2986802/outlook-2013-cannot-connect-to-exchange-server-2013-or-exchange-server
Hallo zusammen,
großes Lob für Deine Arbeit !!!
Habe ich das richtig verstanden, dass RPC und MAPI parallel betrieben werden können? Habe noch vereinzelt Outlook 2010, 2013, 2016. Die Server migriere ich gerade von 2013 (Mapi disabled) auf 2016 (Mapi enabled). Erkennt der Client (Outlook 2010) automatisch, dass er kein Mapi kann und nutzt dann weiterhin RPC?
Viele Grüße
Hallo Stefan,
ja, ein Client der kein MAPI unterstützt, verwendet weiterhin RPC. Du kannst es parallel betreiben. Allerdings unterstützen alle Outlook Versionen ab Outlook 2010 (mit Patch) MAPIoverHTTP. Auch Exchange 2013 unterstützt MAPIoverHTTP, du kannst es also bereits jetzt nutzen.
Gruß, Frank
Hallo Frank, vielen Dank für die schnelle Antwort. Und an dieser Seite mal ein riesen Lob und großen Dank für diese fantastische Seite. Ich bereite gerade den ersten Exchangeserver vor, den ich für meine Firma einrichte und diese Seite ist eine meinerwichtigsten und hilfreichsten Quellen.
Und falls es nicht zu sehr nervt noch zwei Fragen zum Thema MAPI:
Wir verwenden in der Firma fächendeckend noch Outlook 2010 und Exchangeserver 2013. Habe ich es richtig verstanden, dass auf den Outlooks MAPIoverHTTP eigentlich nur mittels Autodiscover aktiviert werden kann? Manuell kann ich ja nur RPCoverHTTP konfigurieren. (Autodiscover ist ja aber dank deiners fantastischen Whitepapers kein Problem und funktioniert bereits)
Und noch eine Frage zur Nutzung der Powershell, die ich vorher kaum genutzt habe, aber in Verbindung mit Exchange ja fast Pflicht wird: Ich sehe hier oft eine Kombination mit GET- und SET- Befehlen die über eine Pipe verbunden sind. z.B:
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl „https://….
Warum wird hier nicht einfach nur der SET-…. Befehl verwendet?
Nochmals vielen DANK für deine Seite und dafür, dass Du dich so ausführlich den Fragen Deiner Seitenbesucher widmest. Oliver
Hi Oliver,
danke für das Lob. MAPIoverHTTP lässt sich für alle Outlook Versionen nur mittels Autodiscover konfigurieren. Bezüglich der PowerShell, du kannst auch nur den „Set“ Befehl verwenden, musst dann aber ggf. weitere Parameter angeben. Einfacher und meistens sicherer vor Schreibfehlern ist es, sich erst das Objekt zu holen (Get) und dann zu verändern (SET). Auch lässt sich mittels GET/SET Kombination mehrere Objekte verändern, als Beispiel:
set-mailbox A …
set-mailbox B …
set-mailbox C …
oder:
get-mailbox | set-mailbox
Gruß, Frank
Hallo,
ich habe zwei Fragen zu MAPIoverHTTP.
1. bei RPCoverHTTP hatte ich als Authentifizierungsmethode im Client die Standardauthentifizierung gewählt. Ist das bei MAPIoverHTTP nicht mehr gewünscht? Was ist hier die Beste Einstellung?
2. Es gibt ja eine InterneURL und eine ExterneURL. Wann wird die interne und wann die externe URL verwendet? (Frage gilt auch für andere Dienste wie OWA usw.)
Oliver
Hi Oliver,
zu 1) ich würde für MAPIoverHTTP NTLM oder Aushandeln (Standard, NTLM bevorzugt) als Authentifizierungsmethode wählen. Alle Clients die MAPIoverHTTP sprechen unterstützen NTLM.
zu 2) Outlook versucht zunächst die interne Adresse zu erreichen, wenn diese nicht erreicht werden kann, wird die externe Adresse benutzt.
Gruß, Frank
Bei mir funktioniert die Verbindung per ExRCA gut, bis zu „Testing HTTP Authentication Methods“. Hier wird eine andere URL aufgerufen – die interne. Die kann aber von extern nicht aufgelöst werden. Daher schlecht OA von extern fehl.
Hallo, obwohl bei mir alles OK scheint (laut powershell cmd-let) bekomme ich keine Bestätigung (200OK) beim Healthcheck für MAPI hin. OWA, ECP erreiche ich sowohl intern als auch extern. Auch das Test-Outlook…. wird ohne Fehlermeldung abgeschlossen. Kann es sein das die Sophos UTM da was blockiert?
Super Anleitung wie immer.
Ich habe jetzt nur folgendes Problem. Nachdem ich alles Schritt für Schritt ausgeführt habe kommt an den Clients ständig eine Abfrage nach den Zugangsdaten (Benutzername und Passwort).
Woran kann das liegen?
Hallo Aslan,
ja das Problem kennen wir auch. Obwohl wir eine lokale, also eine On-Premise-Installation haben, haben wir auch die Office365-Lizenzen. Über die Office365-Lizenz haben wir erfahren, das unsere Domänen-Anmeldename gleich der E-Mailadress-Domäne sein muss, damit man eine AD-Sync machen kann.
Das hat jetzt noch nichts mit Deinem Problem zu tun –
Grundsätzlich gilt aber auch bei einer On-Premise-Installation die korrekt mit Autodiscover z.B. owa.domänenname.de eingerichtet wurde, auch die AD-Konten als Anmeldefeld diese „domänname.de“ haben sollte und NICHT den internen Domänenname wie „intern.local“ oder so.
Bei neuen Benutzern sollte man das übrigens dann auch machen, weil die per Default mit dem „intern.local“ angelegt werden und das PopUp-Fenster wieder kommt, was man dann auch nicht wegbekommt.
Danach sollten so ziemlich alle Anmeldefenster verschwinden… bitte auch mal prüfen ob das Autodiscover richtig eingerichtet ist und die Namen per DNS Aufrufbar sind, u.a. vom Server/Client ggf. auch Systeme dazwischen (je nach Netzwerk).
Exchange2013 und Outlook2013 funktioniert dann „OK“ mit MAPI over HTTP.
Mit Outlook2016 bekomme wir „nur“ am Anfang beim ersten Einrichten ein Pop-Up-Fenster für die Anmeldung, danach aber keine mehr.
Vermutlich musst Du die Authentifizierung für die Website MAPI genau so einstellen wie für RPC, wenn diese automatisch funktioneren soll.
Für OWA hat man ja auch meist Formularbasierte, wenn nicht automatisch mit InternetExplorer (ggf. hat man auch noch ein Loadbalancer von KEMP der da auch noch was zu sagen hat, z.B. mit RSA-SecureID).
Ich habe MAPIoverHTTP auf dem Exchange 2013 wieder ausgeschaltet, das Clients mit Outlook 2013 bei jedem Starten nach den User Credentials gefragt hat. War dann doch für die User etwas nervig.
Hallo, gibt es schon Erfahrungen zu Regeln für die Sophos UTM Web Application Firewall? Grüße, Ulrich
Cooles Protokoll… da werden sich Squid und Co aber freuen. :-)