Entmystifizieren des Clientzugriffsserver-Arrayobjekts - 1. Teil

Veröffentlichung des Originalartikels: 24.03.2012

Seit der Markteinführung 2009 ist das Interesse an Exchange 2010 riesig. Bei der Schulung und Vorbereitung von Kunden auf einen Wechsel zu Exchange 2010 sind wir auf einige häufige Missverständnisse gestoßen. Eines davon bezieht sich auf das Clientzugriffsserver-Arrayobjekt. Der technische Autor und aktive Blogger Scott Schnoll schlug mir vor, doch einmal in die Tasten zu hauen, als ich in einer internen Microsoft-Gruppe auf dieses Missverständnis hinwies. Das habe ich mit diesem Beitrag getan.

Ich werde in diesem Beitrag nicht auf alle technischen Aspekte eines Clientzugriffsserver-Arrayobjekts eingehen. Darum hat sich Nagesh Magadev in einem früheren Beitrag bereits ausführlich gekümmert: Exploring Exchange 2010 RPC Client Access service.

Es folgt eine Liste mit Tatsachen, denen sich die meisten Benutzer in Bezug auf das Clientzugriffsserver-Arrayobjekt nicht bewusst sind und die ich zu entmystifizieren versuche. Die ersten drei werde ich im 1. Teil, die letzten drei im 2. Teil behandeln.

1. Ein Clientzugriffsserver-Arrayobjekt bewirkt keinen Lastenausgleich für Ihren Datenverkehr.
2. Ein Clientzugriffsserver-Arrayobjekt leistet keine Dienste für die AutoErmittlung, Outlook Web App, die Exchange-Systemsteuerung, Exchange Web Services, IMAP, POP oder SMTP.
3. Der vollqualifizierte Domänenname (FQDN) muss nicht Teil des SSL-Zertifikats sein.
4. Ein Clientzugriffsserver-Arrayobjekt darf nicht von externen Clients über DNS aufgelöst werden.
5. Ein Clientzugriffsserver-Arrayobjekt darf nach Erstellen von Exchange Server 2010-Postfachdatenbanken und Verschieben von Postfächern in die Datenbanken nicht konfiguriert oder geändert werden.
6. Ein Clientzugriffsserver-Arrayobjekt muss konfiguriert werden, auch wenn es nur einen Clientzugriffsserver oder einen Einzelserver mit mehreren Rollen gibt.

Verwirrt? Nicht schlimm. Ich werde versuchen, Sie zu erleuchten, indem wir alle diese Punkte einzeln durchgehen. In diesem Artikel tauchen verschiedene Servernamen auf, weshalb ich Ihnen zunächst zeigen möchte, wie ich in meiner Testumgebung arbeite.

Name	Serverrolle	Version
E2K10-MLT-01	Postfach, Clientzugriff, Hub-Transport	Version 14.2 (Build 247.5)
E2K10-MLT-02	Postfach, Clientzugriff, Hub-Transport	Version 14.2 (Build 247.5)
E2K7-MLT-02	Postfach, Clientzugriff, Hub-Transport	Version 8.3 (Build 83.6)
E2003-BE	–	Version 6.5 (Build 7638.2: Service Pack 2)

Lassen Sie uns nun loslegen.

1. Ein Clientzugriffsserver-Arrayobjekt bewirkt keinen Lastenausgleich für Ihren Datenverkehr

Ein Clientzugriffsserver-Arrayobjekt bewirkt keinen Lastenausgleich. Es handelt sich um nichts weiter als ein Active Directory-Objekt, das zum Automatisieren bestimmter Funktionen in Exchange dient. In der Exchange 2010-Dokumentation steht überall, dass empfohlen wird, für den Lastenausgleich von Clientzugriffsserver-Datenverkehr ein Lastenausgleichsmodul zu verwenden. Was meine ich also damit, dass das Clientzugriffsserver-Arrayobjekt keinen Lastenausgleich bewirkt?

