LOAD BALANCER NEWS

Wir freuen uns über Zusendungen – HEUTE: Aus dem Leben eines Exchange Consultants & Trainers

Der Loadbalancerblog lebt von Tips, Ideen und regen Austausch in der Community. Daher freuen wir uns sehr, wenn wir Zusendungen von Consultants, Trainern und System Engineers erhalten die nicht direkt bloggen wollen, aber die Community trotzdem über Ihre Gedanken informieren wollen.

So auch diese Zusendung von Bernd Kruczek, seines Zeichens Guru in der Exchange Welt – ganz großen Dank an dieser Stelle.

CAS und CAS Array für Outlook Full Clients entmystifiziert:
Wenn ich meine Exchange 2010 Schulung halte und es kommt zum Thema CAS, stelle ich immer wieder fest, dass es da doch große Verständnislücken bei den Teilnehmern gibt. Zwar ist meistens bekannt dass ein Server mit der Rolle CAS zwingend in der Exchange Organisation vorhanden sein muss, weil alle Client Zugriffe über einen CAS laufen und dass man auch aus Gründen der Hochverfügbarkeit und des Lastenausgleichs besser zwei oder noch mehr CAS mit Loadbalancing einsetzt. Aber das war es dann meistens auch schon.
Alleine bei der Erwähnung der Tatsache, dass in einem Outlook Profil bei „Server“ ein Server eingetragen ist, der die Rolle CAS hat, und nicht ein Mailbox Server, lässt schon die eine oder andere Augenbraue hochgehen (Exchange 2003 / 2007 lässt grüßen).
Aber wie findet Outlook, respektive Autodiscover diesen Server? Natürlich über das Active Directory, genauer dem Wert im Attribut homeMDB des angemeldeten User Accounts.   Denn ein Attribut einer Exchange Mailbox Datenbank  ist der RCPClientAccessServer, also ein Server mit der Rolle CAS. Man kann sich das in Exchange Powershell mit dem Befehl
Get-MailboxDatabase | Select Name, RpcClientAccessServer, Server | fl
sehr schön für alle vorhandenen Mailbox Datenbanken auflisten lassen.
Damit wird auch eines deutlich, die Zuordnung für ein Postfach findet auf der Ebene User Mailbox-CAS – Mailbox Datenbank statt. Doch wie geht diese Zuordnung vor sich? Befinden sich die Rollen MBX und CAS zusammen auf einem Server, bekommen die Mailboxen dieses Servers immer den lokalen CAS als RCPClientAccessServer zugewiesen. Ist dies nicht der Fall, prüft der Algorithmus auf Server mit der Rolle CAS in derselben AD Site, in der sich auch der Server mit der Rolle MBX befindet. Die eigentliche Zuordnung ist dann zufällig, wenn sich mehr als ein Server mit der Rolle CAS in dieser AD Site befindet.  Trifft auch dies nicht zu wird nach weiteren Servern mit der Rolle CAS in anderen AD Sites gesucht und zugewiesen.
Was aber nun wenn die Rolle CAS nicht mehr zur Verfügung steht und man nur einen Server mit der Rolle CAS hat? Der Client hat dann natürlich keinen Zugriff mehr auf seine Mailbox.
Was ist aber, wenn man einen zweiten Server mit der Rolle CAS hat? Das nützt zunächst ohne weiteren Eingriff auch nichts, weil ja im homeMDB Attribut des User Accounts und im Attribut RCPClientAccessServer der Mailbox Datenbank noch  immer derjenige CAS Server steht, der nun nicht mehr zugreifbar ist. Eine Neuanlage des Outlook Profils hilft hier natürlich auch nichts, da ja beim Autodiscover Prozess immer dieser Wert ausgelesen wird.
Also muss zunächst die Zuordnung CAS – Mailbox Datenbank geändert werden, was mit dem Exchange Powershell Befehl
Set-MailboxDatabase –id „database“ –RpcClientAccessServer ‘FQDN CAS Server“
leicht bewerkstelligt werden kann. Nun muss aber noch das Outlook Profil der User hinsichtlich des neuen CAS Servers angepasst werden, was im Normalfall nur durch ein Löschen des Profils und einer Neuanlage verlässlich funktioniert.
Machbar bei 5 Postfächern und Turnschuhadministration, aber bei 50, 500, 5000 Postfächern?
Aber da naht ja schon die Rettung, denn bei der verzweifelten Suche nach diesem Thema stößt man mehr als einmal auf das Zauberwort CAS Array! Ein Array, also ein Verbund aus einem (ja, das geht!) oder mehreren Servern mit der Rolle CAS, welches man den Mailboxdatenbanken zuweisen kann (selber Befehl wie oben, nur dass eben nicht der FQDN eines einzelnen CAS Servers verwendet wird sondern der FQDN des CAS Array) und es dann noch im Outlook Profil per Autodiscover eintragen lässt.
Dumm nur, dass das so ohne weiteres nicht funktioniert. Denn das Anlegen eines CAS Arrays mit dem Exchange Powershell Befehl
New-ClientAccessArray –Name ‘name’ –FQDN ‘FQDN des CAS Array’ –Site ‘Active Directory Site’
und die Zuweisung an die Exchange Mailbox Datenbanken ist nur die halbe Miete!
Um es grundsätzlich benutzen zu können braucht es noch einen DNS Record für den FQDN des CAS Array verknüpft mit einer IP Adresse. Wenn man nun auch noch für etwas anderes als einen oder besser zwei  Loadbalancer spart, gibt es hier nur eine Möglichkeit:
die IP Adresse im DNS Records des CAS Array ist eine IP Adresse eines der Servers mit der Rolle CAS im CAS Array.
Jetzt kann das Outlook Profil abgeändert werden und alles ist gut. Fällt nun dieser Server mit der Rolle CAS aus und man hat mehr als einen CAS Server muss nun lediglich die IP Adresse des DNS Records auf den zweiten CAS Server abgeändert werden und nach der definierten TTL greifen die Clients korrekt zu. Also kein Eingriff bei den Clients, lediglich an den Servern.
Hat man nun genug gespart und es reicht für zwei  Loadbalancer muss nach der Einrichtung der VIPs an den Loadbalancern nur noch die IP Adresse im DNS Record des CAS Array auf die IP Adresse der VIPs am Loadbalancer  umgestellt werden. Perfekt!
Fast, denn es gibt noch einiges zu beachten. Da ist zunächst einmal der Parameter „Site“ im Poweshell CMDlet zur Erzeugung eines CAS Array. Die bedeutet zweierlei:
–    Es kann nur ein CAS Array pro Active Directory Site geben
–    Nur Clients aus dieser Active Directory Site könne auf dieses CAS Array zugreifen
Außerdem müssen die Server mit der Rolle CAS noch hinsichtlich der Ports angepasst werden. Um ein Loadbalancing für native Outlook Clients zu bewerkstelligen braucht es 3 VIPs.
–    TCP Endpoint Mapper
–    MS Exchange Address Book
–    MS Exchange RPC
Für den TCP Endpoint Mapper ist der Port fest vorgegeben, 135. Für MS Exchange Address Book und MS Exchange RPC handelt es sich allerdings um Port Ranges. Diese müssen also nun zunächst auf jedem Server mit der Rolle CAS auf einen festen Port gelegt werden. Aber wir machen ja nix mit der Hand und per Regedit, wozu gibt es Scripts. Hier zum Beispiel:

