Exchange 2016: Loadbalancing mit F5 BigIP LTM 11.6 (iApp) Teil 2

Wie schon angekündigt, geht es im zweiten Teil dieser Artikelserie „Loadbalancing Exchange 2016 mit F5 Big IP“ um ein paar Optimierungen seitens Exchange Server und Loadbalancer. Der erste Teil findet sich hier.

Postfächer für die „Advanced Monitors“

LTM kann in der iApp zwei Postfächer prüfen. Bei den Benutzerkonten sollte eingestellt werden, dass die Passwörter nicht ablaufen:

Benutzerkonto

Des weiteren sollten die Postfächer in unterschiedlichen Postfach Datenbanken gespeichert sein. Die Postfach Datenbanken sollten im Normalfall auf unterschiedlichen Mailbox Servern aktiv sein.

Die Konfiguration innerhalb der iApp sieht dann in etwa so aus:

iApp

Damit die Postfächer geprüft werden können, muss die Authentifizierung für OWA auf „Nur Benutzername“ umgestellt werden:

Authentifizierung

Ich konnte allerdings auch keine Probleme feststellen, wenn die Authentifizierung mit dem UPN erfolgt, anstatt nur mit dem Benutzernamen.

SSL Offloading

Exchange 2016 lässt in der Standard Einstellung kein SSL-Offloading zu. Ohne entsprechende Konfiguration Änderung ist der Service offline, sobald SSL-Offloading aktiviert wird:

SSL Offloading

Bevor also SSL-Offloading eingeschaltet wird, muss die Exchange Konfiguration angepasst werden. Eine Ausnahme ist Outlook Anywhere, hier ist SSL-Offloading bereits in der Standardkonfiguration aktiviert:

Exchange SSL-Offloading

Um SSL-Offloading auch für die anderen Dienste (OWa, EAS, etc) zu aktivieren, können die folgenden PowerShell Befehle verwendet werden:

Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/OWA"
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/ECP"
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/OAB"
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/EWS"
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/Microsoft-Server-ActiveSync"
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/Autodiscover"
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value "None" -PSPath IIS: -Location "Default Web Site/MAPI"

Nachdem die Änderungen durchgeführt wurden, müssen noch der Anwendungsppol und der IIS neugestartet werden:

Restart-WebAppPool MSExchangeOWAAppPool
iisreset

Diese Befehle müssen auf jedem Exchange Mailbox Server ausgeführt werden.

Jetzt kann SSL-Offloading in der iApp eingeschaltet werden:

iApp SSL-Offloading

Nachdem die Änderungen an der Exchange Konfiguration vorgenommen wurden, sollte die iApp in etwa so aussehen:

Loadbalancing

Unterschiedliche URLs für die Exchange Webservices

Unterschiedliche URLs für die einzelnen Webservices machen durchaus Sinn, aber sind aus meiner Erfahrung in der Praxis nicht immer ganz so einfach umzusetzen. Auf dem Exchange Team Blog ist das Thema für Exchange 2016 sehr anschaulich erklärt:

http://blogs.technet.com/b/exchange/archive/2015/10/08/load-balancing-in-exchange-2016.aspx

Hier muss nun jeder selbst entscheiden, ob unterschiedliche URLs genutzt werden, oder nicht. In der Praxis ist das manchmal etwas schwer umzusetzen, Stichwort: Firewalls, IP-Adressen und Kosten für das SAN-Zertifikat.

Ob nun Single Namespace oder Multiple Namespace, die Einstellung „Different FQDNs for each HTTP service“, sollte in jedem Fall aktiviert werden. In meinen Testumgebungen veröffentliche ich Exchange immer mit einem Single Namespace. Allerdings ist LTM in der Lage auch bei einem Single Namespace die Webservices entsprechend zu prüfen:

Webservices

Fazit

Ich konnte bisher keine Probleme iApp Relase Candidate feststellen. Ich denke die iApp wird ohne große Änderungen freigegeben werden. Bis dahin würde ich allerdings noch warten.

Als ich diesen Artikel geschrieben habe, ist mir eingefallen das ich auch noch einen KEMP LoadMaster rumliegen habe, daher mache ich den jetzt mal einsatzbereit und bringe ihn auf die aktuelle Version. Dazu gibt es dann Teil 3…

3 Kommentare zu “Exchange 2016: Loadbalancing mit F5 BigIP LTM 11.6 (iApp) Teil 2”

  1. Ich frage mich warum es ein F5 sein muss? Der ist ja wohl für KMS nicht das gelbe vom Ei, sondern eher geignet für Exchange Organistation ab 10.000 Mailboxen.

  2. Naja, er hat ja nicht von Muss geschrieben, oder? Der Kemp kommt ja als Nächstes dran. Es ist sicherlich eine Frage des Geldbeutels, aber eine F5 ist weit mehr als ein Load-Balancer, der LTM ist nur der Kern des Ganzen und das, womit sie groß geworden sind. Wenn man sich eine F5 hinstellt nutzt man entweder wenige Features für eine Menge gleichartigen Traffics oder konsolidiert viele Funktionen auf der Plattform, dann lassen sich auch viele Szenarien lohnend auf einer Plattform abbilden. Skalierungsfähigkeit ist ein weiterer, nicht zu unterschätzender Vorteil. Eine F5 nur für Exchange hinzustellen ist aber in den allermeisten Fällen mit Kanonen auf Spatzen geschossen, da hat die ja gar nichts zu tun. ;-) – Danke für die Artikel. Da sich zu 2013 in dem Bereich ja nicht wirklich was geändert hat, war aber auch nichts anderes zu erwarten, wobei, bei der 11.6…, unbedingt den aktuellen Hotfix einspielen, wobei wir selbst für den in Kürze den zweiten Engineering HF bekommen…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.