Was ein Lastenausgleichsmodul tatsächlich bewirkt, ist das gleichmäßige Verteilen von Datenverkehr auf einen Pool oder vielleicht auch ein Array von Clientzugriffsservern, aber nicht für das Clientzugriffsserver-Arrayobjekt selbst. Der Unterschied ist zwar klein, aber fein. Es wäre vielleicht besser gewesen, die Benennungen deutlicher voneinander abzugrenzen, um diese Verwirrung von vornherein zu vermeiden.

Der Hauptgrund und vielleicht einzige Grund für das Vorhandensein eines Clientzugriffsserver-Arrayobjekts ist das automatische Auffüllen des RpcClientAccessServer-Attributs neuer Exchange 2010-Postfachdatenbanken, die am selben Active Directory-Standort (wie das Clientzugriffsserver-Arrayobjekt) erstellt werden.

Das RpcClientAccessServer-Attribut dient dazu, Outlook-Clients während des Profilerstellungsvorgangs anzugeben, welchen Servernamen das Profil enthalten soll. Mehr gibt's dazu eigentlich nicht zu sagen. Das Clientzugriffsserver-Arrayobjekt ist schlichtweg ein Objekt in Active Directory, das derzeit für keinerlei Lastenausgleich zuständig ist.

Alles Weitere liegt nun an Ihnen, denn Sie können:

• In DNS einen A-Eintrag erstellen, mit dessen Hilfe der Clientcomputer den Hostnamen in eine IP-Adresse auflösen kann. Diese IP-Adresse ist höchstwahrscheinlich die virtuelle IP (VIP) des Lastenausgleichsmoduls, auf das nur interne Clients Zugriff haben. Diese VIP-Adresse ist die Stelle, über die Outlook oder andere MAPI/RPC-fähigen Anwendungen eine Verbindung herstellen, um Zugriff auf Exchange 2010-Postfacheressourcen zu erlangen.
• Die Lastenausgleichslösung so konfigurieren, dass Datenverkehr über die virtuelle IP-Adresse an den Pool mit Clientzugriffsservern übergeben wird.

Die Clientzugriffsserver selbst erkennen nicht, dass irgendein Lastenausgleich erfolgt.

Je nachdem ist es für Sie auch verwirrend, was nach Erstellen eines Clientzugriffsserver-Arrayobjekts vom Cmdlet New-ClientAccessArray oder beim Anzeigen eines bereits vorhandenen Clientzugriffsserver-Arrayobjekts vom Cmdlet Get-ClientAccessArray zurückgegeben wird.

Hier erstelle ich in meiner Testumgebung am Active Directory-Standort Site-A ein neues Clientzugriffsserver-Arrayobjekt mit dem Namen CASArray-A und dem FQDN outlook.lab.local.

Abbildung 1: Erstellen eines Clientzugriffsserver-Arrayobjekts

Zunächst einmal stimmen meine Felder FQDN und Name nicht überein, da der Name ein Anzeigename ist (was rein kosmetische Gründe hat). Sie können einen beliebigen Namen wählen, um den Zweck des Clientzugriffsserver-Arrayobjekts zu beschreiben. Der FQDN ist der Eintrag, den Sie in DNS erstellen müssen, da andernfalls Clients diesen nicht in eine IP-Adresse auflösen können, mit der eine Verbindung hergestellt werden soll. An dieser Stelle weise ich darauf hin, dass es pro Active Directory-Standort nur ein Clientzugriffsserver-Arrayobjekt geben darf.

Doch warum ist die Members-Eigenschaft unmittelbar nach der Erstellung mit zwei Clientzugriffsservern aufgefüllt? Habe ich nicht zuvor erklärt, dass es an dieser Stelle keinen Lastenausgleich gibt? Sieht aus, als hätte ich nicht die Wahrheit gesagt, oder?

