Migration von einen Office 365 in einen neuen Microsoft 365 Tenant – Die Herangehensweise

Prozessentwurf für eine Office365 Migration

Migration von einem Office 365 in einen neuen Microsoft365 Tenant – Die Herangehensweise

Als MCT habe ich einen Developer Tennant für Office 365. In diesem Jahr bekommen wir endlich auch Zugriff auf die Microsoft 365 Funktion, also Enterprise Mobility und Security. Nachteil ist, es ist ein neuer Tennant und es steht eine Migration an. Gleichzeitig muss aber vieles neu eingerichtet werden. Ich nutze die Gelegenheit, um daraus direkt eine Reihe von Blogbeiträgen zu schreiben.


Im Mai 2015 habe ich bereits den Artikel „Migration von einem Office365 Tennant zu einem anderen Office365 Tennant“ geschrieben, der beschreibt aber sehr oberflächlich den Weg, diesmal werde ich etwas genauer sein.

Da ich die Artikelreihe auf Deutsch und Englisch schreiben werde, werden die Screenshots auf den Onlineportalen in Englisch sein.

Dieser Artikel soll überwiegend einen Eindruck vermittelt, was es zu beachten gibt.

Wichtiger Hinweis

Dies ist kein Blue-Print oder Best-Practise. Ich schreibe hier meinen Weg auf der Reise, den ich wähle, mit den Stolpersteinen, die ich finde. Da dies der erste Artikel der Reise ist, können die Prozesse und Abläufe sich noch in weiteren Artikeln der Reihe ändern. Auch passt das Vorgehen nicht auf alle Fälle oder Unternehmensgrößen. Für einige könnte ein Werkzeug eines Drittanbieters eine bessere Lösung sein. Diese Artikelreihe soll vor allem als Anregung verstanden werden, als eine Inspiration für den eigenen Weg. Entsprechend kann ich auch keine Garantie, Gewährleistung oder Support für diese Methoden geben. Wie immer versuche ich Fragen die über die Kommentare zu beantworten, diese sollten aber spezifisch formuliert sein, und nicht nur mit einem mehrseitigen Konzept zu beantworten sein.

Die Vorbereitungen

Wichtig ist bei so etwas ein guter Plan. Ich gehe meistens hin und starte mit einem Groben Plan, den ich immer mehr im Detail ausarbeite. As Werkzeuge nehme ich dafür meisten eine einfache OneNote Liste, oder ein Mindmap wie bei der Themenfindung für das EUC-Meetup zusehen ist.

Der erste Entwurf sieht so aus:

1.
2.
4.
Phase 1
b.
c.
d.
Backup der Oaten (Mail, OneDrive und Co.)
Hinzufügen des MS TXT Eintrag zum DNS und ändern der DNS TTL bzw. der TTL des SPF und des MX-Eintrages
umlenken des Mail-flow Liber Mails Server, zum aeispiel Webhosting System mit Mailweiterleitung an Onmicrosoft-Adresse
Testen des Mail-flow
Konfigurieren des neuen Microsoft 365
i. unternehmensbranding
ii. Authentifizierung / MFA
Domäne im alten Office 365 entfernen
Phase 2
a. Trennen der Directory Synchronisation
b. Ändern der aenutzer von Synchronisiertzu Cloud-only im alten Office 365
c. Auslesen der Benutzer Informationen im alten Office 365 und anlegen im neuen
Ill.
v.
Phase 3
Benutzer anlegen
Lizenzen zuweisen
Postfächer anlegen
Gruppen anlegen
Ändern der Mailweiterleitung (Postfachweiterleitung ändern auf neuen Onmicrosoft ändern)
Export der Postfächer in PST und Import als PST / ggf. Imap Import?
a. Nach frühestens 24 Domäne zu neuen Office 365 hinzufügen
b. Nach Umstellung der Domäne DNS umstellen (MX und SPF auf neuen Office 365)
c. OneDrive-Daten Kopieren (Manuel')
d. Installation DirSync in der neuen Domäne
e. Endgeräte neu konfigurieren
Phase 4 - Clean-up
a. DNS bereinigen (alte TXT Einträge)
b. Postfächer auf Linux

Der Vorteil an dieser und der Mindmap Methode ist, ich kann beliebig in die Tiefe gehen. Auch kann ich durch diese Art Themenbereiche nach groben Abhängigkeiten gliedern. Natürlich ist das kein Projektplan im eigentlichen Sinne oder kein Prozess, aber ich kann es dafür nutzen.

Für die genauen Abhängigkeiten sollte man das Ganze in ein Projekt oder einen Prozess darstellen. Hier mal ein kurzes Prozessbild, das ich aus dem Entwurf erstellt habe. Hier kann man auch besser über die Abhängigkeiten überlegen und diese auch darstellen.

Prozessentwurf für eine Office365 Migration
Prozessentwurf für eine Office365 Migration

Wichtig ist, erstellen Sie Ihren eigenen Plan, mit ihren Abhängigkeiten und mit eine Zeitplanung. Auch sollten Sie drüber nachdenken, ob es andere Stellen im Unternehmen gibt, die eingebunden werden müssen. Beispiele für solche Stellen könnten ein Betriebsrat oder ein IT-Sicherheitsverantwortlicher sein.

Aus der Erfahrung mit diversen Mailserver Migrationen weiß ich auch, dass es sich lohnt den Mail-Flow separat zu betrachten. Nichts ist schlimmer, als wenn Mails verloren gehen. Besonders sollte man hier auf die DNS TTL achten und daran denken, das hier Änderungen immer eine Weile dauern bis sie sich „Rumgesprochen“ haben.

Mailflow bei einer Office 365 Migration

Dem Thema Mailfluss werde ich noch im Artikel „Vorbereiten des Mail-Fluss für die Office 365 Migration“ genauer beschreiben.

Themen der Bedacht werden sollten

Was gilt es bei so einem großen Projekt, oder auch bei Teilbereichen zu bedenken? Hier mal ein paar Vorschläge:

Notfallplan

Wichtig ist immer bei solchen Projekten ein Notfall Plan. Wenn alles schief geht, wie werde ich wieder arbeitsfähig oder komme zurück zum Ausgangszustand. In vielen Fällen kann hier ein Backup und eine gute Dokumentation helfen. Aber nur wenn das Backup auch wiederherstellbar ist und die Dokumentation stimmt. Mein Tipp, vorher mal prüfen, spart im Notfall Probleme. Allerdings wird das gerne mal wie eine Versicherung betrachtet, die braucht man ja eh nicht… aber wenn man sie mal braucht, dann ist es gut sie zu haben.

Ressourcen

Habe ich genug Ressourcen? Habe ich die Kapazität für ein paar zusätzliche VMs im RZ? Aber nicht nur diese Ressourcen sind wichtig. Meistens viel wichtiger, habe ich genügend Fachkräfte und haben die das Notwendige Know-How? Schätzen Sie die Aufwände (Am besten mit Puffer, Kaffee trinken wenn alles glatt läuft geht immer) und prüfen Sie ob sie genug Mitarbeiter im Team haben und ob dann noch welche für andere Aufgaben da sind.

Ein weiteres Thema ist die Lizenzensierung, haben Sie genug und sind die Beschaffungswege und Budgets geklärt?

Vorschriften und Regularien

Wenn sie nur Bausteine aus der Reihe verwenden möchten, oder sich nicht sicher sind ob alles beim letzten Office365 richtig gemacht wurde, dies ist Ihre Chance es zu bereinigen. Denken Sie an Themen wie Compliance, GDPR / DSVGO, Auftragsdatenverarbeitung und Co. Nutzen Sie die Gelegenheit es richtig zu machen.

Dokumentation

Wenn Sie so ein Projekt durchführen, dokumentieren Sie es. Wenn Sie bei der Umsetzung die einzelnen Schritte richtig dokumentieren, haben Sie direkt ein Notfallhandbuch, falls es neu eingerichtet werden muss. Außerdem wissen Sie auch direkt was konfiguriert wurde. Gerade bei Zertifizierungen oder Audits kommt die Frage öfters, wie etwas konfiguriert wurde.

Das Ziel meiner Migration

Für meine Zwecke möchte ich nur die Mail und OneDrive Daten von 3 Benutzern migrieren. Hinzukommen noch andere Mail Konfiguration, wie zum Beispiel Gruppen. Alles andere werde ich neu aufbauen. Zum einen um es mit dem heutigen Wissen mal sauber neu aufzusetzen, zum anderen um Artikel zu schreiben die auch für neue Nutzer von Microsoft 365 relevant sind.

Entsprechend werde ich keine Werkzeuge nutzen, wie sie bei Migrationen im Unternehmensumfeld normalerweise genutzt werden. Aber vielleicht hilft das der einen oder anderen kleinen Firma, oder hilft auch großen Unternehmen, um ein Gefühl für die Dimension zu bekommen.

Wichtig bei meinem Migrationsweg ist, er beeinflusst die Benutzer in ihrer Arbeitsfähigkeit. Auch ist eine sogenannte „Big-Bang“ Migration erforderlich. Ein Parallelbetrieb mit beiden Umgebungen ist hier ohne Hilfsmittel nicht möglich, da dieselbe AD-Domäne und dieselben Maildomänen benutzt werden sollen. Erschwerend kommt bei mir noch dazu, dass die Postfächer in mehreren Maildomänen Konten haben. Mit genügend Arbeit könnte man hier etwas versuchen zu planen. Der aber wichtigste Grund warum es nur mit einem großen Knall geht, ist das die Integration zwischen den Postfächern in verschieden Welten nicht funktioniert. Also weder „Senden als“ noch im Kalender der anderen nachschauen. Dies ist etwas das ich in meinem Szenario vermeiden möchte.

Mögliche Stolpersteine

Es gibt auch einiges, das Probleme bereiten kann. Das liegt daran, dass es keinen Offiziellen Weg von Microsoft gibt mit einer AD-Domäne den Tenant zu wechseln. Den einzigen offiziellen Weg, den es gibt ist eine AD Domäne mit einer Office 365 Umgebung zu einer anderen AD-Domäne mit einer anderen Office365-Umgebung zu migrieren. Das klassische Firmenübernahme quasi.

Dinge die besonders problematisch sein können, bzw. bei der Migration eventuell auf der Strecke bleiben:

Anzeige

  • Office 365 Gruppen können nicht migriert werden. Wer doch einen Weg kennt, bitte sagt Bescheid.
  • Berechtigungen wie Senden Als, Senden im Auftrag von, Leseberechtigung auf Postfächer / Kalender
  • Outlook Regeln
  • Öffentliche Ordner
  • Reste alter Exchange oder SharePoint Umgebungen
  • Azure AD Einstellungen auf den Computern der Endbenutzer
  • Weitere Office 365 Dienste wie ToDo, Planner, Sway, Teams und Co.

Die Probleme über die ich stolper, werde ich behandeln. Wie aber gesagt, ich mache das sehr nach dem KISS Ansatz (Keep it simple and stupid). Ein weiterer Artikel zu dem Thema wurde auf Gooroo.io in Englischer Sprache veröffentlicht: Migration between two Office 365 tenants.


Autor: Fabian Niesen

Fabian Niesen ist seit Jahren beruflich als IT-Consultant unterwegs. Hier schreibt er privat und unabhängig von seinem Arbeitgeber. Unter anderem ist er Zertifiziert als MCSA Windows Server 2008 / 2012, MCSA Office 365, MCSA Windows 10, MCSE Messaging, MCT und Novell Certified Linux Administrator. Seit 2016 ist er auch MCT Regional Lead für Deutschland. Seine Hobby’s sind Social Media, Bloggen, Mittelaltermärkte, Historische Lieder und der Hausbau. Zu finden ist er auch auf folgenden Plattformen: -

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.