Ein Erfahrungsbericht:

Die Migration ist nicht so einfach, wie es zunächst scheint. Wir waren auf der Suche nach einer pragmatischen Lösung - da der SBS 2003 kurz vor dem Zerfall stand, hatte eine schnelle Migration Vorrang vor einer komfortablen Lösung.

Wir haben uns letztlich dafür entschieden, vorerst nur die Exchange Postfächer in die Cloud umzuziehen und den On Premise Server vorerst weiterhin als Domänencontroller zu nutzen. Ddie Benutzerverwaltung in Office 365 ist völlig unabhängig von der Benutzerverwaltung auf dem On Premise Server. So hat ein Benutzer zwar möglicherweise zwei verschiedene Passwörter, dafür sind die Systeme jedoch unabhängiger voneinander.

Die Migration selbst wurde nach einigem Hin und Her so konzipiert, dass die Postfächer einzeln migriert werden können. Wir fanden es in unserem Fall praktisch, dass der Migrationszeitpunkt den Bedürfnissen der einzelnen Benutzer angepasst werden konnten, weil einige User auf Projekten unterwegs waren, und in der Regel auch eine Installation der mittlerweile völlig veralteten Microsoft Office Versionen durch den In-House Admin angebracht war.

Die Durchführung von Backups sollte vor einer solchen Migration selbstverständlich sein.

RPC over HTTP

Die gesamte Migration erfolgt per RPC over HTTP. Um dieses zu testen, bietet sich die Website https://testconnectivity.microsoft.com/ an, und zwar mit dem Outlook Connectivity Test.

Remote Connectivity Analyzer

Das korrekte Format der Einstellungen ist für einen erfolgreichen Test sehr wichtig. Insbesondere die manuellen Servereinstellungen für den RPC Proxy Server (= externer / öffentlicher FQDN des Exchange Servers) sowie den Exchange Server (= interner / privater FQDN des Exchange Servers) müssen korrekt angegeben werden.

remote-connectivity-analyzer-2

Erst wenn dieser Test erfolgreich ist, ist ein Fortsetzen des Migrationsprozesses sinnvoll, weil Office365 auf dieselbe Art und Weise Kontakt zum OnPremise Exchange Server aufnimmt, wie das Connectivity Test Tool.

Rechte des Migrationsbenutzers

Während oben der Zugriff eines Benutzers auf sein eigenes Postfach getestet wurde, wird für eine Migration in der Regel ein spezieller Administrator-Account (alternativ der Domänenadministrator) genutzt. Dieser hat jedoch in der Werkseinstellung keinerlei Zugriffsrechte auf fremde Postfächer, somit ist eine Migration zunächst unmöglich.

Im Exchange System Manager kann dies geändert werden (Vorsicht, Datenschutz - ggf. nicht erlaubt!!!). Receive As und Send As sollten nicht verweigert, sondern zugelassen werden.

administrator-zugriff-migration

Vorsicht Stolperstein: Möglicherweise ist für Gruppen, z. B. Domänen Admins die Verweigern Einstellung aktiv. Diese muss entfernt werden, weil die Verweigerung der Gruppe das Zulassen des einzelnen Benutzers überschreibt.

Sinnvoll kann es sein, dies durch den _Remote Connectivity Analyzer _überprüfen zu lassen. Hierfür in diesem Tool einfach die E-Mail Adresse eines beliebigen Benutzers, jedoch die Zugangsdaten des Migrationsbenutzers angeben. Ist das Ergebnis immer noch zufriedenstellend?

Los geht’s…

Die _Mehrstufige Migration _ist eine feine Sache: Es werden genau diejenigen Postfächer umgezogen, die in einer .csv-Datei angegeben werden. Die .csv-Datei kann sehr einfach per Editor erstellt werden:

EmailAddress,ForceChangePassword
max.mustermann@line5.de,FALSE
alfons.mueller@line5.de,FALSE