Ehrlich gesagt, ist die Members-Eigenschaft ein wenig irreführend. Wenn Sie sich nicht über die Schritte zum Erstellen eines Clientzugriffsserver-Arrayobjekts informiert haben, könnten Sie glauben, Sie wären an dieser Stelle fertig. Sie haben Ihr Clientzugriffsserver-Arrayobjekt erstellt und können sehen, dass zwei Clientzugriffsserver dem Array automatisch beigetreten sind. Dies könnte ein Grund sein, einen heben zu gehen, oder von diesem Typ ein Plätzchen zu klauen. So weit sind wir aber noch nicht, Freunde!

Aufgrund der Tatsache, dass wir das Clientzugriffsserver-Arrayobjekt dem Active Directory-Standort Site-A zugeordnet haben, geht das Cmdlet hin und sucht alle Clientzugriffsserver, die für "Site-A" registriert sind, und listet die gefundenen in der Spalte Members auf. Ich sage Kunden gern, dass sie sich diese Spalte als Potenzielle Members vorstellen sollen. Mein Kollege Kamal Abburi, ein anderer Außendiensttechniker hier bei Microsoft, schlägt für die Spalte die Bezeichnung "Site CAS Members" vor. Sie können anschließend diese Clientzugriffsserver Ihrer Lastenausgleichslösung als Knoten hinzufügen, da sie sich alle am selben Active Directory-Standort befinden. Einen Lastenausgleich gibt es allerdings erst, nachdem das Lastenausgleichsmodul konfiguriert wurde.

Woher wissen die Cmdlets, an welchem Standort sich die Clientzugriffsserver befinden? Gut, dass Sie fragen, denn an dieser Stelle greifen wir auf jedermanns Lieblingstool AdsiEdit.msc zurück und durchsuchen die Partition Konfiguration von Active Directory, um den Stein der Weisen zu finden.

Abbildung 2: Das msExchServerSite-Attribut eines Servers mit Exchange 2010 enthält den Active Directory-Standort, an dem sich der Server befindet

Jeder Server mit Exchange hat ein msExchServerSite-Attribut mit dem Active Directory-Standort, an dem er sich gegenwärtig befindet. Falls Sie sich wundern, ja, dieser wird automatisch aktualisiert, wenn Sie einen Server mit Exchange an einen neuen Standort verschieben und der Active Directory-Topologiedienst von Microsoft Exchange ausgeführt wird, um verschiedene Dinge zu aktualisieren. Doch das AutoDiscoverSiteScope-Attribut (Teil von Get/Set-ClientAccessServer) wird nicht dynamisch aktualisiert, sodass der AutoErmittlungsdienst je nach Standort, Server und Clientlayout ggf. komische Ergebnisse zurückgibt, bis dies behoben ist.

2. Ein Clientzugriffsserver-Arrayobjekt leistet keine Dienste für Outlook Web App, Exchange-Systemsteuerung, Exchange Web Services, AutoErmittlung, IMAP, SMTP oder POP

Lassen Sie uns kurz darauf zurückblicken, welche Aufgabe ein Clientzugriffsserver-Arrayobjekt tatsächlich hat. Es füllt das RpcClientAccessServer-Attribut einer Exchange 2010-Postfachdatenbank auf, das anschließend verwendet wird, um Outlook mitzuteilen, womit bei Verwenden von RPC (über TCP) eine Verbindung hergestellt werden muss. Für Outlook Anywhere- (HTTPS-) Clients gibt es an, womit der Datenverkehr, der den RPC-über-HTTP-Proxy verlässt, im Auftrag des Clients verbunden werden muss, um deren Postfächer zu erreichen.

Mit welchen Diensten versucht also der Outlook-Client eine Verbindung herzustellen, wenn RPC (über TCP) verwendet wird?

Zunächst verbindet sich Outlook am TCP-Port 135 mit dem Clientzugriffsserver-Arrayobjekt für eine Kommunikation mit der RPC-Endpunktzuordnung, um die TCP-Ports zu bestimmen, an denen die beiden folgenden Dienste lauschen.

