Migration auf Exchange 2013

In diesem Artikel erläutert unser Experte Markus Hengstler die Optionen für die Migration auf Exchange 2013 in verschiedenen Szenarien. Sie erfahren, was es dabei besonders zu beachten gilt.

Autor Markus Hengstler
Datum 21.02.2014
Lesezeit 8 Minuten

Das Jahr 2014 bedeutet gleich für mehrere wichtige Microsoft-Produkte das Ende des Lebenszyklus: Windows XP, Office 2003 und auch Exchange 2003 sind am Ende des Extended Supports angelangt. Das heisst, dass auch keine Sicherheitsupdates mehr erhältlich sein werden für diese Produkte. Genügend Grund also, zu den neueren oder gar neuesten Versionen zu migrieren.

In diesem Artikel werden die Optionen für die Migration auf Exchange 2013 in verschiedenen Szenarien erläutert. Sie erfahren, was es dabei besonders zu beachten gilt.

Exchange 2003

Gleich vorweg: Exchange 2013 unterstützt keine direkte Migration von Exchange 2003. Es muss zuerst zur Version 2007 SP3 RU10 oder 2010 SP3 migriert werden – dies nennt man Double-Hop-Migration. Es existieren direkte Migrationsverfahren, die aber ihre Tücken aufweisen. Der Weg über PST-Export-Import zum Beispiel ist mit Steinen und Stolperfallen gepflastert und kann mit doppelten Objekten, Non-Delivery Reports beim Beantworten von alten E-Mails oder Default-Ordnern in mehreren Sprachen und Versionen enden. Einen weiteren Weg bilden Produkte von Drittherstellern wie Code Two, Priasoft oder Quest. Diese rühmen sich zwar, eine direkte Migration zu ermöglichen – meistens aber nur cross-forest, d.h. es muss ein neues Active Directory aufgebaut und alle anderen Ressourcen verschoben werden.

Ich empfehle den Weg über Exchange 2010 – dort ist bereits sehr viel Erfahrung vorhanden.

Was gilt es zu beachten bei einer Migration von Exchange 2003 zu 2010?

  • Es gibt keinen Single-Instance Store mehr in Exchange 2010. Tendenziell wird also mehr Platz für die Daten benötigt werden.
  • Neu ist ein dedizierter Typ von Postfächern für Sitzungszimmer oder Ausrüstung vorhanden. Falls vorher der Auto Accept Agent dafür verwendet wurde, muss dieser vor der Migration deaktiviert werden, da es sonst zu merkwürdigem Verhalten der Kalender kommen kann.
  • Für ActiveSync-Geräte wird unterhalb eines Benutzers im AD ein neues Objekt erstellt. Falls Exchange diese Aktion nach der Migration wegen fehlenden Berechtigungen nicht durchführen kann, schlagen alle Synchronisationsversuche fehl. Dies betrifft auf jeden Fall alle Benutzer, die in einer geschützten AD-Gruppe (Domain Admins, Server Operators etc.) sind oder irgendwann mal waren.
  • Es sollte natürlich erst migriert werden, wenn die Exchange-2010-Infrastruktur gesichert (und wiederhergestellt) werden kann. Falls keine Agents für diese Version vorhanden sind, kann auch mit dem Bordmittel Windows Server Backup temporär eine Sicherung erstellt werden.
  • Während der Migration werden sehr viele Transaktionslogs erstellt und erst nach einem Backup gelöscht. Deshalb sollte man unbedingt genügend Platz dafür einrechnen.
  • Outlook 2003 Clients benötigen immer noch Public Folder für Frei/Gebucht-Informationen und den Zugriff auf das Offline Address Book. Beim Setup von Exchange 2010 kann deshalb das Vorhandensein dieser Client-Version angegeben werden. Aber: Outlook 2003 wird von Exchange 2013 nicht unterstützt – also sollte dieser Schalter nicht nötig sein.
  • Die Public-Folder-Replikation kann sehr lange dauern und ist schwierig zu überprüfen bei komplexen Hierarchien. Man sollte genügend Zeit einrechnen und die vorhandenen Scripts auf Exchange 2010 nutzen, um den Inhalt der Public Folder zu verschieben.
  • Falls die Migration länger dauert und beide Versionen nebeneinander funktionieren sollen, muss ein Legacy Namespace eingeführt werden. In den Zertifikaten für Exchange 2010 müssen dann mindestens drei Namen vorhanden sein: FQDN für den Zugriff, FQDN für den Legacy Namespace und FQDN für Autodiscover. Der FQDN für den Zugriff darf nicht derselbe sein wie für das Client Access Array und letzteres sollte extern nicht auflösbar sein.
  • GANZ WICHTIG: Die Exchange 2003 Server müssen korrekt deinstalliert werden. Alle Probleme, die bei der Deinstallation auftreten, müssen gelöst werden. Der Server darf nicht nur abgeschaltet und in ADSIEdit aufgeräumt werden. Überreste führen spätestens bei der Migration zu 2013 zu Problemen.

