Client Access Server richtig einsetzen, Teil 2
11. Juli 2011
Die Rolle des Client Access Servers (CAS) spielt bei Exchange Server 2010 einen weitaus wichtigeren Part als bei allen vorherigen Exchange-Versionen. Daher sollte der Exchange-Verantwortliche im Unternehmen darauf achten, dass er diesen Servertyp gleich beim ersten Mal korrekt aufsetzt und somit ungeplante oder gar unnötige Ausfallzeiten vermeidet, die bei einem nachträglichen Umkonfigurieren entstehen könnten.
Bereits im ersten Teil dieser Serie wurde eine Einführung zur Rolle des Client Access Servers bei Exchange Server 2010 und dem Vorgänger, Exchange Server 2007, gegeben. In diesem zweiten Teil des Beitrags geht es um das Bereitstellen und das Installieren dieses Servertypus. Dabei liegt das Augenmerk vor allem auf Exchange Server 2010 – die Unterschiede zu Exchange 2007 werden dabei nicht vernachlässigt.
Im speziellen wird die „manuelle“, GUI-basierte Installation einmal durchgespielt, zudem erfolgt auch das Vorstellen der unbeaufsichtigten Installation. Des Weiteren kommen auch die Vorbedingungen für eine Installation zur Diskussion. Weitere Punkte in diesem Teil sind Themen wie die Koexistenz und der Übergang auf die neuere Version. Denn in vielen Unternehmen müssen die Client Access Server von mehreren Exchange-Versionen in größtmöglicher Harmonie zusammenspielen.
Ehe der Administrator mit dem Installieren der Client Access Rolle beginnt, sollte er sicherstellen, dass sein (oder seine) Server die Voraussetzungen erfüllen. Wer die Vorbedingungen auf seinem System installieren muss, der wird schnell die Vorzüge schätzen lernen, die ein geskriptetes Installieren dieser Module mit sich bringt. Zum einen muss der Administrator dann nicht von Hand eingreifen und zum anderen liegt damit ein wiederverwendbarer und zudem auch in gewisser Weise dokumentierter Ansatz vor.
Vorbedingung Exchange Server 2007 Exchange Server 2010
Dotnet Framework Dotnet 3.0 Dotnet 3.5 SP1
PowerShell Powershell 1.0 Powershell 2.0
Windows Rem. Man. Nicht benötigt WinRM 2.0
Web Server IIS 6.0 IIS 7.0
In der oben aufgeführten Tabelle sind die Voraussetzungen ersichtlich – es sind für Exchange 2007 und Exchange 2010 verschiedene Aspekte nötig. Das Dotnet-Framework, die Windows Powershell und das Windows Remote Management (WinRM) sind für Exchange generell unbedingt nötig. Für die Client Access Rolle müssen noch der Webserver und der RPC-Mechanismus über HTTP (Remote Procedure Call) installiert sein.
Will der Administrator Exchange 2010 auf Windows Server 2008 installieren, muss er zuvor das Servicepack 1 des Dotnet-Framework 3.5 von der Microsoft-Website herunterladen. Dieses Paket gehört zuerst einzeln installiert. Diese Software lässt sich auch ohne Administrator-Eingriff auf das System spielen. Dazu muss man die heruntergeladene, ausführbare Datei mit dem Kommandozeilenschalter /passive aufrufen. Den aktuellen Zustand dieses Installationsvorgangs zeigt die Software allerdings dabei an.
Beim Windows Server 2008 Release 2 (R2) ist das Servicepack 1 des Dotnet-Framework als ein Feature enthalten. Über die Option Features hinzufügen im Server Manager lässt sich diese Funktionalität zum Einsatz bringen. Optional kann der Administrator das auch mit Hilfe der Powershell erledigen. Für die Powershell-Variante muss er zuerst die Powershell mit den geladenen Systemmodulen öffnen (das erfolgt über einen rechten Mausklick auf die Powershell-Applikation und dort ist dann „Import System Modules“ auszuwählen (siehe Abbildung 1).
Diese Option ist aber nur dann verfügbar, wenn man als aktueller Benutzer die Powershell nicht mindestens schon einmal gestartet hat. Nachdem die Systemmodule importiert sind, muss man noch den folgenden Befehl absetzen:
Add-WindowsFeature Net-Framework-Core
Die Powershell 2.0 und WinRM sind beim Windows Server 2008 R2 bereits standardmäßig installiert. Daher gibt es auf dieser Plattform keinen zusätzlichen Aufwand, um diese Komponenten ans Laufen zu bringen. Beim Windows Server 2008 sind sie allerdings zuerst zu installieren. Microsoft stellt die Powershell 2.0 und WinRM in einem einzigen Download zusammengepackt zur Verfügung, als sogenanntes Windows Management Framework Core.
Dabei ist nur die Core-Version dieses Frameworks nötig, nicht die anderen Download-Pakete auf dieser Seite. Das Installieren ohne Benutzereingriff wird dann über das folgende Kommando erreicht:
Windows6.0-KB968930-x64.msu /quiet
Nachdem die korrekte Version des Dotnet-Frameworks und der Powershell installiert sind, gilt es noch zu überprüfen, ob die folgenden Komponenten installiert sind – denn nur danach lässt sich die Client Access Rolle von Exchange auf dem Server installieren:
• Web Server Rolle beim Windows Server 2008
• Web Server: das Feature „basic authentication”
• Web Server: das Feature “Windows authentication”
• Web Server: das Feature “digest authentication”
• Web Server: das Feature “Microsoft IIS 6.0 metabase compatibility”
• Web Server: das Feature”.NET extensibility“
• Web Server: das Feature “IIS 6.0 management console”
• Web Server: das Feature “Internet Server API (ISAPI) extensions“
• Web Server: das Feature “dynamic content compression”
• Windows Process Activation Service: das Feature “process model”
• Remote Server Administration Tools: das Feature “web server tools”
• Dotnet Framework: das Feature “HTTP activation“
• das Feature “RPC over HTTP Proxy“
Gottseidank muss der Administrator diese Komponenten nicht mit Hilfe des Server Managers auf das System aufspielen. Das Exchange-Team bei Microsoft hat diese Aufgabe deutlich vereinfacht. Es gibt einen Satz von XML-Dateien im Verzeichnis Scripts auf der Exchange-DVD. Die Datei Exchange-CAS.xml enthält die Server-Manager-Packages, die man für die Client Access Rolle benötigt. Installieren lassen sich diese Packages mit dem folgenden Kommando:
ServerManagerCmd.exe -ip d:\scripts\Exchange-CAS.xml
Der Befehl ServerManagerCmd.exe ist beim Windows Server 2008 R2 bereits als nicht mehr zeitgemäß charakterisiert – er wird in den folgenden Versionen wohl verschwinden. Doch mit Hilfe der Powershell lassen sich die Pakete ebenfalls installieren. Dazu eignet sich das Cmdlet Add-WindowsFeature, wie es der folgende Befehl zeigt:
Add-WindowsFeature NET-Framework,
NET-HTTP-Activation, RPC-Over-HTTP-Proxy,
RSAT-ADDS, Web-Server,Web-Basic-Auth,
Web-Windows-Auth,Web-Metabase,
Web-Net-Ext,Web-Lgcy-Mgmt-Console,
WAS-Process-Model,RSAT-Web-Server,
Web-ISAPI-Ext,Web-Digest-Auth, Web-Dyn-Compression
-Restart
Dieser Befehl muss in einer Zeile eingegeben werden.
Die Rolle des Client Access Server macht es erforderlich, dass der Dienst
.NET TCP Port Sharing Service (NetTcpPortSharing) von der Startart her auf automatisch gesetzt wird. Dieser Dienst ermöglicht es, dass mehrere Prozesse auf einem Server laufen und dabei nur einen Port verwenden. Dazu wird eine zusätzliche Logikebene zwischen dem Netzwerk und der Applikation eingezogen.
Bei Exchange 2010 verlässt sich der Mailbox Replication Service (MRS) auf das TCP Port Sharing, um so die Verschiebe-Anfragen (Move Requests) zu koordinieren, die von verschiedenen Clients kommen. Dieser Dienst lässt sich von Hand aktivieren (mit Hilfe des MMC-Snap-Ins „Dienste“). Andere Möglichkeiten sind die folgenden Befehle – auf der Kommandozeilenebene von Windows zum Beispiel:
sc config NetTcpPortSharing start= auto
In der Powershell kann auch dieses Cmdlet diese Aktion starten:
Set-Service NetTcpPortSharing -StartupType Automatic
Installation über die grafische Oberfläche
Nachdem nun alle Voraussetzungen abgehakt sind, lässt sich die Rolle des Client Access Servers mit Hilfe des Assistenten installieren. Dabei darf man diese Rolle auch zusammen mit anderen Rollen auf einem Server einsetzen. In diesem Beispiel wird die CAS-Rolle allerdings als einzige Exchange-Rolle auf einem System installiert.
Nach dem Einschieben des Installationsmediums sollte das Installationsprogramm selbstständig los legen. Wenn nicht, muss man setup.exe im Stammverzeichnis der DVD aufrufen. Dabei ist aber zu unterscheiden: Es gibt zwei Setup-Programme: setup.exe und setup.com. Bei setup.com handelt es sich um das „Kommandozeilen-Installationsprogramm“ – der wird später im Beitrag noch besprochen.
Wenn der Administrator setup.exe aufruft, wird man einen Dialog sehen, wie er in der Abbildung 2 (bei einer englischsprachigen Exchange-Version) angezeigt wird. Hier sind dann im Begrüßungsbildschirm die Schritte 1 und 2 bereits ausgegraut. Das ist korrekt, denn diese Punkte wurden bereits durch die vorbereitenden Arbeiten abgedeckt. Daher kann man an dieser Stelle schon zum Schritt 3 gehen und die gewünschte Sprache wählen – hier wird im weiteren Verlauf die Installation der englischsprachigen Version durchgespielt.
Danach geht es zum Schritt 4 – und ab hier übernimmt der Installations-Assistent (Setup Wizard). Der Ablauf ist bekannt: Erst der Begrüßungsbildschirm, dann das Akzeptieren der Lizenzbestimmungen und noch die Option, dass Fehler automatisch an Microsoft übermittelt werden. Dann kommt die Wahl des Installationstyps – hier ist die „Benutzerdefinierte Installation von Exchange Server“ (Custom Exchange Server) anzugeben und auf Weiter zu klicken (siehe Abbildung 3).
Der nächste Dialog geht um die Auswahl von Serverfunktionen (Server Role Selection). Hier ist die Option für die Client Access Rolle anzugeben. Dabei werden die Management Tools automatisch mit selektiert. Da hier nur die CAS-Rolle gewählt wird, sind das die beiden einzigen Optionen, die man benötigt (siehe Abbildung 4).
Danach kommt der Dialog zum Konfigurieren der externen Domänen für den CAS („Configure Client Access Server External Domain“, siehe Abbildung 5). Dieser Dialog ist bei Exchange 2010 neu und erlaubt die Angabe (bereits während der Installation), welchen externen Namensbereich der Client Access Server bedienen soll. Als Teil der Installation werden die virtuellen Verzeichnisse (Virtual Directories) mit diesem externen Namensbereich gleich konfiguriert. Damit spart man sich diese Arbeit hinterher.
Dieser Dialog ist optional und man sollte ihn nur für CAS konfigurieren, die direkt mit dem Internet in Verbindung stehen. Wer einen derartigen Client Access Server konfiguriert und den externen nicht hier angibt, der kann das auch später noch machen.
Die übrigen Dialoge des Assistenten starten den Test zu den Voraussetzungen für den Client Access Server und führen danach die eigentliche Installation durch. Wenn die zuvor angesprochenen Aktionen zu den Voraussetzungen ausgeführt wurden, sollte es beidem Test im Rahmen des Assistenten zu keinerlei Problemen kommen. Nachdem Exchange erfolgreich installiert, sollte ein Bildschirm angezeigt werden, wie er in Abbildung 5 zu sehen ist.
Installation ohne Benutzereingriffe
Durch das Arbeiten mit dem Setup-Assistenten wird die Installation des Client Access Servers vergleichsweise einfach. Will der Administrator aber mehrere Exchange Server mit dieser Rolle installiert bekommen, eignet sich eine weniger interaktive Installationsmethode besser. Dazu gibt es bei Exchange auf dem Installations-Medium das Kommandozeilen-Tool setup.com. Zu diesem Kommando lassen sich Aufruf-Parameter mitgeben oder aber der Administrator gibt eine Antwortdatei vor.
Antwortdateien spielen ihre Vorteile aus, wenn man bei einem Befehl eine Vielzahl von Optionen angeben möchte. Doch solange man keine zusätzlichen Serverrolle auf dem CAS-System installieren oder anpassen möchte, hilft das für die CAS-Rolle nur wenig. Im einfachen Fall – wenn man keine zusätzlichen Setup-Optionen benötigt, lässt sich die CAS-Rolle mit dem folgenden Kommando installieren:
setup.com /mode:install /roles:clientaccess
Wer den Parameter NoSelfSignedCertificates bei seiner Installation verwendet, der stellt sicher, dass die Rolle ohne ein selbst signiertes Zertifikat installiert wird. Das kann sich als nützlich erweisen, wenn man plant, das standardmäßige selbst zertifizierte Zertifikat zu entfernen und durch eines zu ersetzen, das von einer dritten Seite – genauer einer anderen Zertifizierungsstelle stammt.
Man sollte diesen Befehl nur dann verwenden, wenn man ein herausgegebenes Zertifikat einsetzen möchte. Als weiterer Parameter in diesem Kontext empfiehlt sich ExternalCASServerDomain. Dazu dieses Beispiel:
setup.com /mode:install /roles:clientaccess /ExternalCASServerDomain:mail.contoso.com
Mit diesem Parameter kann der Administrator angeben, dass er einen externen Domänennamen für die CAS-Systeme vergibt, die im direkten Kontakt zum Internet stehen. Diese Konstellation wurde bereits beim Arbeiten mit dem Installations-Assistenten angesprochen.
Nachdem das Kommando setup.com ausgeführt wird, erfolgt die Installation unbeaufsichtigt, wie es auch in Abbildung 6 gezeigt ist.
Koexistenz und Übergang
Die Koexistenz und der Übergang von älteren Exchange-Versionen auf Exchange 2010 sind nicht allzu schwierig – wenn man einige grundlegende Dinge verstanden hat. Zum einen ist ein CAS von Exchange Server 2010 nicht in der Lage, mit Exchange 2003 oder Exchange 2007 Postfachservern über MAPI zu kommunizieren.
Die als Kontakt zur Außenwelt fungierenden alten Server benötigen einen unterschiedlichen externen Namensbereich als die CAS-Systeme von Exchange 2010, die als Schnittstelle zur „Außenwelt“ agieren. Dabei werden wohl neue Zertifikate nötig, denn die alten Server haben einen anderen Namensbereich. Nur wenn man ein so genanntes Wildcard-Zertifikat besitzt, braucht man kein neues Zertifikat einkaufen. Beim Übergang sollte man generell die CAS-System zuerst heranziehen, die Zugang zum Internet haben und erst dann die übrigen CAS.
Das Verwalten eines zusätzlichen Namenbereichs gehört zur Koexistenz und zum Migrationsvorgang – das hat aber auch die größten Auswirkungen auf die Konfiguration von Exchange. Da Exchange 2010 so konzipiert ist, dass es mit älteren CAS-Systemen und Frontend-Servern kooperieren kann, wird man üblicherweise für seine Exchange 201 CAS den bestehenden Namensbereich behalten wollen und neue Namensbereiche für die älteren Server hinzunehmen.
Angenommen der externe Namensbereich mit der aktuellen Implementierung (mit Exchange 2007 oder Exchange 2003) lautet mail.contoso.com. Dann wird man üblicherweise diesen Namensbereich für die neue Umgebung mit Exchange 2010 weiter verwenden wollen. Wenn man das so übernimmt, müssen sich die Benutzer nicht eine neue URL für Outlook Web App (OWA, früher als Outlook Web Access bezeichnet) merken oder gar ihre Mobiltelefone oder IMAP/POP3-Clients neu konfigurieren.
Wenn man die älteren Frontend-Server von Exchange 2003 oder die CAS von Exchange 2007 behält (entweder nur vorübergehend oder gar permanent), dann kann es zu Situationen kommen, in denen die CAS von Exchange 2010 einen externen Client auf einen Frontend-Server oder Exchange-2007-CAS umleiten müssen. Damit diese Umleitung funktioniert, benötigen die älteren Server einen anderen externen Namensbereich, wie etwa legacy.contoso.com.
Ist man dann fertig für den Umstieg, kann man seine CAS auf der Basis von Exchange Server 2010 einsetzen, ohne dass man die alte Exchange-Infrastruktur ändern müsste. Dabei ist noch sicherzustellen, dass keine Änderungen am DNS für den externen Produktiv-Namensbereich (wie zum Beispiel mail.contoso.com) gemacht werden, bevor nicht der alte Namensbereich konfiguriert wurde und man soweit ist, dass die externen Benutzer die CAS mit Exchange 2010 nutzen können. Die einzelnen Schritte für das Konfigurieren des alten Namensbereichs unterscheiden sich von Exchange 2007 zu Exchange 2003.
Für die Frontend-Server von Exchange 2003 sind nötig:
DNS-Einträge für den alten Namensbereich (wie legacy.contoso.com) sind zu erzeugen und dann müssen sie auf die mit dem Internet verbundenen Exchange-2003-Systemen verweisen, die die Frontend-Infrastruktur bilden.
Dann ist das Cmdlet Set-OwaVirtualDirectory der Exchange Management Shell zu verwenden, um Exchange 2010 OWA mitzuteilen, wie die alte URL lautet, damit bekannt ist, wohin die Benutzer umgeleitet werden sollen. Dazu ist der Parameter Exchange2003URL auf allen CAS anzugeben, die Exchange-2003-Postfächer für die Verbindung zu OWA haben. Das sieht zum Beispiel wie folgt aus:
Set-OwaVirtualDirectory "CONTOSO-CAS01\owa*" -Exchange2003URL https://legacy.contoso.com/exchange
Wenn ActiveSync zum Einsatz kommt, ist sicherzustellen, dass die integrierte Authentifizierung von Windows für ActiveSync auf den Exchange-2003-Postfachserver aktiv ist. Diese Funktionalität ist nötig, damit der Exchange Server 2003, auf dem ActiveSync läuft, die Anmeldeinformationen nach dem Kerberos-Protokoll akzeptiert, die vom den CAS unter Exchange 2010 verwendet werden.
Dann sind die Zertifikate auf den Exchange-2003-Frontend-Servern zu aktualisieren, so das sie den alten Namensbereich mit einschließen.
Wenn man dann soweit ist, dass die Benutzer die Exchange-2010-CAS verwenden können, sind die DNS-Einträge für den Produktiv-Namensbereich zu ändern, so dass sie auf die Exchange-2010-Systeme verweisen.
Im nächsten Schritt geht es an das erneute Konfigurieren des OAB (Offline Address Book). Falls Clients mit Outlook 2007 oder Outlook 2010 im Unternehmen im Einsatz sind, wird man das OAB auf einen Exchange-2010-Postfachserver verschieben wollen. Damit stehen dann die Vorteile der Web-basierten OAB-Verteilung zur Verfügung. Das macht diese Angelegenheit effizienter als die Verteilung, die auf den öffentlichen Ordnern basiert: Die neue Vorgehensweise benötigt weniger Netzwerkbandbreite.
Auch wenn die Web-basierte OAB-Verteilung von den CAS ausgeführt wird, so läuft die Erzeugung des OAB auf dem Postfachserver. Daher muss man, wenn die Web-basierte Verteilung erwünscht ist, den OAB-Erzeugungsprozess auf einen Exchange-2010-Postfachserver verschieben. Das lässt sich mit dem Cmdlet Move-OfflineAddressBook erledigen.
Outlook 2003 und ältere Clients verwenden nach wie vor die öffentlichen Ordner, um das OAB herunterzuladen. Wenn derartige alte Clients noch in der Umgebung aktiv sind, sollte man sicherstellen, dass die auf den öffentlichen Ordnern basierende Verteilung nach wie vor funktioniert. Das virtuelle Verzeichnis für die Web-basierte Verteilung des OAB wird beim CAS standardmäßig hinzugefügt. Doch der Administrator muss das OAB selbst noch konfigurieren, und dazu das virtuelle Verzeichnis als den Web-basierten Verteilpunkt hinzufügen.
Bei Exchange 2010 eignet sich das Cmdlet Set-OfflineAddressBook, um das virtuelle Verzeichnis für das OAB beim CAS der Liste von virtuellen Verzeichnissen hinzuzufügen, die für das OAB erlaubt sind. Wenn er Administrator diese Änderung ausführt, muss er dabei sicherstellen, dass OABs der Version 4 erzeugt werden.
Zudem müssen alle bestehenden virtuellen Verzeichnisse und das neu dazu kommende eingeschlossen sind, wenn man diesen Befehl ausführt. Alle virtuellen Verzeichnisse, die man dabei auslässt, werden dann aus der Liste gelöscht. Die Befehle sollten in etwa wie folgt aussehen:
Move-OfflineAddressBook
"Default Offline Address Book"
-Server CONTOSO-MBX01
Set-OfflineAddressBook
"Default Offline Address Book"
-VirtualDirectories
"CONTOSO-CAS01\oab*"
Wenn man RPC over HTTP verwendet, muss der Verbindungspunkt zu Exchange 2010 verschoben werden und dann ist RPC over HTTP auf den Servern mit Exchange 2003 abzustellen.
Um einen alten Namensbereich für CAS unter Exchange 2007 anzulegen, sind die folgenden Schritte zu absolvieren:
Die DNS-Einträge für den alten Namensbereich sind anzulegen (wie etwa legacy.contoso.com) und sie müssen dann auf die CAS-Infrastruktur unter Exchange 2007 verweisen, die Anschluss an das Internet haben.
Die externen URLs auf den Exchange 2007 CAS sind zu aktualisieren, damit sie den alten Namensbereich verwenden.
Wenn es soweit ist, dass die Benutzer die CAS von Exchange Server 2010 verwenden können, sind die DNS-Einträge für den produktiv-Namensbereich so zu ändern, dass sie auf die Exchange-2010-Server zeigen. Dabei ist der Eintrag AutoDiscover ebenfalls zu ändern.
Dann ist das OAB neu zu konfigurieren. Dazu eignet sich das Cmdlet Set-OfflineAddressBook – anschließend dürfen die CAS unter Exchange 2010 das OAB verteilen. Das Cmdlet ändert dazu das OAB und fügt den Exchange 2010 Webservice der Liste der virtuellen Verzeichnisse hinzu.
Ähnlich wie beim zuvor beschriebenen Übergang bei Exchange 2003, ist sicherzustellen, dass die Version 4 des OAB Verwendung findet. Auch hier ist darauf zu achten, dass die bereits bestehenden virtuellen Verzeichnisse in der Liste bleiben, wenn man ein neues Verzeichnis aufnimmt – ansonsten werden die nicht aufgeführten Verzeichnisse auch hier ausgelassen. Dazu das folgende Beispiel für den Einsatz der Cmdlets:
Set-OfflineAddressBook
"Default Offline Address Book"
-VirtualDirectories
"CONTOSO-CAS01\oab*"
Dann ist noch Outlook Anywhere auf den CAS unter Exchange 2007 abzuschalten und diese Funktion dafür bei den CAS von Exchange 2010 abnzuschalten.
Der Übergangsprozess für die alte Infrastruktur unterscheidet sich zwischen den verschiedenen Exchange-Umgebungen. Auch wenn hie einzelnen Schritte hierdetailliert beschrieben wurden, sollte man den Übergang in einer Testphase genau prüfen und die Koexistenz-Möglichkeiten genau auf seine Vorgaben hin untersuchen, ehe man eine Exchange-2010-Umgebung in den Produktivbetrieb einführt.
Eingesetzt und bereit für die nächste Stufe
Nach diesen beiden Artikeln zur CAS-Rolle in einer Exchange-Umgebung sollte man für den Einsatz gut gerüstet sein. Die CAS-Rolle verfügt über viele Ebenen. In den nächsten Beiträgen dieser Artikelserie wird eine weitere Ebene angesprochen: Die Hochverfügbarkeit für die CAS. Wer sich noch weiter Informationen zum Übergang des Client Access beim Exchange Server 2010 informieren möchte, dem sei der Blog-Eintrag des Exchange Teams ans Herz gelegt: Transitioning Client Access to Exchange Server 2010.