1. Microsoft Exchange-RPC-Clientzugriffsdienst (alias MSExchangeRPC)
2. Microsoft Exchange-Adressbuchdienst (alias MSExchangeAB)

Das wär's schon für den RPC-über-TCP-Modus!

Outlook Anywhere (alias RPC über HTTP) -Clients verbinden sich am TCP-Port 443 mit der RPC-über-HTTP-Proxykomponente für einen Clientzugriffsserver und lösen dabei den externen Outlook Anywhere-Hostnamen bzw. das auf, was im Outlook-Profil als Proxyserver bezeichnet wird.

Hier noch ein Hinweis für Spezialisten. Outlook fügt dem angegebenen Servernamen automatisch und unbeaufsichtigt/rpc/rpcproxy.dll hinzu, da diese Datei tatsächlich benötigt wird, um eine Verbindung herzustellen. (Doch wenn wir die Leute wie noch in Outlook 2003 auffordern würden, diese Namen einzugeben, können Sie sich vorstellen, wie viele das vergessen oder falsch machen würden?)

Abbildung 3: Angeben der RPC-Proxy-URL in Outlook 2003

Datenverkehr wird über den RPC-über-http-Proxy an den entsprechenden MAPI-/RPC-Endpunkt mithilfe einer Liste hart codierter und nicht dynamisch zugewiesener TCP-Ports weitergeleitet. Dabei handelt es sich um die TCP-Ports 6001, 6002 und 6004. Der externe Outlook Anywhere-Hostname hat absichtlich nicht denselben FQDN wie das Clientzugriffsserver-Arrayobjekt, was ich weiter unten erläutere.

Ein Client baut auch HTTPS-Verbindungen mit Diensten wie AutoErmittlung, Downloads des Outlook-Adressbuchs, Exchange Web Services, POP oder IMAP auf, doch diese Dienste werden mithilfe völlig anderer Methoden definiert, z. B. virtuelle Verzeichnis-URLs oder Wert von AutoDiscoverServiceInternalUri. Für keinen dieser zusätzlichen Dienste leistet das Clientzugriffsserver-Arrayobjekt etwas, da keiner davon RPC verwendet, wenngleich sie wahrscheinlich mit demselben Server eine Verbindung herstellen. Der FQDN des Clientzugriffsserver-Arrayobjekts verwendet ggf. dieselbe virtuelle IP-Adresse wie die URLs der anderen Dienste, doch es wird ausdrücklich empfohlen, dass der FQDN des Clientzugriffsserver-Arrayobjekts nicht identisch mit den URLs der anderen Dienste ist, wenn ein geteiltes DNS verwendet wird. Mehr zur letzten Empfehlung weiter unten.

3. Der vollqualifizierte Domänenname (FQDN) eines Clientzugriffsserver-Arrayobjekts muss nicht Teil der Namensliste des SSL-Zertifikats sein

Dies ist ein häufiges Missverständnis, das zumeist von dem Punkt direkt davor ausgelöst wird. Im Rahmen dieses Artikels werden SSL-Zertifikate nur genutzt, wenn beispielsweise eine durch SSL geschützte HTTP-Sitzung eingerichtet werden soll. Da RPC (über TCP) keine HTTP-Sitzung darstellt, erfolgt kein Schutz durch SSL, weshalb der FQDN des Clientzugriffsserver-Arrayobjekts nicht in die Liste der Antragstellernamen des SSL-Zertifikats einbezogen werden muss. Lassen Sie uns einen Blick darauf werfen.

Die folgende Abbildung zeigt Outlook 2010 im MAPI/RPC-Modus und eine Verbindung mit einem Exchange 2010-Clientzugriffsserver-Arrayobjekt.

Abbildung 4: Outlook 2010- RPC-über-TCP-Verbindungen mit einem Exchange 2010-Clientzugriffsserver