Die Liste ist nicht abschliessend, zeigt aber, dass nur schon für den Zwischenschritt einiges zu beachten ist.

Exchange 2007 / Exchange 2010

Die Migration der beiden Vorgängerversionen 2007 oder 2010 auf 2013 ist prinzipiell sehr ähnlich. Zuerst ein paar wichtige Punkte, die für beide gelten:

    • Es ist keine direkte (in-place) Migration eines Servers möglich.
    • Die Clients müssen einen bestimmten Versionsstand aufweisen und Outlook 2003 ist gar nicht mehr unterstützt.
    • Exchange 2013 hat weniger Anforderungen an den Storage, benötigt aber mehr RAM. Das Design für Exchange 2013 sollte diesem Umstand Rechnung tragen. Der Storage sollte mit Jetstress validiert werden.
    • Autodiscover innerhalb des AD verwendet standardmässig den ältesten Service Connection Point (SCP) für die Wahl der URL. Dies ist praktisch immer ein Legacy-Server. Autodiscover muss dementsprechend mit Set-ClientAccessServer > AutoDiscoverServiceInternalUri für alle Server so umgestellt werden, dass die Anfragen zu Exchange 2013 gelangen.
    • Prinzipiell kann der Namespace für OutlookAnywhere auf die Exchange-2013-Infrastruktur umgestellt werden, die dann als RPCoverHTTP Proxy für alle Versionen funktioniert. Die Authentisierungs- und Verschlüsselungsoptionen müssen allerdings sorgfältig geplant werden, damit der Zugriff auf zusätzliche Mailboxen und/oder Public Folder auf den Legacy Servern immer noch funktioniert.
    • Unter bestimmten Umständen kann es zu einem erneuten Download des Offline Address Book aller Clients kommen. Je nach Grösse und Anzahl Clients kann dies problematisch werden.
    • Public Folder benötigen eine besondere Beachtung in der Planung, da die Funktionsweise stark geändert wurde. Für Benutzer hingegen ändert sich nichts.

 

  • Speziell bei Exchange 2007: 
    • Ein Legacy Namespace wie bei Exchange 2003 wird benötigt, um die URL für den Zugriff auf OWA Exchange 2013 zur Verfügung zu stellen. Wenn die Mailbox noch auf dem Legacy Server liegt, wird statt einer Weiterleitung eine Umleitung ausgelöst.
    • Auf Multi-Role Exchange 2007 Servern muss IPv6 in der Registrierung deaktiviert werden – aber nicht auf den Exchange 2013 Servern. Microsoft testet kein Szenario ohne aktiveres IPv6.
  • Speziell bei Exchange 2010: 
    • Die Arbitration Mailbox sollte früh migriert werden, da sonst bestimmte Funktionen (Admin Audit Log, Moderation) bis zum Abschluss der Migration nicht mehr zur Verfügung stehen.
    • Da Exchange 2013 als Proxy funktioniert, muss auf allen virtuellen Directories in Exchange 2010 Integrated Authentication aktiviert werden.

Auch diese Auflistung ist nicht abschliessend, da je nach Ausgangslage (3rd Party Software, spezielle Konfiguration wie AD RMS oder Journaling, Berechtigungseinschränkungen) noch weitere Herausforderungen zu meistern sind. Es ist sogar noch wichtiger als bei früheren Versionen, einiges an Fachwissen oder Erfahrung mit Exchange 2013 zu haben, bevor man sich an eine Migration wagt. Dies kann mit externer Hilfe geschehen oder natürlich mit Kursen.

Microsoft Exchange Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings


Über den Autor

Markus Hengstler

Markus Hengstler arbeitet bei der UMB AG als Senior Systems Engineer in den Bereichen Exchange, Windows und Citrix. Dank seiner Erfahrungen in diesen Bereichen ist er zertifizierter «MCSE: Server Infrastructure». Ausserdem ist er einer von drei «MCSM: Messaging» in der Schweiz. Seit 2001 unterrichtet er als Microsoft Certified Trainer und seit 2010 als Citrix Certified Instructor bei Digicomp.