Entmystifizieren des Clientzugriffsserver-Arrayobjekts - 2. Teil

Veröffentlichung des Originalartikels: 29.03.2012

Willkommen zurück! In Entmystifizieren des Clientzugriffsserver-Arrayobjekts - 1. Teil haben wir zum Beginnen der Entmystifizierung des Clientzugriffsserver-Arrayobjekts in Exchange Server 2010 die folgenden drei Punkte behandelt.

1. Ein Clientzugriffsserver-Arrayobjekt bewirkt keinen Lastenausgleich für Ihren Datenverkehr.
2. Ein Clientzugriffsserver-Arrayobjekt leistet keine Dienste für Outlook Web App, Exchange-Systemsteuerung, Exchange Web Services, AutoErmittlung, IMAP, SMTP oder POP.
3. Das Clientzugriffsserver-Arrayobjekt muss nicht Teil des SSL-Zertifikats sein.

Im 2. Teil wollen wir die letzten drei Missverständnisse ausräumen und den Nebel um das Clientzugriffsserver-Arrayobjekt zu lüften, damit Sie vorhandene Bereitstellungen korrigieren und/oder künftige Bereitstellung strategischer planen können.

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.

4. Ein Clientzugriffsserver-Arrayobjekt darf nicht von externen Clients über DNS aufgelöst werden

Wie im 1. Teil mehrfach erwähnt, darf der FQDN Ihres Clientzugriffsserver-Arrayobjekts nicht dem FQDN anderer Dienste wie Outlook Web App, Exchange-Systemsteuerung, Exchange Web Services, Exchange ActiveSync, AutoErmittlung oder dem externen Hostnamen von Outlook Anywhere entsprechen.

Der Hauptgrund dafür ist, dass Outlook Anywhere-Clients zuerst versuchen, den FQDN des Clientzugriffsserver-Arrayobjekts über DNS aufzulösen, damit Outlook weiß, ob eine RPC-über-TCP-Verbindung versucht oder direkt zu HTTPS gewechselt werden soll. Lassen Sie direkte RPC-über-TCP-Verbindungen aus dem Internet mit Ihrem Intranet zu? Ich hoffe nicht, denn falls doch, wird in Ihrem Bericht zum Exchange Risk and Health Assessment Program eine große rote Fahne angezeigt. Wenn der Client zuerst versucht, über RPC (über TCP) eine Verbindung aufzubauen, da er die FQDN des Clientzugriffsserver-Arrayobjekts erfolgreich auflösen kann, könnte es zu einer beträchtlichen Verzögerung kommen, bevor der Client erneut eine HTTPS-Verbindung mit der Proxy-URL von Outlook Anywhere versucht. Diese Verzögerung kann zu vermehrten Anrufen beim Helpdesk führen, wenn die Endbenutzer diese Verzögerung als Leistungsverschlechterung und/oder Dienstunterbrechung wahrnehmen.

Stellen Sie zum Vermeiden dieser Situation sicher, dass der interne FQDN des Clientzugriffsserver-Arrayobjekts für das interne DNS eindeutig ist, z. B. outlook.corp.contoso.com, während für die anderen Nicht-RPC-über-TCP-Dienst-URLs intern und extern mithilfe eines geteilten DNS mail.contoso.com verwendet wird.

Bei einem geteilten DNS handelt es sich um eine Gruppe interner UND externer DNS-Server, die Anforderungen für dieselbe Forward-Lookupzone, z. B. contoso.com verarbeiten. Die beiden DNS-Infrastrukturen sind vollständig voneinander isoliert. Es erfolgen keine Zonenübertragungen, und auch die DNS-Weiterleitungen werden nicht gemeinsam genutzt. Diese Konfiguration ermöglicht internen Benutzern die Nutzung der internen DNS-Infrastruktur zum Auflösen des Hosts mail.contoso.com in eine interne IP-Adresse (z. B. 192.168.1.10), die an die virtuelle IP-Adresse des Lastenausgleichsmoduls geleitet wird, während externe Benutzer diese in die öffentliche IP-Adresse auflösen, die ggf. auf Ihre Forefront TMG/UAG-Infrastruktur mit Schnittstelle zum Internet in Ihrem Umkreisnetzwerk zeigt. Es kommt häufig vor, dass die IP-Adresse des Clientzugriffsserver-Arrayobjekts und die interne IP-Adresse der Nicht-RPC-über-TCP-Dienst-URLs (Outlook Web App, Exchange-Systemsteuerung, Exchange Web Services usw.) derselben virtuellen IP-Adresse des Lastausgleichsmoduls entspricht, wobei jedoch unterschiedliche Aktivitätsprüfungen für eine ordnungsgemäße Dienststatuserkennung verwendet werden.

