To-do-Liste: Vorbereitung der Migration auf Exchange 2013

Von Active Directory bis Service Packs gibt es vor der Migration zu Exchange 2013 einige Aufgaben zu erledigen. Eine Übersicht der wichtigsten To-dos.

Nicht nur die Migration auf Exchange Server 2013, sondern auch die Vorbereitungen dazu verursachen einen großen Arbeitsaufwand. In dieser To-do-Liste werden die vier wichtigsten Aufgaben erläutert, die erledigt werden müssen, bevor man einen Exchange-Server-2013-Client-Access-Server in einer Exchange-2010-Umgebung installieren kann.

Aufgabe 1: die richtigen Service Packs für Exchange 2010/2013 installieren

Der erste Punkt auf der To-do-Liste betrifft die installierten Service Packs (SP). Beachten Sie, dass Exchange Server 2010 die richtigen Service Packs vor der Migration zu Exchange 2013 benötigt. Alle Exchange-2010-Server müssen mit dem SP3 für Exchange 2010 ausgestattet sein. Ohne dieses Service Pack arbeitet Exchange 2010 nicht mit Exchange 2013 zusammen.

Wenn Ihr Exchange-Server mehrere Active Directory-Standorte umfasst, müssen Sie das Service Pack auf sämtlichen Exchange-Servern installieren, die mit dem Internet verbunden sind. Anschließend installieren Sie das Service Pack auf allen anderen Exchange-Servern und warten die Replikation ab.

Sobald Sie Ihre Exchange-2010-Server mit der richtigen Service-Pack-Version aktualisiert haben, laden Sie für Exchange Server 2013 das Service Pack 1 (siehe „Alle Einzelheiten zum Service Pack 1“) herunter. Dieses Update ist für die reibungslose Zusammenarbeit von Exchange Server 2010 und Exchange Server 2013 erforderlich. Zwar funktioniert die Zusammenarbeit bereits mit dem kumulativen Update 1 (CU1) und CU2 für Exchange 2013, allerdings enthält das SP1 noch einige Fehlerbehebungen. Außerdem können Sie mit dem SP1 für Exchange 2013 den Server komplett installieren, ohne zuvor Exchange installieren zu müssen. Dazu kommt, dass in SP1 für Exchange 2013 jetzt die Edge-Transport-Rolle integriert ist und Sie den Server auf Basis von Windows Server 2012 R2 installieren können.

Damit Exchange 2013 beispielsweise auch mit Exchange 2007 zusammenarbeitet, brauchen Sie das SP3 für Exchange 2007 und mindestens das Update Rollup 10 für SP3. Besser ist es aber, wenn Sie das aktuelle Update Rollup 14 einsetzen.

Aufgabe 2: Active Directory vorbereiten

Vor der Installation von Exchange 2013 in eine bestehende Organisation sollten Administratoren das Schema, die Gesamtstruktur und die Domänen vorbereiten.

Die zweite Aufgabe auf der Liste beschäftigt sich ausführlicher mit Microsofts Verzeichnisdienst Active Directory (AD). Nach der Aktualisierung der bestehenden Exchange-Server müssen Sie vor der Migration auf Exchange 2013 auch Active Directory aktualisieren. Hierfür benötigen Sie administrative Rechte auf der Ebene der Gesamtstruktur und auf der Domain-Ebene. Das Konto, das Sie verwenden, muss zusätzlich über Schema-Admin-Berechtigungen verfügen. Hier ist zu beachten, dass das SP1 für Exchange 2013 Schema-Aktualisierungen vornimmt und die Schemata von Exchange 2013 erweitert.

Es ist technisch möglich, die Vorbereitung der Active Directory zu überspringen, da das Exchange-Server-Setup später erkennt, ob Active Directory bereit ist. Falls Sie die richtigen Berechtigungen verwenden, werden Schema, Gesamtstruktur und Domänen später automatisch vorbereitet. Viele Unternehmen ziehen es jedoch vor, Active Directory vor der Migration vorzubereiten. Das hat den Vorteil, dass die Exchange-Installation weniger fehlerbehaftet ist und die Domänen-Controller die notwendigen Daten kennen. Dazu wird die Setup-Datei des SP1 mit folgenden Befehlen gestartet:

Setup /PrepareSchema /IAcceptExchangeServerLicenseTerms

Setup /PrepareAD /IAcceptExchangeServerLicenseTerms

Setup /PrepareDomain /IAcceptExchangeServerLicenseTerms

Aufgabe 3: temporäre Exchange-Server einrichten

Als dritte Aufgabe ist die Einrichtung eines temporären Exchange-Servers zu empfehlen, zum Beispiel auf Basis einer virtuellen Maschine (VM). Diese sollten Sie für die erste Exchange-Server-2013-Bereitstellung nutzen. Idealerweise wird diese Bereitstellung als Alternative in der Produktion direkt ausgeführt. Dieser Schritt ist allerdings optional, Sie können auch direkt einen produktiven Server installieren.

