Erster Ausblick auf Exchange Server 2013
23. August 2012
Die ersten Preview-Versionen von Exchange Server 2013 und Outlook 2013 haben im Juli ihr Debüt gegeben. Eine wichtige Änderung betrifft den Umgang mit MAPI-Verbindungen: Sämtlicher MAPI-Verkehr muss gekapselt werden und kann nur mehr über RPC-over-HTTPS übertragen werden. Das macht den CAS bei Exchange 2013 einfacher als bei den Vorgängern, doch in speziellen Fällen sind bestimmt Einstellungen nachzujustieren.
Tony Redmond zeigt, wie diese Details zusammenhängen.
Im Rahmen des Office 2013 Preview Release ist die Preview-Version des Exchange Server 2013 verfügbar – derzeit in den Sprachversionen Englisch, Japanisch und Spanisch. Bei Exchange 2013 wird sich vieles ändern. Geplant ist die Vorstellung von Exchange 2013 im Umfeld der Microsoft Exchange Conference in Orland am 24. September 2012. In der Eröffnungs-Keynote wird ein technischer Einblick in diese Version gegeben. 70 weitere Vorträge beziehen sich auf dieser Konferenz auf Exchange 2013.
Es werden auf diesem Event einige Neuerungen gezeigt: So hat Microsoft bei Exchange die „Modern Public Folders“ eingeführt – viele werden den Ausdruck für einen Widerspruch in sich halten. Zudem wird die Anzahl der Serverrollen reduziert – es gibt nur mehr CAS (Client Access Server) und Mailbox Server. Ein weiterer interessanter Aspekt ist die enge Verbindung zwischen Exchange 2013 und Sharepoint – dazu gehören zum Beispiel die „Site Mailboxes“. Auf der Technet-Website gibt es bereits eine umfassende Dokumentation für Exchange 2013 Preview.
Anwender, die Exchange Online unter Office 365 verwenden, werden von den neuen Features profitieren, nachdem Microsoft die neue Software in seinen Rechenzentren zum Einsatz bringt. Der genaue Zeitpunkt und die neuen Möglichkeiten für die Administratoren sind noch nicht zu 100 Prozent festgelegt – allerdings wird erwartet, dass Microsoft recht schnell hier für mehr Klarheit sorgt. Doch eine neue Version von Exchange ist nur dann komplett, wenn es auch ein neues, dazu passendes Outlook gibt: Daher ist auch eine Preview-Version von Outlook 2013 verfügbar.
Dazu muss man als Client-Betriebssystem allerdings Windows 7 oder Windows 8 verwenden – denn Office 2013 läuft nicht mehr auf Vista oder Windows XP. Wie es bisher auch schon der Fall war, muss man die Kombination aus neuestem Outlook und neuestem Exchange verwenden, wenn man alle neuen Server-Funktionen ausnutzen möchte.
Exchange 2013 setzt auf RPC-over-HTTPS
Eine der interessanten Änderungen bei Exchange 2013 ist die Entscheidung, nur mehr RPC-over-HTTPS als alleinige Methode zu verwenden, um die Verbindung zu Outlook-Clients herzustellen. Damit werden die direkten MAPI-Verbindungen über TCP nicht mehr unterstützt – das betrifft selbst Intranet-basierte Verbindungen.
Das RPC-over-HTTPS (Outlook Anywhere) wird bereits seit Exchange 2003 unterstützt – es handelt sich also um ein ausgereiftes und bekanntes Protokoll. Wenn nun alle MAPI-Clients ihre Datenpakete in HTTPS-Paketen einkapseln (sprich wrappen) müssen, ergeben sich daraus einige Vorteile für die Konzeption von Exchange. Zum einen muss sich der CAS um ein Protokoll weniger zu kümmern.
Zum zweiten wird der RPC Client Access Service entfernt, weil sich der CAS nicht mehr um MAPI zu kümmern hat. Damit muss deutlich weniger Code auf dem CAS ausgeführt werden. Zudem ergeben sich durch den Entfall des RPC Client Access Service beim CAS gegenüber Exchange 2010 auch Vereinfachungen bei Aktionen wie dem „Site Resilient Failover“. Zum Beispiel braucht man sich beim Umschalten auf eine andere Site nicht mehr um die Namespaces kümmern. Zum dritten ist die HTTP-Familie bestens geeignet, um Verbindungen über eine Vielzahl von verschiedenen Netzwerken aufzubauen. Und RPC-over-HTTPS hat seine Stabilität und Zuverlässigkeit auch bei sehr großer Anzahl von Verbindungen bewiesen, selbst bei komplexen Konfigurationen, wie sie beim Zugriff auf Exchange Online unter Office 365 gegeben sind.
Der letzte Vorteil bezieht sich auf die Angabe des „Kommunikationsendpunkts“: Bei Outlook muss ein Server-FQDN (Fully Qualified Domain Name) als Kommunikationsendpunkt angegeben werden. Bei Exchange 2010 wurde dieser Endpunkt von einem Postfachserver (Mailbox Server) auf einen CAS umgelegt. Exchange 2013 geht noch weiter: Hier reicht die GUID eines Postfachs und das UPN-Suffix als Endpunktangabe.
Die Postfach-GUID ist innerhalb einer Organisation eindeutig und zeigt Exchange, wie die Verbindung zum Postfach eines Benutzers herzustellen ist. Dazu sind dann keine Zusatzinformationen – wie etwa ein Referral – vom CAS notwendig. Das erweist sich bei den Clients als große Verbesserung: Sie müssen nicht mehr auf einen neuen Endpunkt umkonfiguriert werden, denn das wird komplett vom Autodiscover-Mechanismus übernommen, der zum Einsatz kommt, wenn sich ein Client das erste Mal an einem Exchange 2013 CAS verbindet.
Exchange 2013 braucht mindestens Outlook 2007
Exchange 2013 unterstützt allerdings nur mehr Outlook ab der Version 2007. Daher sollte man den Umstieg von Outlook 2003 nun angehen, wenn man den Einsatz von Exchange 2013 vorhat.
Auf den ersten Blick sieht das Umstellen des Formats für die Angabe des Endpunkts als ein sehr theoretischer Vorgang aus. Doch in der Praxis erweist sich das als extrem sinnvoll: Damit wird ein Postfach im Rahmen einer Server-Infrastruktur sehr „portabel“.
Bei Exchange 2007 und den früheren Versionen waren die Postfächer noch fest mit bestimmten Datenbanken verbunden, die auf ganz speziellen Servern lagen. Bei Exchange 2010 kam es schon zu einer Verbesserung: Die Verbindung zwischen Datenbank und Server wurde aufgebrochen, indem man den MAPI-Endpunkt auf den CAS verschoben hat und die DAG (Database Availability Group) eingeführt hat.
it Exchange 2013 kommt in diesem Kontext eine noch höhere Abstraktion ins Spiel: Das Postfach selbst wird zum Zielpunkt für die Verbindung. Damit dürften die Anwender keine Probleme mehr bekommen, wenn der Administrator eine Umkonfiguration in der Server-Infrastruktur vorgenommen hat, und damit sollten dann auch Fehlermeldungen nach dem Motto „An der Konfiguration ihres Postfachs wurde etwas geändert. Bitte starten sie Outlook neu“ der Vergangenheit angehören.
Mit diesen grundlegenden Änderungen an der Arbeitsweise der CAS sollte man auch unbedingt den Empfehlungen folgen, die Microsoft für die CAS bei Exchange 2013 herausgegeben hat. Die Exchange 2013 CAS sollten zuerst an allen den Internet zugewandten Sites zum Einsatz kommen und dann bei den internen Sites. Damit kann Exchange 2013 Schritt für Schritt die Client-Verbindungen richtig abwickeln.
Mit der gestiegenen Wertigkeit von RPC-over-HTTPS muss man beim RPC Proxy Service (er läuft im Kontext des IIS und wickelt den ankommenden HTTPS-Verkehr ab) mehr Sorgfalt walten lassen. Hier gibt es von Microsoft die entsprechenden Vorgaben im MSDN.
Der RPC-Proxy muss auf jedem Server konfiguriert sein, der die CAS-Rolle ausführt und wird auch in den allermeisten Fällen sauber laufen. Doch in einigen Situationen kann es dazu kommen, dass bestimmte Einstellungen anzupassen sind – vor allem wenn weitere Netzwerkkomponenten mit zu berücksichtigen sind.
Ein Beispiel dafür ist das Erstellen einer Vollduplex-Verbindung mit Exchange. Dabei muss Outlook zwei TCP-Verbindungen über einen RPC-over-HTTPS-Link benutzen. Diese Links werden als RPC_In_Data und RPC_Out_Data bezeichnet. Werden über diese beiden Verbindungen keine Daten übertragen, hält sie der Client standardmäßig aufrecht und sendet alle 720 Sekunden (12 Minuten) einige Byte über diesen Link. Auch der Exchange-Server macht seine Hausaufgaben und hält die Verbindung aufrecht, nimmt dazu aber ein Zeitintervall von 900 Sekunden (15 Minuten), um diese „Keep Alive“-Bytes zu versenden.
Für die meisten Konfigurationen reichen diese Zeitintervalle bestens aus. Kommen aber noch weitere Netzwerkkomponenten mit ins Spiel, kann sich das aber als weniger effektiv erweisen – vor allem wenn diese Komponenten die TCP-Verbindung eher „fallen“ lassen. Dann tritt der Effekt auf, dass die Clients von Zeit zu Zeit die Verbindung zum Exchange-Server verlieren und dass sie die Verbindung neu herstellen müssen um eine Synchronisation auszuführen oder um Mails zu versenden. Das führt dann zu Situationen, bei denen die Mails nicht mehr aus dem Postausgang heraus gesendet werden.
Beheben lässt sich das mit einer Änderung des „Keep Alive“-Intervalls des Proxys auf 180 oder gar 120 Sekunden. Das lässt sich in der Registry des CAS einstellen (beim Schlüssel HKLM\Software\Policies\Microsoft\Windows NT\Rpc\MinimumConnectionTimeout). Dann muss der CAS (oder die CAS-server) neu gestartet werden. Damit wird dann allerdings etwas mehr „nutzloser“ Datenverkehr im Netzwerk fließen, doch das macht in der Regel nicht viel aus.