Gibt Ihr DNS einen Platzhaltereintrag als Antwort zurück?

Ich hatte mindestens einen Kunden mit einem externen DNS-Server, der einen Platzhaltereintrag als Antwort auf Abfragen zurückgab, die für einen nicht vorhandenen Hostnamen eingingen. Man konnte also eine DNS-Anforderung für NichtVorhandenerBeliebigerName.contoso.com senden, woraufhin der DNS-Server stets die IP-Adresse der Website des Unternehmens zurückgab. (Hinsichtlich Standards im Internet sind Platzhaltereinträge uneingeschränkt zulässig. Einzelheiten finden Sie im Abschnitt 4.3.3 in RFC 1034 - Die Redaktion).

Aus diesem Grund konnten ihre Outlook Anywhere-Clients stets den FQDN des Clientzugriffsserver-Arrayobjekts auflösen und versuchten zuerst eine RPC-über-TCP-Verbindung, bevor ein Wechsel zu HTTPS erfolgte. Wenn Sie sich in einer ähnlichen Situation mit einem externen DNS-Server befinden, der für eine bestimmte Forward-Lookupzone Platzhalterantworten verwendet, empfehle ich, diese Forward-Lookupzone für die Outlook Anywhere-Proxy-URL zu vermeiden.

Zwischendurch möchte ich Sie daran erinnern, dass Sie für Ihre Lastenausgleichslösung eine ordnungsgemäße Dienststatusüberwachung konfigurieren sollten. Lassen Sie sich zur Optimierung der Überwachung am besten vom Hersteller der Lösung beraten. Unter Exchange Server 2010 Load Balancer Deployment finden Sie eine Liste der Hersteller von Lastenausgleichslösungen, die Exchange 2010 Lösungstests durchlaufen haben, sowie Links zu deren Websites (für Exchange 2010). Dies soll *keine* definitive Liste von Herstellern unterstützter Lastenausgleichslösungen sein, sondern lediglich eine Liste von Herstellern, die direkt mit Microsoft zu Lösungstest- und Supportzwecken zusammenarbeiten.

Ein Beispiel kann sein, dass für Ihre auf dem HTTPS-Dienst basierenden FQDNs Aktivitätsprüfungen für den TCP-Port 443 ausgeführt werden und die Lastenausgleichslösung das Senden von neuem Clientdatenverkehr an Clientzugriffsserver einstellt, die nicht mehr am TCP-Port 443 reagieren. Für den FQDN des RPC-über-TCP-Diensts des Clientzugriffsserver-Arrayobjekts können Aktivitätsprüfungen für die RPC-Endpunktzuordnung am TCP-Port 135 sowie an den beiden statischen TCP-Ports erfolgen, die Sie für den RPC-Clientzugriffsdienst und den Adressbuchdienst durchführen. Wenn beliebige dieser drei Ports auf einem bestimmten Clientzugriffsserver nicht mehr antworten, sendet die Lastenausgleichslösung keinen neuen Clientdatenverkehr an diesen Clientzugriffsserver für RPC (über TCP), bis alle Ports wieder zu antworten beginnen. Wenn Sie keine statischen TCP-Ports konfigurieren, wählt Exchange beim Programmstart für jeden Dienst einen dynamischen TCP-Port, was Aktivitätsprüfungen für einige Lastenausgleichslösungen schwieriger, wenn nicht unmöglich macht.

5. Ein Clientzugriffsserver-Arrayobjekt darf nach Erstellen von Exchange Server 2010-Postfachdatenbanken nicht konfiguriert oder geändert werden

Allzu oft installieren wir in aller Schnelle die Postfachserver, erstellen die Postfachdatenbanken und beginnen anschließend mithilfe von Jetstress mit der Gültigkeitsprüfung der Speicherlösung. Darf ich vorschlagen, dass Sie einen Moment auf die Bremse treten, um sich dadurch späteren Ärger zu ersparen? Wenngleich die Postfachserver-Rolle von vielen als die wichtigste Serverrolle angesehen wird, hat diese keinen Nutzen, wenn die Vordertür zugenagelt ist, da Sie die Postfachserver nicht über die Clientzugriffsserver erreichen.

Wenn Sie mit dem Erstellen von Postfachdatenbanken beginnen, bevor ein Clientzugriffsserver-Arrayobjekt eingerichtet ist, wird am selben Active Directory-Standort ein beliebiger Clientzugriffsserver angezeigt, der mit dem RpcClientAccessServer-Attribut jeder Datenbank markiert ist.

Anstatt auszusehen, wie es sollte (bei Verwenden des FQDN des Clientzugriffsserver-Arrayobjekt)