Wie wir sehen, wurden ein Verzeichnis und zwei E-Mail-Verbindungen erstellt. In der Ausgabe von NETSTAT (siehe das überlagerte Bildschirmfoto) erkennen wir, dass der Computer eine Endpunktzuordungsverbindung (TCP-Port 135) mit dem Clientzugriffsserver-Arrayobjekt sowie Verbindungen mit den TCP-Ports 59531 und 59532 aufgebaut hat. Dies sind statisch zugewiesene TCP-Ports für die Dienste MSExchangRPC und MSExchangeAB in dieser Testumgebung.

Auf Serverseite sehen wir mithilfe des Befehls netstat –n –b die lauschenden Dienste.

Abbildung 5: Dienste, mit denen sich Outlook bei Verwenden von RPC (über TCP) verbinden muss

Wie erwartet wird keiner der Dienste über HTTP (an TCP-Port 443) kontaktiert. Aus diesem Grund wird der FQDN des Clientzugriffsserver-Arrayobjekts nicht für das SSL-Zertifikat benötigt.

Die Annahme, dass der FQDN des Clientzugriffsserver-Arrays auf dem SSL-Zertifikat erforderlich ist, wird mitunter dadurch verursacht, wie Outlook Verbindungen im HTTPS-Modus anzeigt (siehe unten).

Abbildung 6: Outlook Anywhere-Verbindungen

Auf diesem Bildschirmfoto erkennen wir, dass Outlook 2010 zwei E-Mail und eine öffentliche Ordner-Verbindung aufgebaut hat und dass wir mit HTTPS arbeiten. In Outlook sieht es so aus, als wären wir mit outlook.lab.local und E2K10-MLT-01.lab.local verbunden, was wir auf gewisse Weise auch sind. Doch bei nochmaliger Verwendung von NETSTAT erkennen wird, dass wir tatsächlich mit dem RPC-über-HTTP-Proxy unter webmail.lab.local am TCP-Port 443 (HTTPS) verbunden sind. Outlook zeigt stets an, mit welchem Server letztendlich eine Datenverbindung besteht (entweder selbständig oder über den RPC-über HTTP-Proxy). Falls Sie sich fragen, warum über NETSTAT sechs anstatt drei Verbindungen angezeigt werden, liegt dies daran, dass HTTP ein Halbduplexprotokoll ist, weshalb für jede in Outlook angezeigte Verbindung ein RPC_DATA_IN- und ein RPC_DATA_OUT-Kanal eingerichtet wird.

Sie mögen jetzt auch denken "Hallo! Outlook 2007 und 2010 verschlüsseln RPC-Sitzungen standardmäßig! Der Name muss auf dem Zertifikat angegeben werden!" Leider falsch, meine Freunde, denn die Verschlüsselungseinstellungen, die Sie unten sehen, arbeitet mit RPC-Verschlüsselung und hat nichts mit SSL zu tun. Die Kommunikation erfolgt weiter über RPC und nicht über HTTPS.

Abbildung 7: Beim Verbindungsaufbau über RPC (über TCP) verwendet Outlook die RPC-Verschlüsselung

"Hey Alter, du brauchst mich, echt! Ich schieb dir ein scharfes Platzhalterzertifikat für wenig Kohle rüber!" Das Clientzugriffsserver-Arrayobjekt würde einfach antworten "Mir doch egal!" und die Zertifizierungsstelle ins Leere laufen lassen. Das gilt dann, wenn Sie unsere Empfehlung befolgt haben, einen FQDN für das Clientzugriffsserver-Arrayobjekt zu verwenden, der sich von dem für die anderen Dienste unterscheidet.

Ich hoffe, der 1. Teil dieses Artikels konnte dazu beitragen, einige gängige Missverständnisse in Bezug auf Clientzugriffsserver-Arrayobjekte zu beseitigen. Verpassen Sie nicht den 2. Teil, in dem wir die restlichen drei gängigen Missverständnisse bei CAS-Arrayobjekten behandeln.

Brian Day
Leitender Außendiensttechniker, Messaging

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Demystifying the CAS Array Object - Part 1