http://blogs.technet.com/b/bshukla/archive/2011/10/21/script-to-configure-static-ports-on-exchange-server-2010.aspx

; funktioniert einwandfrei und geht sogar Remote.
Nun steht der Einrichtung der drei erforderlichen VIP für native Outlook Access anhand der wunderbaren KEMP Dokumentationen nichts mehr im Weg.
Viel Spaß und gutes Gelingen.

Best Practice
–    Multi Role Server Installation (auch bei einer DAG) und KEINE Single Role Server Installation! Das ist Old School und war vorgestern. Nur praktikabel wenn Sie einen reinen Mailboxserver bauen wollen und dessen potentielle Kapazität bezüglich CPU Cores exklusiv und bis zum Anschlag für eine maximale Anzahl von Mailboxen  benutzen wollen.
–    Hardware Loadbalancing (HLB) statt Network Loadbalancing (NLB). Auch NLB ist Vorkrieg, hat deutliche Nachteile gegenüber HLB und preisliche Vorteile. Selbst wenn Sie CAS und HT auslagern sollten Sie dennoch HLB benutzen. Mit allen drei Rollen auf einem Server in einer DAG ist NLB übrigens nicht möglich.
–    Datenbanken und Datenbankpfade umbenennen. Die Benutzung des Datenbanknamens „Mailbox Database 1234567“ in Powershell CMDlets ist etwas sperrig.
–    Immer so früh wie möglich ein CAS Array einrichten und den Mailbox Datenbanken zuweisen, auch wenn es zu diesem Zeitpunkt gerade mal einen Server mit der Rolle CAS gibt und das HLB erst noch gekauft werden muss. Denn wenn Sie das erst später machen, zu einem Zeitpunkt zu dem schon Mailboxen in den Mailboxdatenbanken existieren, wird das wegen der Änderung im Outlook Profile verdammt aufwendig!
Und last but not least, noch mehr Futter zum Thema CAS gibt es hier:
http://blogs.technet.com/b/exchange/archive/2012/03/23/demystifying-the-cas-array-object-part-1.aspx

Tags:

Related.Posts

Comments are closed.