Abbildung 1: Beim Erstellen eines Clientzugriffsserver-Arrayobjekts wird die RpcClientAccessServer-Eigenschaft der Postfachdatenbank mit dem FQDN des Clientzugriffsserver-Arrayobjekts aufgefüllt

wird Folgendes gezeigt:

Abbildung 2: Wird das Clientzugriffsserver-Arrayobjekt nicht erstellt, wird die RpcClientAccessServer-Eigenschaft der Postfachdatenbank mit dem FQDN des Clientzugriffsservers aufgefüllt

Clientprofile sehen wie folgt aus...

Abbildung 3: Wird kein Clientzugriffsserver-Arrayobjekt erstellt, werden Outlook-Clients mit dem FQDN des Clientzugriffsservers konfiguriert

Clients verbinden sich wie folgt...

Abbildung 4: Clients verbinden Sie mit dem FQDN des Clientzugriffsservers

Auf den ersten Blick erscheint dies ein überaus harmloser, problemloser Vorgang zu sein, aber Sie müssen sich später auf Ärger gefasst machen. Wenn Sie bei dieser Konfiguration beginnen, Postfächer nach Exchange Server 2010 zu verschieben, verwendet Outlook den Clientzugriffsserver-Namen im Feld Server des Benutzerprofils. Das funktioniert auch, es sei denn, dieser Clientzugriffsserver steht zu einem späteren Zeitpunkt nicht zur Verfügung oder wird außer Betrieb genommen und durch einen Server mit einem anderen Namen ersetzt. Würden Sie nicht auch zu diesem Zeitpunkt lieber einen Lastenausgleichspool mit Clientzugriffsservern nutzen wollen?? Doch, Sie würden!

Sie mögen sich vielleicht denken "Na gut, Schlaumeier, wenn das jemals passieren sollte, erstelle ich ein Clientzugriffsserver-Arrayobjekt und korrigiere das RpcClientAccessServer-Attribut für die Datenbanken, und alles ist in Butter." Ich kann Ihnen versichern, dass dies nur für Postfächer funktioniert, die Sie im Anschluss an die Erstellung nach Exchange 2010 verschieben. Benutzer mit einem bereits vorhandenen Outlook-Profil, das so konfiguriert ist, dass es auf einen Clientzugriffsserver-Namen und nicht auf das Clientzugriffsserver-Arrayobjekt zeigt, verbinden sich weiter mit dem Clientzugriffsserver-Namen, ohne sich selbst so zu ändern, dass der FQDN des Clientzugriffsserver-Arrayobjekts verwendet wird.

Das Profil aktualisiert sich nicht selbst, da der Client keine ecWrongServer-Antwort vom Clientzugriffsserver erhält. Es erhält diese Antwort nicht, da jeder Clientzugriffsserver ein gültiger Verbindungspunkt für beliebige Postfachdatenbanken über RPC (über TCP) ist. Deshalb können Clients Switchover- und Failoverereignisse ohne Neukonfiguration überstehen. Der Administrator muss den DNS-Eintrag des Clientzugriffsserver-Arrayobjekts nur so ändern, dass dieser auf einen noch bestehenden Pool von Clientzugriffsservern zeigt. Derzeit ist die einzige Möglichkeit zum Korrigieren von Postfachprofilen eine manuelle Profilreparatur in Outlook durch Veröffentlichen einer Office PRF-Datei über Gruppenrichtlinienobjekte (funktioniert allerdings nicht bei nicht der Domäne beigetretenen Computern) oder durch Außerbetriebnahme des Clientzugriffsservers, der in den Profilen der Benutzer genannt ist, damit der Endpunkt nicht mehr verfügbar ist. Diese letzte Option sollte (testen, testen, testen!!!) eine vollständige Profilreparatur durch den AutoErmittlungsdienst in Outlook 2007 und Outlook 2010 auslösen. Outlook 2003 kann nur mithilfe einer Profilreparatur oder PRF-Datei repariert werden. Der AutoErmittlungsdienst aktualisiert (zum Zeitpunkt des Verfassens dieses Artikels) ein Profil nicht mit einem neuen Servernamen als Teil des normalen AutoErmittlungsvorgangs, bei dem die Outlook Anywhere-Konfiguration aktualisiert und Exchange Web Services-URLs für andere Features, z. B. die Verwaltung von Abwesenheits-, Frei/Gebucht- und Posteingangsregel-Einstellungen.