Die meisten Exchange-Server-Bereitstellungen in produktiven Umgebungen – mit Ausnahme etwa von Bereitstellungen in kleinen Firmen – trennen die Client-Access-Server-Rolle und die Postfachserverfunktion. Auf diese Weise wirkt der Client-Access-Server als Puffer, um den Traffic zum Postfachserver zu steuern. Seit SP1 für Exchange 2013 können Client-Access-Server auch SSL-Abfragen beenden und neue Kanäle zu den Postfachservern öffnen. Diese Funktion wird SSL-Offloading genannt und erhöht die Sicherheit sowie die Leistung der Exchange-Umgebung.

Das Problem bei diesem Vorgehen ist allerdings, dass Microsoft große architektonische Änderungen an der Client-Access-Server-Rolle in Exchange Server 2013 vorgenommen hat und diese jetzt nur noch über eingeschränkte Funktionalität verfügt. Im Prinzip gibt es nur noch drei Aufgaben, die ein Exchange-Server-2013-Client-Access-Server erledigt: Er kann Requests authentifizieren, diese weiterleiten, und er dient als Proxy-Server. Der Client-Access-Server führt allerdings keine Datenverarbeitung mehr aus.

Der Postfachserver dagegen umfasst alle Serverkomponenten aus Exchange 2010: Client-Zugriffs-Protokolle, Transportdienst, Postfachdatenbanken und Unified Messaging. Der Postfachserver verarbeitet alle Vorgänge für die aktiven Postfächer auf dem lokalen Server.

Da auf dem Client-Access-Server keine Daten gespeichert oder Warteschlangen erstellt werden, kann ein Upgrade auch unabhängig vom Mailbox-Server ausgeführt werden. Der Client-Access-Server bietet alle üblichen Client-Zugriffsprotokolle (HTTP, POP und IMAP sowie SMTP), die Zertifikatverwaltung aber kann auf dem Client-Access-Server oder dem Postfachserver erfolgen. Für Letzteren ist standardmäßig ein selbstsigniertes Zertifikat installiert. Der Client-Access-Server vertraut dem selbstsignierten Zertifikat auf dem Exchange-2013-Postfachserver automatisch, weshalb Clients keine Warnungen zu einem selbstsignierten Zertifikat erhalten, dem nicht vertraut wird. Voraussetzung ist allerdings, dass der Exchange-2013-Client-Access-Server über kein selbstsigniertes Zertifikat von einer Windows-Zertifizierungsstelle oder einem vertrauenswürdigen Drittanbieter verfügt.

Diese Struktur kann nun ein Problem darstellen, weil die Mailbox-Serverrolle die gesamte Datenverarbeitung in Exchange Server 2013 abwickelt, einschließlich der Ausführung von Remote-Powershell-Cmdlets. Daher kann ein alleinstehender Exchange-Server 2013 Client-Access-Aufgaben nicht alleine ausführen, sondern hängt vollständig von Back-End-Postfachservern ab.

Es ist daher wichtig, dass Sie auf einer VM einen temporären Exchange-2013-Server installieren, der über sämtliche Rollen verfügt. Der erste Exchange-2013-Server, den Sie in eine Exchange-2010-Organisation installieren, muss sowohl die Client-Access-Server- als auch die Mailbox-Server-Funktion aufweisen. Da dies aber selten so gewünscht ist, müssen Sie zunächst einen temporären Server mit Exchange 2013 aufsetzen, der beide Serverrollen bereitstellt. Sobald dieser Server vorhanden ist, können Sie Ihre produktiven Exchange 2013 Server online bringen, auf denen Sie die Client-Access-Server-Rolle oder nur die Postfachserver-Rolle installieren. Wenn Sie fertig sind, entfernen Sie einfach den temporären Exchange-Server wieder oder verwenden ihn als Testserver weiter.

Aufgabe 4: notwendige Zertifikate erwerben

Der letzte Punkt auf dieser Liste betrifft die benötigten Zertifikate. Als letzten Schritt vor der Migration zu Exchange 2013 sollten Sie Ihre Zertifikatanforderungen überprüfen und die erforderlichen erwerben. Sie können auch mit selbst signierten Zertifikaten oder mit internen Zertifikaten einer Active-Directory-Zertifikatsstelle arbeiten.

Je nach Ihren Anforderungen, dem Namensraum und der Zertifikatsart, die Sie verwenden, kann es durchaus möglich sein, dass Sie Ihre aktuellen Zertifikate weiter nutzen können. Allerdings sind in vielen Fällen auch neue Gütesiegel erforderlich.

Wenn Ihr Unternehmen Exchange-Server-2007 einsetzt, werden Sie aufgrund bisheriger Namensraum-Anforderungen wahrscheinlich neue Zertifikate benötigen. Viele Administratoren finden es allerdings einfacher, vor der Migration auf Exchange 2013 von Exchange 2007 zunächst auf Exchange 2010 zu migrieren.

Folgen Sie SearchEnterprise.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Collaboration-Software

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close