Client Access Rolle des Exchange Servers, Teil 1
14. Juni 2011
Die Rolle des Client Access gab bereits beim Exchange Server 2007 ihr Debüt. Doch beim Exchange Server 2010 kommt mehr Verantwortung für diese Rolle ins Spiel. Sie ist nun für das Abwickeln sämtlicher Client-Verbindungen zuständig. Einzig wenn sich Clients mit öffentlichen Ordnern verbinden, läuft das nicht über die Client Access Rolle. Da diese Rolle nun noch mehr Bedeutung bekommen hat, sollte man ihre Funktionsweise verstehen und daraus auch ableiten können, wie man den Einsatz dieser Rolle optimieren kann.
Mit diesem Beitrag startet eine Artikelreihe, die sich um Exchange 2010 kümmert und dabei zunächst die Client Access Rolle und dann die anderen Rollen dieses Servers genau beleuchtet. Dabei sind neben den besten Einsatzbeispielen und Konfigurationsmöglichkeiten auch Aspekte wichtig, die sich um den Bereich Sicherheit der Exchange-Infrastruktur drehen.
|
Bei der Rolle des Client Access handelt es sich um eine von fünf möglichen Rollen eines Exchange Servers. Diese Rolle kann bare auch auf demselben Server zum Einsatz kommen wie die Rollen Postfach (Mailbox), Hub Transport und Unified Messaging. Ganz egal, wie die Kombination der Rollen auf einem System aussieht, der verantwortliche Administrator muss sicherstellen, dass die Hardware-Ausstattung passt, um die Belastung durch die verschiedenen Rollen abarbeiten zu können. Hier gilt es die einzelnen Faktoren – Prozessoren, Arbeitsspeicher, Festplatte und Netzwerkverbindungen – bestmöglich zu dimensionieren. Je nachdem welche Rollen auf einem System gruppiert sind, ergeben sich auch Einschränkungen in Bezug auf die machbaren Sicherheitsrichtlinien oder das Abhärten des Systems. Angenommen die Rollen Postfach und Client Access laufen zusammen auf einem Server, dann wird die Postfach-Rolle leichter anzugreifen sein, denn es müssen für die andere Rolle zusätzliche Dienste installiert und nach außen hin bereitgestellt werden. Jede Rolle bringt ihre eigenen Zuständigkeiten mit ein – und der Client Access Server zeichnet sich nicht durch eine geringe Arbeitslast aus. Viele Administratoren sind der Meinung, dass diese Rolle nur ein Interface für den Web-basierten Mail-Zugriff bietet. Doch es kommt beim Client Access –vor allem ab Exchange 2010 – weitaus mehr dazu. Beim Exchange Server 2007 wurde die Rolle Client Access eingeführt, um einen Teil der Last von den Postfach-Servern weg zu nehmen. Zudem wollte man einen gemeinsamen Eingangspunkt in die Exchange-Organisation haben, der alle Client-Protokolle abhandeln kann. Dazu gehören die Verbindungen, die über den Web-Browser, über Mobiltelefone und von Mail-Clients, die sich über das Internet anbinden. Damit besteht auch die Möglichkeit, die Postfach-Server sicherer zu machen. Denn dadurch müssen auf diesen Systemen keine Dienste aktiv sein, die für die externen Clients nötig sind – außer es wird bereits mit Hilfe von Reverse-Proxy-Servern eine derartige höhere Sicherheitsstufe erreicht. Um die gewünschten Verbindungspunkte herzustellen, verwendet ein Client Access Server eine Mischung von Windows-Diensten und „Web Virtual Directories“, die durch den IIS (Internet Information Services) bereitgestellt werden. Die Virtual Directories eines Client Access Servers sind im linken Bildschirmbereich des IIS Manager (siehe Abbildung 1) zu sehen. Einige dieser Dienste sehen wahrscheinlich bekannt aus, doch was die anderen machen, lässt sich nicht so leicht erkennen. Client Access unter Exchange 2010Mit der Version von Exchange 2010 gab es bei der Rolle Client Access einige neue Funktionalitäten und einige bestehenden wurden verbessert. Dazu kamen noch Optimierungen bei den benötigten Schnittstellen, um dem Exchange-Administrator das Leben zu vereinfachen. Bei den Virtual Directories sind zwei neue Vertreter dazugekommen, die auf der Web-basierten Architektur aufsetzen, die bereits bei Exchange 2007 Verwendung fand. Das Exchange Control Panel (ECP) bietet ein neues Interface für die Browser-basierten Email-Clients. Das ECP arbeitet im Zusammenhang mit Outlook Web App (OWA, früher als Outlook Web Access bezeichnet). Damit bekommen die einzelnen Benutzer mehr Möglichkeiten eingeräumt, was die Kontrolle über ihre Postfächer angeht. Benutzer können nun ihre Kontaktinformationen in der GAL (Global Address List) ändern und die Verteilergruppen, die zu ihnen gehören, über das ECP ändern. Haben Benutzer über die RBAC (Role Based Access Control) administrative Rollen zugewiesen bekommen, können sie diese zusätzlichen Verwaltungsaufgaben für die Exchange-Organisation ausführen. Dazu gehört das Suchen über mehrere Postfächer und das Zuweisen von Rollen für andere Benutzer. Abbildung 2 zeigt wie diese zusätzlichen Möglichkeiten als weitere Reiter in der Benutzerschnittstelle des ECP realisiert sind. Das zweite Virtual Directory, das beim Client Access Server von Exchange 2010 eingeführt wurde, ist die Remote Powershell. Damit lässt sich von jedem Rechner mit einer SSL-Verbindung, die EMS (Exchange Management Shell) auf dem Client Access Server ansprechen. Da diese Kommunikation über das Protokoll HTTPS läuft, können auch Computer außerhalb des Unternehmensnetzwerks diese Verbindung erstellen. Damit werden die Kommandos zwar auf dem entfernten System aufgerufen, doch ausgeführt werden sie auf dem Client Access Server. Damit kann man mit der Remote Powershell seinen 64-Bit-Exchange-Systeme von Computern aus verwalten, die mit 32-Bit-Betriebssystemen (wie die entsprechenden Versionen von Windows 7, Windows Vista Servicepack 1, und Windows XP mit Servicepack 3) arbeiten. Die einzigen Vorbedingungen für diese Client-Systeme, die auf die Remote Powershell des Exchange-Servers zugreifen wollen, lauten: Windows Remote Management (WinRM) in der Version 2.0 und die Windows Powershell 2.0 müssen installiert sein. Diese Komponenten werden über das Windows Management Framework bereitgestellt. Nachdem man dieses Framework heruntergeladen und es auf seinen Clients installiert hat, muss man auf ihnen die Exchange Management Tools nicht mehr installieren. Zudem müssen die Clients auch keine Mitglieder in der entsprechenden Domäne sein. Die Authentifizierung erfolgt über die Remote Powershell, indem ein Session Objekt erzeugt wird und dabei der URI (Uniform Resource Identifier) für den Powershell Web Service angegeben wird, wie es der folgende Befehl zeigt: $Session = New-PSSession Hierbei ist zu beachten, dass der Befehl auf mehrere Zeilen verteilt wurde – das muss bei der Eingabe des Kommandos auf dem System in einer Zeile erfolgen. Zusätzlich zur Authentifizierung über Kerberos (für die allerdings eine Verbindung mit der Domäne bestehen muss) unterstützt die Remote Powershell noch andere Optionen, wie NTLM, die basic und Digest Authentication sowie das CredSSP-Protokoll (Credential Security Support Provider). Der Client Access Server bestimmt welche RBAC-Rollen man besitzt und präsentiert einem dann auch nur die EMS-Cmdlets und Parameter, die für diese Rollen gelten. Angenommen man besitzt die Rolle „Mailbox Import Export“ nicht, dann wird auch der Zugriff auf das Cmdlet Export-Mailbox nicht gegeben sein. Zusätzlich zu den neuen Virtual Directories bringt Exchange 2010 auch noch einige neue Windows-Dienste für die Client Access Rolle ins Spiel, die eine große Auswirkung auf die Client-Anbindung haben. Der wichtigste von ihnen ist der Service RPCCA (RPC Client Access). Er verlegt den Verbindungpunkt für MAPI-RPC vom Mailbox-Server auf den Client Access Server. Die Clients sprechen mit dem Client Access Server mit Hilfe von RPC (Remote Procedure Call). Und der Client Access Server führt dann anstelle des Benutzers die MAPI-RPC-Verbindung aus. Dazu verwendet der Client Access Server die Active Manager Client-Komponente und bestimmt so, welcher Postfach-Server die Datenbank des Benutzers enthält. Dann verbindet er sich mit dieser Datenbank und agiert quasi als Broker für den MAPI-Verkehr. Clients mit Outlook 2010 und Outlook 2007 können sich mit RPCCA bereits standardmäßig verbinden. Wer dagegen noch Outlook 2003 verwendet, der muss die Verschlüsselungseinstellungen ändern. Das lässt sich beim Outlook-Client entweder mit Hilfe der Gruppenrichtlinien erledigen oder aber man stellt das von Hand im Outlook-Profil ein. Eine weitere Option dazu ist das Abschalten der Verschlüsselungsanforderung auf dem Client Access Server – doch das wird man nur in den seltensten Fällen empfehlen können. Um diese Änderung auszuführen, muss man den folgenden Befehl in der EMS aufrufen: Set-RpcClientAccess Durch das Verschieben des MAPI-Endpunkts für die internen Outlook-Clients auf den Client Access Server lassen sich einige neue Funktionen realisieren. Eine der wohl am meisten erwarteten sind das Verschieben von Postfächern im Online-Betrieb und ein verbessertes „Failover“. Das „Failover“ bei den Datenbanken lässt sich nur erzielen, wenn die Postfachserver in einer DAG (Database Availiability Group) liegen. Der Exchange Replication Service (MSExchangeRepl) überwacht die Datenbanken und berichtet Ausfälle an die Komponente Active Manager, die auf dem Postfachservern in einer DAG läuft. Wenn sich dann die aktive Kopie der Datenbank ändert, aktualisiert der MSExchangeRepl die Client-Komponente des Active Managers im RPCCA-Dienst. Da sich nun alle Outlook-Clients mit dem Client Access Server direkt verbinden, können die Postfächer zwischen den Datenbanken verschoben werden – beziehungsweise sogar zwischen den Postfachservern während der Benutzer angemeldet ist und mit Outlook arbeitet. Denn der Client Access Server kümmert sich um das Verschieben der Postfächer und erledigt diese Aufgabe mit Hilfe des Mailbox Replication Service (MRS). Dieser Prozess agiert asynchron, daher kann man eine Verschiebe-Anforderung erstellen und dann weiterhin arbeiten, während der Client Access Server die eigentliche Arbeit ausführt. Beim Online-Verschieben der Postfächer werden sowohl der Online Mode als auch der Cached Mode unterstützt. Doch es lässt sich weitaus besser arbeiten, wenn man die Clients im Cached Mode betreibt. Wenn der Administrator ein Postfach von einem Exchange 2007 mit Servicepack 2 auf eine Datenbank bei Exchange 2010 oder aber wenn er das Postfach auf eine Datenbank unter einem anderen Exchange Server 2010 verschiebt, dann gibt es keine Rekonfiguration des Profils, keine Änderung der DNS-Einträge und kein Warten auf die Replikation durch das Active Directory (AD). Da der Benutzer an den Client Access Server angebunden ist, muss nur dieser Server wissen, wo sich die betreffende Datenbank für dieses Benutzerkonto im AD befindet. Wenn das Verschieben des Postfachs angestoßen wird, erfolgt eine Aktualisierung der AD-Attribute und der Client Access Server an diesem Standort bekommt die Information, dass dieser Verschiebevorgang sich in Ausführung befindet. Um den kompletten Übergang zum RPCCA zu machen, muss noch ein weiterer Dienst auf den Client Access Server verlegt werden. Bei Exchange wird der Zugriff auf das Verzeichnis für die Clients über das NSPI (Name Service Provider Interface) abgewickelt. Bei Exchange 2007 und früheren Versionen wurden die Bezüge zu einem NSPI-Endpunkt von der Komponente DSProxy bereitgestellt. Bei Exchange 2010 wird DSProxy durch den neuen Service „Address Book“ ersetz, der auf dem Client Access Server zum Einsatz kommt. Durch dieses Verlagern bekommt man zusätzliche Freiheiten, denn nun muss keine direkte Verbindung von Outlook zu den Postfachservern bestehen. |
Nachdem nun die grundlegenden Charakteristika der Rolle des Client Access Server geklärt sind, sollte man diese Eigenheiten in die Planung seiner Infrastruktur für den Client Access einbeziehen.
Das Planen der Client-Access-Infrastruktur
Die erste Fragestellung konzentriert sich darauf, wo man diese Server platzieren soll. Die Antwort auf diese Frage ist schon von Exchange 2007 her bekannt: Am besten überall! Die Client Access Server kommunizieren mit den Postfachservern über das Protokoll RPC. Daher kann ein Client Access Server nur am selben Standort mit einem Postfachserver eine Verbindung erstellen.
Aufgrund dieser Einschränkung gilt als eine Voraussetzung für Exchange 2010, dass man zumindest einen Server hat, der in jedem AD-Standort, in der ein Postfachserver liegt, diese Rolle beherbergt. Diese Vorgabe erweist sich als kein Problem, wenn man den Zugriff nur für Benutzer innerhalb des Unternehmensnetzwerks einrichten muss.
Sollen aber auch andere Benutzer von außen den Zugriff auf ihre Mail bekommen – etwa durch OWA (Outlook Anywhere), über POP/IMAP oder über Active Sync – dann muss man sich mehr Gedanken darüber machen, wo die Client Access Server residieren sollen.
Steht die Entscheidung an, welche Client Access Server an das Internet anzuschließen sind, gehört die Berücksichtigung des externen Namespace zu den wichtigsten Überlegungen. Verfügt das AD über mehr als einen Standort mit einem Client Access Server, der Anschluss an das Internet hat, dann wird es schwer, mit einem einzigen Namespace auszukommen. Um den Grund dafür zu verstehen, muss man sich zwei wichtige Parameter bei den Virtual Directories ansehen: InternalURL und ExternalURL.
Die InternalURL enthält die URL, die von den Clients im internen Netzwerk benutzt wird, die ExternalURL dagegen die, die Clients im Internet verwenden. Zum Beispiel könnte das bei OWA https://mail.contoso.com/owa sein. Wenn man nun mehrere Client Access Server mit Anschluss an das Internet betreibt, dann müssen sie alle ihre eigene ExternalURL für ihre Virtual Directories definiert haben.
Um die Auswirkung dieser Einstellungen zu zeigen, kann man sich folgendes überlegen: Der Benutzer Lincoln, der ein Postfach im Standort Baltimore auf BAL-MB01 besitzt, greift auf einen Client Access Server in Seattle (mit dem Servernamen SEA-CAS01) zu. Wenn Lincoln versucht, OWA auf SEA-CAS01 zu verwenden, bemerkt der Client Access Server, dass das Postfach von Lincoln in Baltimore liegt.
Wenn nun BAL-CAS01 etwas im Feld für die ExternalURL für OWA eingetragen hat, dann weiß SEA-CAS01, dass BAL-CAS01 über einen Anschluss an das Internet verfügt und leitet Lincoln um, so dass er die ExternalURL für BAL-CAS01 verwendet. Wenn BAL-CAS01 dagegen nichts als ExternalURL eingetragen hat, verwendet SEA-CAS01 die auf BAL-CAS01 definierte InternalURL, um sozusagen als Proxy die Verbindung für den Benutzer herzustellen. Falls der Benutzer in dieser Proxy-Konstellation eine Nachricht in OWA öffnet, würde die Anfrage nach dieser Message vom Benuter an SEA-CAS01 an BAL-CAS01 gegeben werden und dann an den Postfachserver geleitet, auf dem das Postfach für den Benutzer (also auf das System BAL-MB01) liegt. In Abbildung 3 ist dieser Vorgang zu sehen.
Die Frage nach den Namespaces
Daraus ist zu erkennen, dass es durchaus Sinn macht, wenn man mehrere Client Access Server mit Internet-Zugang hat, für jeden Standort einen eigenen Namespace zu betreiben. Würde man alles mit demselben Namespace betreiben wollen, würde die ExternalURL nicht immer korrekt auflösen und so den Standort bestimmen, in dem das Postfach des Benutzers liegt.
Der andere Ansatz – durchaus häufiger anzutreffen – lautet: Der Zugang ins Internet wird den Client Access Server nur über einen Standort ermöglicht. Und ihr Zugang wird dann für alle Benutzer nur über einen einzigen Namespace gemacht. Falls ein Postfach eines Benutzers nicht in diesem Standort liegt, wird die Verbindung in Proxy-Manier an den Client Access Server weitergeleitet, der im richtigen Standort (sprich dem mit der Internet-Anbindung) liegt.
Das Dimensionieren der Server
Nachdem nun klar ist, wo die Client Access Server liegen sollen, steht noch die Entscheidung an, wie viele es geben soll und über welche Hardware-Ausstattung sie verfügen sollten. Zuerst muss man allerdings feststellen, dass das richtige Dimensionieren der Client Access Server mehr eine Kunst als eine klar definierte Wissenschaft ist.
Nur in recht einfachen Umgebungen kann man genau vorhersagen, wie viele Benutzer sich mit den Client Access Servern verbinden, wie häufig das der Fall ist und welche Protokolle dabei zum Einsatz kommen. Denn all diese Faktoren müssen in die Gleichung aufgenommen werden, wenn man errechnen möchte, wie viele Server nötig sind.
Denn leider ergeben 10.000 Benutzer, die sich über OWA anbinden, nicht dieselbe Last wie 10.000 Anwender, die Outlook Anywhere oder Active Sync verwenden. Und es wird noch schwieriger, da noch weitere Faktoren ins Spiel kommen, die mit der Rolle des Client Access gar nichts zu tun haben und trotzdem eine langsame Verbindung der Clients zur Folge haben – wie zum Beispiel die Einschränkungen für TCP/IP-Verbindungen oder aber ein schlecht implementiertes AD.
Microsoft stellt selbst einige generelle Vorgaben für die Dimensionierung der Client Access Server zur Verfügung. Doch dabei handelt es sich lediglich um generelle Werte, die nicht auf spezielle Anforderungen passen, wie sie in verschiedenen Unternehmen vorkommen. Eine Informationsquelle dazu ist der Technet-Beitrag „Understanding Exchange Performance“.
Die Vorgaben von Microsoft setzen voraus, dass die Rolle des Client Access Server die einzige Rolle auf einem Server ist. Dann wird vorgegeben, dass man drei Prozessorkerne in einem Client Access Server für vier CPU-Kerne in einem Postfachserver im selben Standort benötigt.
Angenommen es liegen zwei Postfachserver in einem Standort und jeder dieser Postfachserver verfügt über 8 Prozessorkerne (das ergibt insgesamt 16 CPU-Kerne). Dann sollte die Anzahl der gesamten „Client Access Kerne“ in diesem Standort bei mindestens 12 liegen – sprich man müsste drei Server mit jeweils 4 Prozessorkernen einsetzen, oder zwei Server mit jeweils 6 Kernen, oder 6 Server mit zwei Kernen.
In Bezug auf den Arbeitsspeicherausbau bei den Client Access Servern von Exchange sollte man als Minimum von 4 GByte ausgehen. Als weitere Faustregel gelten 2 GByte für jeden CPU-Kern – bis zu einem Maximum von 16 GByte. Angenommen ein Client Access Server verfügt über 4 Prozessorkerne, dann sollten 8 GByte im Server zum Einsatz kommen.
Mit diesen Vorgaben kann man in seiner individuellen Umgebung beginnen, doch nach einer Testphase und eigenen Untersuchungen muss man dann schauen, ob der Client Access Server mit diesem Arbeitsspeicherausbau in der konkreten Client-Infrastruktur auch richtig skaliert.
Diese Testphase bezieht sich auf viele Aspekte. Zuerst gilt es zu verstehen, über welche Protokolle die Clients sich mit dem Client Access Server verbinden. Dabei kann sich der Client-Verkehr zusammensetzen aus MAPI, Outlook Anywhere, Active Sync, EWS (Exchange Web Service) und OWA.
Wer derzeit noch Exchange 2007 verwendet, der kann diese Informationen mit einigen relativ einfachen Performance-Überwachungsaktionen auf seinen bestehenden Postfachservern (für den MAPI-Verkehr) und auf den Client Access Servern (für alle anderen Protokolle) herausbekommen.
Dazu gibt es Performance Counter für jedes dieser Protokolle. Das Protokollieren der Daten lässt sich über Tag, Wochen oder gar Monate machen, so dass man ein gutes Verständnis bekommt, welche Clients mit welchen Protokollen auf ihre Nachrichten zugreifen. Je länger man diese Daten im Vorfeld sammelt, umso genauer wird die Abschätzung sein. Zusätzlich zum Performance Monitor kann man auch noch Tools wie den Exchange Server User Monitor einsetzen.Dieses englischsprachige Tool hilft ebenfalls beim Analysieren des MAPI-Verkehrs.
Nachdem diese internen Statistiken vorliegen, muss der verantwortliche Administrator diese Werte heranziehen, um seine Umgebung passend zu dimensionieren. Dann ist die gefundene Hardware-Konfiguration in einer Testumgebung einzusetzen und dann mit der erwarteten Last und den entsprechenden Protokollen zu untersuchen, ob diese Dimensionierung auch wirklich passt.
Die 2010-Version des Exchange Load Generator ist als 64-Bit-Version bereits verfügbar. Damit lässt sich die Simulation des Client-Verkehr und der zugehörigen Protokolle machen. Aus diesen Tests kann der Administrator dann die Flaschenhälse seines Systemdesigns erkennen und an den entsprechenden Stellen mit zusätzlichen Hardware-Ressourcen nachlegen. Aber auch ein Nachrüsten mit weiteren Client Access Servern lässt sich dann noch machen, ohne dass die Produktivumgebung darunter zu leiden hat.
Fertig für den Einsatz im Produktivbetrieb
Die Rolle des Client Access Servers bei Exchange 2010 oder Exchange 2007 ist ein wesentlicher Eckpunkt in der Konzeption der Client-Infrastruktur einer Exchange-Organisation. Auf diesem grundlegenden Wissen folgen in lockerer Reihenfolge weitere Beiträge, die zeigen, wie sich diese Rolle optimal einsetzen lässt.