Dies bedeutet auch Folgendes: Wenn Sie ein Postfach aus einer Datenbank am Active Directory-Standort "Site-A" mit dem Clientzugriffsserver-Arrayobjekt "Boston-CASArray" in eine Datenbank am Standort "Site-B" mit dem Clientzugriffsserver-Arrayobjekt "Redmond-CASArray" verschieben, dass das Profil nicht aktualisiert wird und das Feld mit dem Servernamen weiter den FQDN von "Boston-CASArray" enthält. Sie sollten dies im Hinterkopf behalten, wenn es Benutzergruppen gibt, die aufgrund eines Arbeitsplatzwechsels an andere Standorte umziehen, oder Sie im Verlauf des Lebenszyklus der Lösung eine massive interne Postfachverschiebung an einen anderen Standort durchführen. Wenn Sie dennoch Exchange 2010-Datenbanken anlegen, bevor Sie ein Clientzugriffsserver-Arrayobjekt erstellen, müssen Sie auf jeden Fall das RpcClientAccessServer-Attribut der Datenbanken so korrigieren, dass das Clientzugriffsserver-Arrayobjekt verwendet wird, ehe Postfächer in die Datenbanken verschoben werden.

6. Ein Clientzugriffsserver-Arrayobjekt muss konfiguriert werden, auch wenn es nur einen Clientzugriffsserver oder einen Einzelserver mit mehreren Rollen gibt

Denken Sie einen Moment darüber nach, was im vorherigen Absatz erläutert wurde. Ein Client übernimmt nicht automatisch ein Clientzugriffsserver-Arrayobjekt, wenn Sie eines zu einem späteren Zeitpunkt hinzufügen. Was gilt, wenn Sie nur einen Clientzugriffsserver haben? Sie meinen vielleicht, dass spiele keine Rolle. Auf der einen Seite könnte man sagen, dass es zum gegenwärtigen Zeitpunkt keine Rolle spielt. Doch warum sich nicht für die Zukunft absichern und sich einige Arbeitszyklen und spätere Probleme ersparen? Was, wenn Sie in genau einem Jahr diesen Clientzugriffsserver ersetzen müssen? Wenn alle Ihre Clientprofile auf einen Clientzugriffsserver-Namen zeigen, gibt es keine saubere Methode für deren Übergang ohne Ausfallzeiten und manuelle Eingriffe. Sie müssen die Profile mithilfe einer der bereits genannten Möglichkeiten nach Hinzufügen eines neuen Clientzugriffsservers reparieren oder den vorhandenen Clientzugriffsserver außer Betrieb nehmen und einen neuen Clientzugriffsserver mit demselben Hostnamen bereitstellen, wodurch es zu Ausfallzeiten kommt. Für mich ist keine dieser Optionen akzeptabel.

Was machen Sie, wenn sich Ihre Geschäftsanforderungen später so ändern, dass für den Clientzugriff eine hohe Verfügbarkeit erforderlich ist? Diese Vorgabe können Sie nur erfüllen, indem Sie einen zweiten Clientzugriffsserver und eine Lastenausgleichslösung hinzufügen. Dann haben Sie wieder dieselbe Situation, in der Sie die Profile der Benutzer mithilfe einer der bereits erwähnten Methoden reparieren müssen, die für mich wiederum nicht akzeptabel sind.

Ich schlage vor, bereits ganz am Anfang ein Clientzugriffsserver-Arrayobjekt zu erstellen. Doch wie soll das gehen, wenn Sie keine Lastenausgleichslösung und nur einen Clientzugriffsserver haben? Ganz einfach! Konfigurieren Sie das Clientzugriffsserver-Arrayobjekt wie gewohnt. Weisen Sie ihm einen Namen, einen Active Directory-Standort und einen FQDN zu, und verweisen Sie anschließend den DNS-A-Eintrag der IP-Adresse zu, die dem einzigen derzeit vorhandenen Clientzugriffsserver oder Einzelserver mit mehreren Rollen entspricht. Sie haben sich dadurch für die Zukunft abgesichert. Wenn Sie jemals den einzelnen Clientzugriffsserver oder Server mit mehreren Rollen ersetzen müssen, reicht es aus, den neuen Server einzurichten und anschließend die IP-Adresse im DNS-Eintrag zu ändern. Wenn Sie zu einem späteren Zeitpunkt für hohe Verfügbarkeit sorgen wollen, müssen Sie lediglich Ihre Lastenausgleichslösung in Betrieb nehmen und anschließend die IP-Adresse im DNS-Eintrag des Clientzugriffsserver-Arrayobjekts so ändern, dass sie auf die virtuelle IP-Adresse der Lastenausgleichslösung verweist. Ganz einfach!

Ich hoffe, dass dieser Artikel einige der Missverständnisse beim Clientzugriffsserver-Arrayobjekt aus dem Weg räumen konnte und langfristig zu einer erfolgreichen Migration zu Exchange Server 2010 beiträgt.

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 2