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:
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:
Damit die Postfächer geprüft werden können, muss die Authentifizierung für OWA auf „Nur Benutzername“ umgestellt werden:
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:
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:
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:
Nachdem die Änderungen an der Exchange Konfiguration vorgenommen wurden, sollte die iApp in etwa so aussehen:
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:
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…
Ok, hat sich erledigt. Man muss hier tatsächlich auf die Großkleinschreibung Bei Ssl,Ssl128 achten.
Hallo, deine Artikel haben mir schon oft geholfen, allerdings bräuchte ich zu diesem hier einen Tipp…
Wie kann ich diesen Befehl wieder Rückgängig machen?:
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/OWA“
MfG Carsten
wonderful article
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…
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.