Das Service Pack 1 für Exchange 2013 bringt ein neues Protokoll für die Kommunikation zwischen Outlook und Exchange mit: MAPIoverHTTP. Bisher wird MAPIoverHTTP nur von Outlook 2013 mit SP1 und Exchange 2013 SP1 unterstützt. Daher
Wie funktioniert MAPIoverHTTP?
Mit dem Service Pack 1 für Office 2013 und aktivierten MAPIoverHTTP kennt Exchange nun 2 Protokolle um mit Outlook zu kommunizieren. Bisher wurde als Protokoll RPCoverHTTP verwendet, welches schon bei Outlook Anywhere zum Einsatz kam. Seit Exchange 2013 RTM wurde RPCoverHTTP auch für die interne Verbindung von Outlook zu Exchange als Standard verwendet.
MAPIoverHTTP funktioniert im Gegensatz zu RPCoverHTTPS ohne RPC-Calls. Um die Funktionsweise etwas zu verdeutlichen, habe ich folgende Grafik erstellt:
Links sieht man vereinfacht wie RPCoverHTTP funktioniert. Outlook verpackt die RPC-Calls in HTTPS und sendet sie zum Exchange Server, der Exchange Server wiederum, muss die RPC-Calls aus der HTTPS Verbindung auspacken um sie zu verarbeiten. Bei Exchange 2010 konnte Outlook auch direkt via RPC mit Exchange kommunizieren.
Rechts wird nun der Unterschied deutlich: Die RPC Kommunikation fällt komplett weg. Outlook unterhält sich direkt via HTTPS mit dem Exchange Server. Auf die Vorteile dieser Kommunikation gehe ich später ein. Hier geht es zuerst um die Funktionsweise.
Für RPCoverHTTPS wurde das IIS Verzeichnis /RPC genutzt. Für MAPIoverHTTP ist das Verzeichnis /MAPI hinzugekommen. Das Verzeichnis wird mit der Installation des Service Pack 1 für Exchange 2013 angelegt
Das MAPI Verzeichnis lässt sich über die Exchange Management Shell konfigurieren, bzw anzeigen:
Get-MapiVirtualDirectory -Server EX1
´
Die Parameter zu Konfiguration sind vergleichbar mit denen für RPCoverHTTPS, es gibt im wesentlichen Interne URLs, externe URLs und die Authentifizierungseinstellungen.
Auch die Exchange Organisation kennt nun einen neuen Parameter, hier ist MAPIoverHTTP noch abgeschaltet:
Get-OrganizationConfig | fl name,mapi*
Ob Outlook MAPIoverHTTP nutzen kann erfährt es via Autodiscover.
Es müssen also keine Einstellungen manuell am Outlook Client geändert werden, allerdings fordert Outlook einen Neustart wenn MAPIoverHTTP aktiviert wird.
Vorteile von MAPIoverHTTP
Die Vorteile von MAPIoverHTTP sind schnell erklärt: MAPIoverHTTP hat nicht die Nachteile wie RPCoverHTTP. Bei RPCoverHTTP musste eine RPC Verbindung über das HTTP Protokoll getunnelt werden, das führte zu ein paar Problemen:
- Nicht alle Firewalls verstehen RPCoverHTTP
- Bei Verbindungsverlust muss auch die RPC Verbindung terminiert werden
Gerade den zweiten Punkte kennen die Notebook Benutzer. Im Büro wird Outlook nicht geschlossen, sondern nur schnell das Notebook eingesteckt, man kommt beim Kunden an und Outlook braucht eine gefühlte Ewigkeit um wieder eine Verbindung zum Exchange Server herzustellen.
MAPIoverHTTP hat also den Vorteil das es unabhängig vom Standort oder Art der Verbindung funktioniert, da eben nicht erst wieder RPC Verbindungen terminiert und neu aufgebaut werden müssen. Wahrscheinlich winken auch die meisten Firewalls mit Content Inspection die Verbindungen als „normalen“ HTTPS-Verkehr durch 
, das habe ich aber noch nicht getestet.
Wie wird MAPIoverHTTP aktiviert?
Wie schon erwähnt lässt sich MAPIoverHTTP (Stand 03.2014) aktuell nur mit Exchange 2013 SP1 und Outlook 2013 SP1 nutzen.
Die Einrichtung von MAPIoverHTTP ist einfach: Interne und Externe URL konfigurieren, Einschalten, Fertig.
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl "https://outlook.frankysweb.de/mapi" -ExternalUrl "https://outlook.frankysweb.de/mapi" -IISAuthenticationMethods Ntlm, OAuth, Negotiate
Der Befehl oben konfiguriert MAPIoverHTTP auf die URL outlook.frankysweb.org. Ich wähle hier die gleiche Konfiguration wie auch bei Outlook Anywhere (RPCoverHTTPS). In meinem Fall ist „outlook.frankysweb.org“ der VirtualService des Loadbalancers. Der Hostname muss auf dem Zertifikat vorhanden sein.
Jetzt muss nur noch MAPIoverHTTP aktiviert werden:
Set-OrganizationConfig -MapiHttpEnabled $true
Ob die Verbindung mit mit MAPIoverHTTP oder mit RPCoverHTTP hergestellt wird, lässt am Outlook Client feststellen. Hier zunächst eine Verbindung via RPCoverHTTPS:
Und hier via MAPIoverHTTP:
Wichtig: Outlook erfordert einen Neustart, wenn MAPIoverHTTP aktiviert wird:
Welche Möglichkeiten zur Fehleranalyse gibt es?
Der wohl einfachste Weg die Funktion von MAPIoverHTTP zu testen, ist es die Healthcheck Seite aufzurufen. Viel mehr als den IIS Server testet man damit allerdings nicht:
Etwas weiter geht da schon das Test-Outlook CMDlet, welches über den folgenden Befehl ausgeführt werden kann:
Test-OutlookConnectivity -RunFromServerId EX1 -ProbeIdentity OutlookMapiHttpSelfTestProbe
Am Aussagekräftigsten sind allerdings die Logfies:
- C:\Program Files\Microsoft\Exchange Server\V15\Logging\MAPI Client Access
- C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Mapi
Welche Probleme sich mit MAPIoverHTTP ergeben, muss sich erst noch zeigen.
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. :-)