Es gibt verschiedene Wege, die Benutzer auf Office 365 zu migrieren. Mit dem Exchange 2013 Server Deployment Assistant kann man herausfinden, welche Migration für die eigene Umgebung in Frage kommt.
In meinem Fall mit mehr als 1’000 Accounts und einem Exchange 2007 Server wählt man die sogenannte “Staged Exchange Migration”.
Die “Staged Exchange Migration” kann sich über mehrere Wochen oder sogar Monate hinziehen. Wichtig ist, dass bis zum Abschluss der Migration die öffentlichen DNS-Einträge (Autodiscover- und MX-Einträge) auf den lokalen Exchange Server zeigen. Dies bedeutet zwar, dass im Office 365 Admin Center die Domänen ein rotes Kreuz haben, was aber während der Migration richtig ist.
Der lokale Exchangeserver leitet nämlich die an ihn gerichteten Mails der bereits migrierten Benutzer an Office 365 weiter. Erst wenn alle Benutzer migriert sind, kann man die DNS Einträge auf Office 365 umstellen, damit die Mails direkt dorthin geroutet werden.
Wenn alles vorbereitet ist, kann man gemäss diesem Technet Artikel eine CSV-Datei für die Migration bereitstellen. Da das Passwort über DirSync mit dem Active Directory synchronisiert wird, benötigt man nur die Spalte “EmailAddress”. In einer CSV-Datei dürfen maximal 1’000 User vorkommen.
Diese CSV-Datei kann man nun im “Exchange Admin Center” vom Office 365 Portal”“ unter “Empfänger” –> “Migration” hinzufügen.
Beim Migrationstyp wählt man aus den oben erwähnten Gründen “Mehrstufige Migration”, also eine “staged migration”.
Im nächsten Fenster wählt man die vorher erstellte CSV-Datei aus.
Als nächstes muss man die Angaben zum Server angeben.
Nun muss man dem Migrationsbatch noch einen Namen vergeben.
Wenn man möchte, dass man per Mail über die erfolgreiche Abarbeitung des Batches informiert wird, kann man eine Mailadresse eintragen.
Nachdem der Migrationsbatch durchgelaufen ist, haben die migrierten Benutzer zwei Postfächer, eines auf dem lokalen Exchangeserver und eines in Office 365. Mails werden wegen den noch nicht umgestellten DNS Einträgen weiterhin an den lokalen Exchangeserver geliefert, welcher nun die Mails an Office 365 weiterleitet. Dies wird erreicht, indem im Active Directory die Adresse von Office 365 bei targetAddress eingetragen wird. Man kann dies mit dem ADSI-Editor überprüfen.
Ein Problem bleibt nun aber das bestehende Postfach auf dem lokalen Exchangeserver. So verbindet sich z.B. Outlook über den Autodiscover-Eintrag weiterhin mit dem lokalen Exchangeserver. Dieses und weitere Probleme kann man beheben, indem man das Benutzerpostfach auf dem lokalen Exchangeserver zu einem “mail-enabled user” abändert. Microsoft stellt dafür eine Anleitung und Powershellskripts zur Verfügung.
Als erstes lädt man die beiden Powershellskripts in einen Ordner, kopiert die CSV-Datei mit den migrierten Benutzern dazu und ändert den Namen auf migration.csv.
Nun kann man in der Exchange Management Shell das erste Skript .\ExportO365UserInfo.ps1 ausführen lassen.
Für die Verbindung mit Office 365 muss man sich mit Benutzernamen und Passwort für Office 365 anmelden.
Wenn das Skript erfolgreich durchgelaufen ist, wird eine neue Datei cloud.csv erstellt.
Mit .\Exchange2007MBtoMEU.ps1 <FQDN von einem Domänencontroller> kann man nun die Umwandlung auslösen.
Wenn alles erfolgreich gelaufen ist, haben die Accounts kein Postfach mehr in Exchange, sondern sind nur noch als E-Mail-Kontakt mit der externen Mailadresse von Office 365 aufgeführt.
Im Office 365 Portal kann man nun unter “Benutzer” –> “Aktive Benutzer” die migrierten Benutzer auswählen.
Tipp: Ich habe mir eine neue Ansicht erstellt, die die Benutzer mit einem Postfach, aber ohne Lizenz anzeigt. Dies sind dann gerade die noch zu ändernden Benutzer.
Diese kann man nun alle auswählen und bearbeiten. So kann man für alle migrierten Benutzer die Standarddomäne auswählen, den Benutzerstandort auf Schweiz setzen und eine Lizenz zuweisen.
Wenn alles korrekt funktioniert hat, kann man den Batch im Exchange Admin Center unter “Empfänger” –> “Migration” beenden und löschen
Die migrierten Benutzer können sich nun auf verschiedenen Wegen anmelden. An Outlook Web App kann man sich über https://outlook.office365.com und am Portal über https://portal.office365.com anmelden.
Bei der ersten Anmeldung muss man noch Sprache und Zeitzone auswählen.
Über Active Sync kann man wie gewohnt ein neues Exchange Konto hinzufügen und die persönlichen Daten eintragen. Bei mir genügten die Mailadresse und das Passwort nicht. Es wurde auch der Benutzername (gleich wie Mailadresse) und der Server (outlook.office365.com) abgefragt. Ich gehe davon aus, dass dies nicht mehr nötig ist, wenn nach der vollständigen Migration die DNS Einträge angepasst sind.
Bei einem bereits eingerichteten Outlook Profil muss man die neue Verbindung herstellen. Beim Starten von Outlook erscheint ein Anmeldefenster. Beim Benutzernamen wird die intern verwendete Domäne vorgeschlagen, welche auf die korrekte öffentliche Mailadresse geändert werden muss.
Am Schluss kommt eine Meldung, dass Outlook nun neu gestartet werden muss.
Danach startet Outlook korrekt mit der neuen Verbindung zu Office 365.
Über diese Änderungen sollte man die Benutzer mit einer Anleitung informieren.
Alternativ könnte man mit dem “Office Customization Tool” eine angepasste MSP-Datei erstellen, die sich dann verteilen lässt. Wegen einem Problem mit Benutzern, die Outlook noch nie geöffnet haben, musste ich so eine angepasste MSP-Datei verteilen. Weitere Informationen findet man in diesem Beitrag.
Es bleiben ein paar weitere “Real-World” Probleme.
Public Folders
Microsoft bietet zwar Skripts zum Migrieren der öffentlichen Ordner, aber solange diese Skripts nicht ausgeführt wurden, können die migrierten Benutzer nicht auf die öffentlichen Ordner zugreifen und nachdem sie ausgeführt wurden, können die noch nicht migrierten Benutzer nicht mehr auf sie zugreifen…
Passwort ändern
Bisher konnten Benutzer, die nicht an einem Computer in unserem Netzwerk arbeiten (z.b. Schulräte), ihr Passwort von extern über Outlook Web Access (OWA) zurücksetzen, auch nachdem es abgelaufen ist. Da DirSync aber die lokalen Passwörter nach Office 365 synchronisiert, können die Passwörter nur noch von intern geändert werden. Der beste Weg wird wohl sein, nicht das ganze AD zu synchronisieren und für diese Benutzer nicht synchronisierte “cloud-only” Accounts anzulegen.
ictschule 