Jeder zu migrierende User muss bei dieser Migrationsvariante bereits - mit derselben E-Mail Adresse - in Office365 vorhanden sein. Nach Anlage der User geht es per Empfänger > Migration zum Migrationsassistenten, der die .csv-Datei entgegennimmt und den Migrationsendpunkt abfragt. Für den Migrationsendpunkt sollten dieselben Daten angegeben werden, die auch im _Remote Connectivity Analyzer _(s.o.) zu einem Erfolgserlebnis geführt haben. Und dann … startet die Migration.

Vorsicht: Während der Migration werden die User auf dem OnPremise Server automatisch so umgestellt, dass alle neuen E-Mails direkt an das Office365 Postfach weitergeleitet werden.

Interne E-Mails von Office365 zum OnPremise Server

Werden der interne E-Mail Server und der Office365 Server gleichzeitig und ohne Hybridbereitstellung unabhängig voneinander betrieben, weist der Online Exchange Server solche E-Mails an Adressen, die vom OnPremise E-Mail Server verwaltet werden, zurück.

Beispiel: max.mustermann@line5.de nutzt sein Postfach auf dem OnPremise Server, lisa.mustermann@line5.de ist bereits auf den Office365 Server umgezogen. Versucht Lisa, eine E-Mail an Max zu senden, schlägt dies fehl, weil der Office365 Server Max noch nicht kennt. Versendet Max dagegen eine E-Mail an Lisa, erhält sie diese, weil der Migrations-Task den Parameter TargetAddress in Lisas Benutzer auf lisa.mustermann@meinefirma.onmicrosoft.com gesetzt hat.

Um interne E-Mails vom Office 365 System zum OnPremise Server zuzulassen, sind zwei Einstellungen notwendig:

  • Ein ausgehender Connector vom Office 365 System
  • Die Domain muss als Internes Relay statt autoritativ eingestellt werden

Outlook und die Endbenutzer

Es mag praktisch sein, im Zuge der Migration gleich die aktuelle Office Version zu installieren. Wenn allerdings das alte Exchange Konto noch in Outlook vorhanden ist, kommt es nach der Installation von Office365 möglicherweise zu einer Fehlermeldung, weil sich manche Office365 Versionen nicht mit einem OnPremise Exchange verbinden lassen.

Am sichersten ist es, das Outlook Profil bereits vor dem Deinstallieren von Office zu löschen - und dann Office komplett neu zu installieren. Hierbei sollte man jedoch beachten, dass Daten verloren gehen könnten - beispielsweise eingebundene Archivdateien, oder private POP3 / IMAP Accounts. Unter Umständen empfiehlt es sich, das Office Upgrade gemeinsam mit dem User einzeln durchzuführen.

Rückgängig…

Falls aus irgend einem Grunde die E-Mail Weiterleitung vom OnPremise Server zu Office365 abgeschaltet werden soll, kann mittels des Tools ADSIEdit.msc (Teil der Windows Server 2003 Support Tools) der Parameter TargetAddress für den spezifischen User entfernt werden. Die E-Mail Weiterleitung wird sofort inaktiv. Denkbar ist die Notwendigkeit für diesen Schritt, falls eine Migration rückgängig gemacht oder der User nach durchgeführter Migration doch wieder auf dem OnPremise Server arbeiten soll.

Migrationsberichte

Nach Abschluss der Migration (Status: synchronisiert) besteht die Möglichkeit “Details zu übersprungenen Elementen” anzusehen und abzulegen. Ebenso kann der “Bericht für diesen Benutzer” heruntergeladen werden. Achtung!: Im weiteren Verlauf wird der Status des Migrationsbatches automatisch auf beendet gesetzt und später gelöscht. Details zu übersprungenen Elementen oder der Bericht können dann nicht mehr eingesehen werden.

s.: https://technet.microsoft.com/de-de/library/jj898488%28v=exchg.150%29.aspx#managebatches