Exchange Fragen & Antworten: CAS-Arrays – Serverrollen, Clienterstellung, Lastenausgleich und mehr
Henrik Walther
Erläuterungen zu Serverrollen
Frage: Ich plane ein Upgrade unserer Umgebung von Microsoft Exchange 2007 auf Exchange 2010. Diese Implementierung muss auf allen Ebenen vollständig redundant sein. Da in unserem Unternehmen etwa 3.000 Benutzer arbeiten, beabsichtige ich, Exchange anfänglich auf zwei Computern zu installieren. Jeder wird die Serverrollen Hub-Transport (HT), Clientzugriffsserver (Client Access Server, CAS) und Mailbox (MB) enthalten. Beide werden außerdem Mitglieder einer Database Availability Group (DAG) sein, so dass die Server Datenbanken untereinander replizieren.
Auf Grundlage unserer Erfahrungen mit der aktuellen Exchange-Umgebung weiß ich Folgendes: Wenn die HT- und MB-Rollen sich auf demselben Computer befinden, zieht der Microsoft Exchange-Mailübergabedienst immer den lokalen HT-Server vor. Ebenso wie MB-Server, welche die HT-Serverrolle nicht enthalten, verwendet er an dem Active Directory-Standort keine anderen HT-Server nach dem Roundrobin-Schema.
Wenn das in Exchange 2010 auch so ist, dann haben wir ein Problem. Den Transportpapierkorb auf einem DAG-Mitglied zu speichern, ist nicht sinnvoll. Wenn der Mitgliedsserver ausfällt und für Postfachdatenbanken ein Failover auf das andere DAG-Mitglied stattfindet, können die Nachrichten im Transportpapierkorb nicht erneut übergeben werden.
Antwort: Ich verstehe Ihre Bedenken. Zunächst kann ich Ihnen versichern, dass die Exchange-Produktgruppe diese Art von Szenario in Betracht gezogen hat. In einem frühen Stadium der 2010-Entwicklung hat das Team eine Entwurfsänderung vorgenommen. Wenn der Exchange-Mailübergabedienst feststellt, dass er auf einem Postfachserverabschnitt eines DAG läuft, wird er nicht den lokalen HT-Server bevorzugen. Stattdessen führt er einen Lastenausgleich auf andere HT-Server an demselben Active Directory-Standort aus. Wenn keine gefunden werden, greift er auf den lokalen HT-Server zurück.
Die Abhängigkeit des Exchange-Mailübergabedienstes von der MB-Rolle war nicht das einzige Element, das die Entwickler geändert haben. Sie haben die HT-Rolle so geändert, dass eine Nachricht an einen anderen HT-Server an dem Active Directory-Standort umgeleitet wird, wenn die HT-Rolle auf einem Server installiert ist, der auch die MB-Rolle enthält und Teil eines DAG ist. Mit diesen beiden Änderungen soll hohe Verfügbarkeit sichergestellt werden, wenn HT- und MB-Rollen gleichzeitig auf einem Server vorhanden sind, der auch ein DAG-Mitglied ist.
Clientzugriffsdesign
Frage: Wir entwerfen unsere Exchange 2010-Lösung und müssen festlegen, wie viele Clientzugriffsserver (CAS)-Arrays zu erstellen sind. Wir werden zwei Datencenter mit jeweils eigenem Active Directory-Standort haben. Sollten wir einen pro Standort erstellen, oder ist es sinnvoll, dass jeder über mehrere Arrays verfügt?
Wir werden die Postfachdatenbanken außerdem mit DAGs schützen und werden Kopien von jeder Datenbank auf die beiden Standorte aufteilen. Müssen wir bei einem Failover oder Switchover auf eine Kopie am anderen Standort, bei dem Benutzer gerade verbunden sind, den DNS neu konfigurieren, um die Client auf das CAS-Array dieses anderen Standorts zu verweisen?
Antwort: Die Entscheidung bezüglich der Anzahl der CAS-Arrays dürfte nicht schwer fallen, da Sie nicht mehr als eins pro Active Directory-Standort erstellen können. Wenn Sie es versuchen, erhalten Sie die in Abbildung 1 dargestellte Fehlermeldung.
.png)
Abbildung 1 Die angezeigte Fehlermeldung, wenn Sie versuchen, ein zweites CAS-Array an einem Active Directory-Standort zu erstellen
Da Sie über jedes beliebige CAS-Array in Ihrer Umgebung auf ein Postfach zugreifen können, besteht an sich kein Bedarf für mehr als eins. Selbst wenn Sie weitere erstellen würden, würde nur das erste verwendet.
Was Ihre andere Frage angeht: Solang mindestens ein CAS-Server im CAS-Array an Standort 1 verfügbar ist, brauchen Sie keine DNS-Neukonfiguration vorzunehmen, um Clients nach einem Switchover oder Failover auf das Array des anderen Standorts zu verweisen. Verfügbare CAS-Server an Standort 1 kommunizieren über RPC direkt mit den Postfachservern (auf denen die aktiven Datenbanken für Benutzer an Standort 1 gespeichert sind).
Clienterstellung
Frage: Können Sie mir bewährte Methoden für die Erstellung eines Exchange 2010 CAS-Arrays an einem Active Directory-Standort mitteilen?
Antwort: Ich rate Ihnen, das CAS-Array zu erstellen, bevor Sie Postfachdatenbanken anlegen oder Postfächer auf einen Exchange 2010-Postfachserver an einem Standort verschieben. Exchange 2010-Portfachdatenbanken verfügen über ein Attribut namens „RpcClientAccessServer“. Wenn beim Erstellen der Datenbank kein CAS-Array an dem Active Directory-Standort vorhanden ist, wird diese mit dem Server-FQDN eines Exchange 2010-CAS-Servers an dem Active Directory-Standort gefüllt. Wenn Sie das CAS-Array vor den Postfachdatenbanken erstellen, erhält dieses Attribut stattdessen den FQDN des CAS-Arrays, wie in Abbildung 2 dargestellt.
.png)
Abbildung 2 RpcClientAccessServer-Attribut in einer Postfachdatenbank
Warum ist das eine gute Vorgehensweise? Der Outlook-Client (ob Outlook 2003, 2007 oder 2010) übernimmt die Änderung nicht automatisch. Wenn Sei mit Outlook 2007 oder 2010 arbeiten, können Sie das Profil aktualisieren, indem Sie den alten RPC-Endpunkt deaktivieren oder eine Profilreparatur vornehmen. Jedoch kann Outlook 2003 den Endpunkt nicht ändern und enthält keine Funktion zur Profilreparatur. Dadurch sind Sie gezwungen, das Profil manuell zu ändern, indem Sie den Benutzernamen entfernen, wieder hinzufügen und dann auf die Schaltfläche „Name prüfen“ klicken). Das ist nicht gerade ideal und wirkt sich auch auf Endbenutzer aus. Deshalb sollten Sie wirklich das CAS-Array vorher erstellen.
Lastenausgleich für CAS-Arrays
Frage: Wir beabsichtigen, für unser CAS-Array ein Hardwaregerät zum Lastenausgleich anstelle von Windows NLB zu verwenden. Jetzt fragen wir uns, ob es möglich ist, für den neuen Exchange 2010 RPC-Clientzugriffsdienst statische Ports festzulegen. Gemäß Empfehlung des Anbieters, bei dem wir das Hardwaregerät für den Lastenausgleich erworben haben, sollten wir keine dynamischen Ports verwenden. Wenn wir für diesen Dienst statische Ports festlegen können, empfehlen Sie dann bestimmte Ports?
Antwort: Wie bei den Vorgängerversionen können Sie in Exchange 2010 statische Ports für den RPC-Clientzugriffsdienst festlegen. Das müssen Sie für Exchange 2010 und für den Exchange-Adressbuchdienst tun, weil Outlook mit beiden über MAPI kommuniziert. Öffentliche Ordnerverbindungen werden auch noch für die Postfachserver aufgeführt.
Um einen statischen Port für den RPC-Clientzugriffsdienst auf einem CAS-Server festzulegen, müssen Sie die Registrierung auf jedem CAS-Server in dem CAS-Array öffnen und zu folgendem Verzeichnis navigieren: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC. Erstellen Sie einen neuen Schlüssel namens „ParametersSystem“, und erstellen Sie darunter ein REG_DWORD namens „TCP/IP Port“. Der Wert für das DWORD sollte der gewünschten Portnummer entsprechen (siehe Abbildung 3).
Dies ist für die statischen RPC-Ports keine bewährte Methode, mit Ausnahme der Empfehlung, dass Sie einen nicht zugeordneten und nicht belegten Port Ihres Unternehmensnetzwerks verwenden sollten. Bei Microsoft IT wird TCP/IP-Port 7575 des Unternehmensnetzwerks verwendet. Sie sollten dies auf Ihre eigene Situation anpassen.
Um einen statischen Port für den Exchange-Adressbuchdienst festzulegen, öffnen Sie in Notepad die Datei „microsoft.exchange.addressbook.service.exe.config“, die sich in dem Verzeichnis „C:\Program Files\Microsoft\Exchange Server\V14\Bin“ befindet. Ändern Sie dann den Wert auf den gewünschten TCP/IP-Port. Sie können für den RPC-CA und den Exchange-Adressbuchdienst nicht denselben TCP/IP-Port verwenden.
.png)
Abbildung 3 Konfigurieren eines statischen Ports für den RPC-Clientzugriffsdienst auf einem CAS-Server
Sobald Sie den Port konfiguriert haben, müssen Sie das Microsoft Exchange-Adressbuch und den Microsoft Exchange RPC-Clientzugriffsdienst neu starten. Zum Festlegen eines statischen Ports für öffentliche Ordnerverbindungen gehen Sie genau so vor wie beim Ändern des TCP/IP-Ports für den RPC-Clientzugriffsdienst. Der einzige Unterschied besteht darin, dass Sie den Vorgang auch auf den Exchange 2010-Postfachservern ausführen müssen, weil öffentliche Ordernverbindungen für den RPC-Clientzugriffsdienst auf der Postfachserverrolle ausgeführt werden. Nach Festlegung des Ports für öffentliche Ordnerverbindungen müssen Sie den Microsoft Exchange RPC-Clientzugriffsdienst auf jedem Postfachserver neu starten.
Outlook-Verbindungen
Frage: Ich habe gehört, dass nur Outlook 2007 und 2010 eine Verbindung zu einem RPC-Clientzugriffsdienst oder einem CAS-Array herstellen können. Stimmt das so?
Antwort: In der Vergangenheit war in der Exchange 2010-Dokumentation fälschlicherweise angegeben, dass Sie mit einem Outlook 2003-Client keine Verbindung zum RPC-Clientzugriffsdienst oder zu einem CAS-Array herstellen konnten. Das war ein so genannter Dokumentationsfehler. Outlook 2003-Clients werden vollständig unterstützt. Sie müssen nur sicherstellen, im Outlook-Profil entweder RPC-Verschlüsselung zu aktivieren oder die RPC-Verschlüsselungsanforderung auf den CAS-Server zu deaktivieren. Unter Sicherheitsaspekten empfiehlt Microsoft die Aktivierung der RPC-Verschlüsselung im Outlook-Profil. Das können Sie mit einer Gruppenrichtlinie tun. Die Anleitung hierzu finden Sie in dem KB-Artikel „Outlook-Verbindungsprobleme mit Exchange 2010-Postfächer aufgrund der RPC-Verschlüsselungsanforderung.“
Lastenausgleich mit Windows NLB
Frage: Wenn man den Windows-Netzwerklastenausgleich zum den Lastenausgleich von Datenverkehr zu einem Exchange 2010 CAS-Array einsetzt, muss der FQDN des Windows-Netzwerklastenausgleichs mit dem des CAS-Arrays übereinstimmen?
Antwort: Das ist überhaupt nicht erforderlich. Wenn Sie beispielsweise den Windows-Netzwerklastenausgleich für Datenverkehr zum CAS-Array verwenden, könnten Sie einen FQDN für den Windows-Netzwerklastenausgleich angeben, z. B. „casarray01.contoso.com“, und dem CAS-Array „outlook.contoso.com“ zuweisen. Dies funktioniert gut und wird vollständig unterstützt. Solang der interne DNS-Datensatz für das CAS-Array auf die virtuelle IP-Adresse des Windows-Netzwerklastenausgleichs verweist, dürften keine Probleme auftreten.
Henrik Waltherist Microsoft Certified Master: Exchange 2007 und Exchange MVP mit über 15 Jahren Erfahrung in der IT-Branche. Er ist als Technology Architect für Timengo Consulting (ein Microsoft Gold Certified Partner aus Dänemark) und als technischer Autor für Biblioso Corporation (eine in den USA ansässige Firma, die sich auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert hat) tätig. Sie können Henrik Walther unterexqa@microsoft.com erreichen.