Migrieren einer Exchange-2010-DAG auf Exchange 2013

11. November 2012

Das Prinzip Ausfallsicherheit adressiert eine Exchange-DAG. Quelle: Redmond/Penton Media

Die Vorgehensweise bei der Migration einer DAG von Exchange Server 2010 auf Exchange 2013 erscheint auf den ersten Blick als recht einfach: Der Administrator muss eine neue DAG – unter Exchange Server 2013 – anlegen und hat danach nur die Postfächer zu verschieben. Doch er darf dabei einige „Kleinigkeiten“ nicht übersehen – sonst scheitert das Vorhaben.

Unser Autor Tony Redmond skizziert die beste Vorgehensweise.

Das Servicepack 3 für Exchange Server 2010 wird von Microsoft erst Anfang 2013 gebracht. Es soll dann das Zusammenspiel zwischen Exchange Server 2010 und dem Exchange Server 2013 in einer Organisation ermöglichen.

Daher wird wohl kaum jemand schon jetzt vor der Aufgabe stehen, eine Database Availability Group (DAG) von Exchange 2010 auf Exchange 2013 migrieren zu müssen. Doch das ist eine extrem wichtige Aufgabe, wenn jemand an einer Hochverfügbarkeit seiner Exchange-Infrastruktur interessiert ist. Daher sollte man sich bereits damit befassen und sich womöglich sogar einen Plan zurechtlegen, wie diese Aufgabe angegangen werden soll.

Einheitliches Fundament für die DAG ist ein Muss

Die größte Herausforderung ist die Vorgabe, dass man keine unterschiedlichen Betriebssysteme innerhalb einer DAG einsetzen darf – und auch keine verschiedenen Versionen (nicht verwechseln mit den Editionen) von Exchange Server.

Daher kann man nicht einfach einen Postfachserver auf der Basis von Exchange 2013 in eine vorhandene Exchange-2010-Infrastruktur einbauen. Zudem ist es nicht möglich, das darunterliegende Betriebssystem – etwa Windows Server 2008 Release 2 auf Windows Server 2012 – zu wechseln

Mit diesen Voraussetzungen für die DAGs sollte man den folgenden Weg einschlagen: Alle Member Server der DAG müssen dieselbe Software verwenden – daher ist eine neue DAG zu erstellen. Diese Struktur muss dann komplett auf Exchange Server 2013 basieren. Wenn dann diese neue DAG komplett verfügbar ist, gilt es für den Administrator noch die Postfächer auf die neue Exchange 2013 DAG zu migrieren. Dazu sind die folgenden Teilschritte nötig:

Die Exchange 2013 DAG ist zu erstellen und dann sind die Exchange 2013 Postfachserver der DAG hinzuzufügen.
Dann sind die nötigen Postfach-Datenbankkopien in der Exchange 2013 DAG anzulegen.
Im folgenden Schritt gilt es, die Postfächer aus den Datenbanken in der Exchange-2010-DAG in die Exchange-2013-DAG zu verschieben.
Wenn alle Postfächer aus der Exchange-2010-Datenbank entnommen sind und die Datenbanken dann leer sind, kann man diese Datenbanken und ihre Kopien aus der Exchange-2010-DAG entfernen.
Wenn dann die Arbeitslast sich in der Exchange 2010 DAG reduziert, kann man diese Infrastruktur konsolidieren und sie auf eine geringere Anzahl von Servern reduzieren. Dann sind die nicht mehr benötigten Mitglieder der Exchange-2010-DAG zu entfernen.
Nachdem ein Postfachserver aus der Exchange-2010-DAG entfernt wurde, kann man auf ihm über das Setup-Programm von Exchange den Exchange Server 2010 deinstallieren und dann den Server aus der Exchange-Organisation entfernen.
Nachdem alle Postfächer auf die Exchange-2013-DAG migriert wurden, kann man den letzten verbliebenen Postfachserver aus der „alten DAG“ entnehmen und dann mit dem Powershell-Cmdlet Remove-DatabaseAvailabilityGroup die alte Exchange-2010-DAG aus der Organisation entfernen.

Basis für den Neuanfang

Die entnommenen Exchange-2010-Postfachserver können als Basis für die neuen Exchange-2013-Server dienen. Man sollte generell den Versuch eines Aktualisierung der Software nicht unternehmen, denn das erweist sich in der Praxis vielmals als der schlechtere Ansatz im Vergleich zum kompletten Entfernen aller Software und dem Neuaufsetzen auf der „nackten“ Hardware.

Danach hat man dann vorzugsweise einen neuen Server mit der Betriebssystemplattform Windows Server 2012 und dem Exchange Server 2013 vorliegen. Ist der Server komplett aufgebaut, kann man ihn zu einem Mitglied in der Exchange-2013-DAG machen.

Das hört sich nach viel ungewollter Arbeit an, doch es ähnelt sehr stark der Vorgehensweise, wenn man einen „normalen“ Exchange Server aufsetzt, bei dem sich auch keine direkte Aktualisierung machen lässt. Diese Vorgehensweise ist in den letzten drei Exchange-Versionen gut abgelaufen – es spricht daher nichts dagegen, diesen Ansatz auch auf die Migration bei den DAGs auszuweiten.