MAPI/HTTP: das neue Zugriffsprotokoll in Exchange 2013 SP1

Eine der interessanten Änderungen im kürzlich erschienenen Service Pack 1 von Exchange 2013 ist das alternative Verbindungsprotokoll MAPI/HTTP für Outlook Clients. Was hat es damit auf sich? Wie kann es aktiviert werden und welche Vor- und Nachteile ergeben sich aus der Verwendung? Auf diese Fragen erhalten Sie in diesem Artikel eine Antwort.

Ein paar Worte zur Geschichte der Verbindung Outlook–Exchange

Bis Exchange 2000 wurde der Datenbank-Zugriff von Outlook direkt über RPC zum Mailboxserver abgewickelt. In Exchange 2003 wurde erstmals mit dem RPCoverHTTP Proxy des Betriebssystems eine Möglichkeit geschaffen, Outlook über ein öffentliches Netzwerk mit den Servern zu verbinden, ohne dass ein VPN verwendet werden musste. Der Endpunkt der HTTP-Verbindung konnte mit Hilfe einer dedizierten Frontend-Server-Installation von der Datenbank separiert werden.

In Exchange 2007 und 2010 wurde dies dann noch weiterentwickelt – (fast) alle Verbindungen wurden auf einer speziellen Serverrolle terminiert: dem Client Access Server. RPCoverHTTP erhielt noch einen neuen Namen, nämlich Outlook Anywhere.

Zeit also, wieder einmal etwas komplett neues zu entwickeln, damit alle Hersteller von 3rd Party Software eine Beschäftigung haben? Nicht ganz. Outlook Anywhere hat sicher viele Vorteile, aber eben auch einige Mankos. Eines davon ist die Komplexität der Verbindung. Eigentlich handelt es sich um MAPI in RPC in HTTP, also ein Tunnel in einem Tunnel. Genau genommen sind es zwei Tunnels, die am Ende auf denselben Server treffen müssen. Die Komponente des RPC Proxies gehört nicht zu Exchange, sondern zum Betriebssystem. Dies macht Anpassungen viel schwieriger. Die nachfolgende Illustration zeigt die Verbindungen zwischen Outlook 2013 und Exchange 2013 vor SP1:

Und hier sehen Sie die Verbindung nach Aktivierung von MAPI/HTTP:

Ein Hauptgrund für das neue Protokoll ist also die Verringerung der Komplexität. Was sind nun aber die Pros und Kontras?

Dass trotz der Vereinfachung mehr Daten übertragen werden müssen, mag erstaunen. Leider liegen von Microsoft noch keine Sizing Guidelines vor, die diesem Umstand Rechnung tragen.

Mich hat es trotzdem interessiert, wie gross der Unterschied sein würde und ich habe deshalb einen Test gemacht: 2 Windows 8.1 Clients, die auf denselben Exchange 2013 SP1 Server verbinden. Ein Client mit Outlook 2013 installiert, der andere mit Outlook 2013 SP1. Während ich auf beiden Testgeräten die gleichen Aktionen durchgeführt habe, wurde auch der Netzwerkverkehr mittels Network Monitor aufgezeichnet und nachher mit NMTopProtocols analysiert. Hier sind die Ergebnisse:

RPCoverHTTP

MAPI/HTTP

Natürlich ist die Datenmenge zu gering, um wirklich ein Sizing danach zu richten. Aber immerhin zeigt sich der oben erwähnte Datenzuwachs in der Kolonne Total Bytes beim Protokoll TLS.

Ebenso neugierig war ich auf die Verbesserungen beim erneuten Verbindungsaufbau im Falle von Roaming oder Hibernation. Allerdings habe ich in den Tests nur das virtuelle Netz von den Clients entfernt und wieder hinzugefügt. Hier das Resultat:

Auch bei diesem Versuch ist das Ziel eher, ein Gefühl für die Änderung zu bekommen als statistisch relevante Daten zu erhalten, da die Anzahl Testläufe gering waren.

Wie wird MAIP/HTTP aktiviert?

Wenn alle Server den Stand von SP1 haben, lässt sich mit dem Kommando

das Feature aktivieren. Es muss unbedingt sichergestellt werden, dass InternalURL und ExternalURL mit Set-MapiVirtualDirectory auf einen Wert eingestellt sind, der auch im Zertifikat auf den Servern vorhanden ist. Andernfalls ist keine Verbindung möglich.

Aufgrund eines Bugs muss auch das Attribut InternalAuthenticationMethods gesetzt werden. Am besten wird der bestehende Wert übernommen.

Outlook 2013 und früher funktionieren übrigens problemlos mit RPCoverHTTP weiter:

Hier noch die der Verbindungsstatus auf die gleiche Mailbox, aber mit MAPI/HTTP:

Es ist gut zu erkennen, dass kein (RPC-)Proxy verwendet wird und stattdessen Zugriffe auf Mailboxstore und Directory (NSPI) über HTTPS laufen.

Fazit

Das neue Protokoll ist eine interessante Option, die sich aber erst noch in der Praxis bewähren muss.