Cross Tenant Migration

Die Welt könnte so einfach sein, wenn Firmen statisch wären. Da es die Wirtschaft und die Kunden aber auch nicht sind, ändern sich Firmen selbst durch Zukäufe oder Verkäufe und auch Leistungen werden manchmal von anderen Dienstleistern eingekauft. Je mehr Firmen Dienste von Office 365 nutzen, desto häufiger wird auch hier das Thema "Merger and Aquisitions" in Verbindung mit der Cloud relevant. Diese Seite beschreibt die Überlegungen und Hintergründe einer Migration von Personen und Daten zwischen Office 365 Tenants. Die Informationen sind ebenso passend für eine Migration in die "DE Cloud" oder wieder heraus. Die Migrationen unterscheiden sind gar nicht mal so von anderen Exchange Migrationen.

Vorbemerkung

Ehe Sie im folgenden Kapitel die Szenarien betrachten, sollten Sie sich folgende Dinge noch mal in Erinnerung rufen.

  • Ein Tenant-Name ist weltweit eindeutig
    In Office 365 kann ein Tenant wie "msxfaq.onmicrosoft.com" immer nur einmal existieren. Speziell in Verbindung mit der "Public Cloud" und der fast abgeschirmten "DE-Cloud" ist der Namen eindeutig.
  • Vanity-Domain ist eindeutig
    Die meisten Firmen arbeiten nicht mit der "onmicrosoft"-Domain, sondern registrieren ihre "richtige" Domain auch in der Cloud. An diesem Namen hängen dann Mailadressen, SIP-Adressen und vor allem auch der Anmeldename (UPN). Auch diese Adresse kann nur bei einem Tenant hinterlegt sein. Wenn ein Anwender seine "Mailadresse" (=UPN) eingibt, dann muss Office 365 ja den Anwender zum richtigen ADFS-Server weiter leiten. zudem erscheinen bei der Microsoft Public Cloud in Exchange nur die Domains als "Accepted Domains", die auch eingetragen worden sind.
  • Service Records zu einem Dienstleister (MX, SIP etc.)
    Die DNS-Einträge für die Dienste "Skype for Business" (SIP, Lyncdiscover)" oder Mail (MX, AutoDiscover) etc. kann auch nur eine Firma auf ihren einen Tenant setzen.
  • DirSync Einschränkungen
    Ein Tenant kann immer nur von genau einer DirSync-Instanz bedient werden, die aber mittlerweile mehrere Quell-Forests unterstützt. Theoretisch könnten sie mit zwei Tenants natürlich einfach einen zweiten DirSync aufsetzen. Da aber auch die Mailadressen und insbesondere der UPN Teil des DirSync ist, wird ein Tenant dann verlieren

Wer also bei der Migration mit zwei Tenants arbeiten muss, muss einem Tenant zumindest eine andere primäre Domäne geben. Dies gilt auch bei der Microsoft "Public Cloud" als auch der Microsoft DE-Cloud.

Szenarien

Mir fallen in dem Zuge folgende Szenarien ein. Dabei ist Tenant 1 der aktuell aktive primäre Tenant, aus dem Benutzer raus verschoben oder hinein verschoben werden. Dieser Tenant hat einen DirSync mit "On-Prem1" und eventuell ein Hybrid-Setup:

Quelle Ziel Szenarien Beschreibung

Tenant1

On-Prem1

Migration zurück

Das Zurückverlagern von Benutzern in die On-Prem-Umgebung ist über den Hybrid oder von Exchange und Skype for Business einfach möglich.

On-Prem1

Tenant1

Migration in die Cloud

Das Verlagern von Benutzern in die On-Prem-Umgebung ist über den Hybrid oder von Exchange und Skype for Business einfach möglich.

Tenant1

On-Prem2

Splitt - Ausgliederung von Benutzern in eine andere Firma

Anders ist es, wenn Benutzer eines Tenant1 in eine andere On-Prem-Organisation übertragen werden sollen. Ein Hybrid-Mode mit On-Prem2 ist nicht möglich, wenn Tenant1 bereits Hybrid mit On-Prem1 arbeitet. Ansonsten könnte es aber auch einfach nicht "gewollt" sein, einen HybridMode eines Tenant1 mit einer On-Prem2-Organisation aufzubauen

On-Prem2

Tenant1

Merger - Einbinden von Benutzern einer anderen Firma

Auch in die Gegenrichtung ist es nicht einfach, da kein DirSync on On-Prem2 mit Tenant1 eingerichtet werden kann und auch Hybrid ausscheidet.

Tenant1

Tenant2

Splitt oder Migration in anderen Tenant

In diesem Fall werden Benutzer und ihre Daten von einem Tenant in einen anderen Tenant verschoben. Das kann ein Teilverkauf einer Gruppe sein oder eine Komplett-Migration zu einem anderen Cloud Dienstleister oder DE-Cloud

Tenant2

Tenant1

Merge in den Zieltenant

Dieses Szenario beschreibt den Sonderfall, dass das Ziel nicht "leer" ist und damit insbesondere dort auch ein DirSync aktiv sein kann. In dem Fall können Exchange Properties nicht in der Cloud direkt verändert werden. Bei diesem Fall gehe ich aber davon aus, dass die Quelle und das Ziel unterschiedliche AD-Forests sind und daher schon zwei DirSync aktiv sind und Änderungen lokal vorgehalten werden.

Identität = UPN = eindeutig

Der Dreh und Angelpunkt bei einer "Cross Tenant" Migration ist wie immer die "Identität" des Anwenders. Was On-Prem das Active Directory Konto ist, ist in der Cloud der Benutzer mit einem UPN als Anmeldekonto. Der große Unterschied ist hier aktuell, dass das lokale AD-Konto eine SID hat, die bei einer Migration in einen andere Domäne sich ändert und maximal als SIDHistory mitgenommen werden kann. In Office 365 gibt es weder SID noch Kerberos aber der UPN und einige interne GUIDs) sind hier maßgeblich für die Berechtigungen der Anwender.

Anders als eine SID kann ein UPN problemlos von einem Tenant zu einem anderen Tenant mitgenommen werden. Das Problem ist nur, dass der Domainpart eines UPN immer nur genau einem Tenant zugewiesen sein kann. Wenn also in der Quelle Personen die gleiche UPN-Domain nutzen, und nur ein Teil der Anwender in einen neuen Tenant überführt werden sollen, dann können Sie ihren UPN nicht mitnehmen. Sie bekommen in der neuen Umgebung einen neuen UPN und damit auch zwingend eine neue SIP-Adresse.

Eine "langsame Migration" von Benutzern in Gruppen geht nur, wenn die Benutzer im neuen Tenant zwingend einen neuen UPN nutzen. Das ist sogar ein sehr wahrscheinlicher Fall, denn einen neuer Tenant ist in der Regel auch eine neuen Firma mit einem neuen Namen. Aber auch wenn alle Konten, die ein den neuen Tenant überführt werden, die gleiche UPN-Domain nutzen und dies ein dem Quell-Tenant nicht mehr benötigt wird, ist ein Umzug nicht einfach mal so möglich. Zuerst muss der Quell-Tenant den UPN frei geben, ehe dann der neue Zieltenant diese Domäne registrieren kann. Die Quelle kann den UPN aber nur dann mitnehmen, wenn alle Benutzer gelöscht wurden oder einen anderen UPN temporär erhalten haben.

Wenn die Anzahl der Benutzer überschaubar ist, dann könnte man im Ziel erst einmal Benutzer als "ziel.onmicrosoft.com"-Konten anlegen und die Daten von der Quelle in das Ziel kopieren. Dann muss es irgendwann eine "Frozen Zone" geben, in der die Anwender in der Quelle  nicht mehr arbeiten dürfen und folgende Schritte erfolgen:

  1. UPN in der Quelle ändern, z.B. auf eine temporäre Domäne oder auf "<quelltenant>.onmicrosoft.com
    Bei per DirSync gepflegten Benutzern ist das etwas aufwändiger, da eine Änderung des UPN On-Premises den UPN in der Cloud nicht ändert
  2. Freigeben der Domäne in der Quelle und Zuweisen der Domäne an den Zieltenant
    Die Domäne wird in dem Quell-Tenant freigegeben, damit sie dann im Ziel-Tenant registriert werden kann. Das kann je nach DNS-Replikation etc einige Zeit dauern
  3. Zuweisen des richtigen UPN im Ziel
    Nun können die Benutzer im Ziel, die bislang nicht zum Anmelden genutzt wurden aber natürlich schon auf den übertragenen Daten und Postfächern berechtigt sind, den richtigen UPN bekommen. In Verbindung mit ADSync ist auch hier der UPN dennoch von Hand zu ändern.
  4. Aktivierung des Zieltenant
    Nun ist es an der Zeit, dass die Anwender im Ziel "online" gehen können und weiter arbeiten. Dazu muss natürlich auch ADFS eingerichtet werden, der MX-Record für die Domäne gedreht werden u.a.
  5. Datenreplikation
    Zuletzt sollten Sie noch mal die verschiedenen Datentöpfe betrachten, die die Anwender bislang genutzt haben zwischenzeitlich aufgelaufene Änderungen noch in das Ziel übertragen.

Hoffen wir, dass bei einer Cross-Tenant-Migration ein neuer UPN genutzt wird. Das macht schon einiges einfacher in Bezug auf die Identitäten.

Was ist mit den Daten?

Interessanter wird es bei der Migration der Anwenderdaten in den neuen Tenant. Da muss man schon mal etwas genauer hinschauen. Kaum jemand wird die Daten erst von einem Tenant herunterladen und danach im neuen Tenant wieder hochladen. Wenn eh schon alle Daten in Office 365 liegen, könnte man diese doch direkt dort übertragen. Leider gibt es genau dafür von Microsoft kaum Unterstützung. Wir wissen ja alle, wie Exchange funktioniert und eigentlich müsste man ja nur den Verweis auf das Postfach (msExchMailboxGUID) an das neue Objekt hängen. Aber genau das geht z.B. in der Cloud ebenso wenig wie das Umhänge von OneDrive-Laufwerken und anderen Datentöpfen. Wir kommen nicht um eine Migration herum, bei der die Daten aus der Quelle ausgelesen und in das Ziel übertragen werden.

Das geht aber je nach Datenmenge für Exchange und SharePoint nicht so schnell. Also müssen Sie überlegen, ob Sie die umgestellten User im Ziel mit "leeren" Töpfen starten lassen wollen und die Daten "nachliefern" oder ob vorab schon mal die Daten ins Ziel kopiert werden und man nach dem "Switch" die letzten Änderungen nachholt. Eine zeitnahe "Synchronisation" von Daten ist nur bei ganz kleinen Umgebungen möglich und selbst hier müssen Sie aufpassen, dass die immer vorhandenen Replikationskonflikte sie nicht mehr Zeit kosten als eine kurze "Frozen Zone" mit einer Umstellung zu einem Stichtag.

Eine Herausforderung bleibt natürlich neben der Datenübernahme selbst auch das Aussperren der Benutzer im Ziel bis zum Umschaltmoment und dann in der Quelle. Dabei muss auch beachtet werden, dass auch andere bereits im Ziel vorhandene Benutzer vorab replizierte Daten verändern könnten und auch nach dem Umschalten die Quellen nicht nur von den betroffenen Anwendern gegen Veränderung geschützt werden müssen, sondern eben auch von zurück gebliebenen Konten, die vielleicht als Stellvertreter darauf Zugriff haben. Vergessen Sie dabei auch nicht, dass einige Datentöpfe per SMTP erreichbar sind oder über "veröffentliche URLs", die nach dem Umschalten nicht mehr gültig sind.

Je mehr Daten zu verlagern sind, desto weniger attraktiv ist eine Verlagerung über Clients oder Service in ihrem eigenen LAN. Ich sehe da folgende Abstufung:

  1. Migration durch Microsoft
    Sofern dies einmal möglich sein wird. ist dieser Weg sicher prädestiniert zum Umzug von Daten
  2. Migration über 3rd Party in Azure oder Hosted
    Als zweite Option ist ein Drittprodukt durch den Anbieter selbst oder z.B. in einer Azure-VM zu sehen. Einige Drittanbieter nutzen selbst Azure als Plattform und sind damit auch sehr nahe an Office 365 dran.
  3. Lokale Migration durch Admin
    An dritter Stelle steht der Umzug durch eine On-Prem eingesetzte Software. Das kann relevant sein, wenn der Betrieb in Azure oder sonst wie gehostet nicht möglich ist. Azure erlaubt Windows- und Linux-VMs aber vielleicht sprechen z.B. Datenschutzbedenken gegen das Auslagern von Anmeldedaten.
  4. Migration durch Anwender
    Nur wenn andere Optionen technisch nicht möglich sind, muss der Anwender herhalten. Das ist natürlich der schlechteste Weg, da es den Anwender (und die Systeme) belastet aber vor allem Fehleranfällig ist. Schließlich sind Anwender keine "Spezialisten für Migration".

Erschwerend kommt dazu, dass die Migration natürlich je Produkt zu sehen ist.

Übersicht nach Produkten

Ich versuche diese Liste aktuell zu halten, aber ich verfolge auch nicht alle Produkte in Echtzeit. Wenn ihnen Änderungen bekannt sind, dann beschreiben Sie diese doch gerne auf ihrem Blog und ich addiere einen Link oder geben Sie einen Tipp, dass ich die Abschnitte erweitern kann.

Siehe dazu auch Tentant2Tenant Client

Produkt  

Exchange Online

Microsoft hat noch keine Tools und selbst eine Cutover oder Staging Migration geht nur mit Exchange On-Prem als Quelle und leider (noch) nicht zwischen Tenants. Hier sind also Drittprodukte angesagt, wenn Sie nicht über PST-Dateien oder eine Rückmigration über Hybrid-Mode gehen wollen.

Man kann in der Zeit der Migration über die "TargetAddress" erreichen, dass irrtümliche Mails an das noch nicht aktive Postfach an das aktive Postfach geroutet werden. Eine Koexistenz mit Frei/Belegt-Zeiten ist zwischen verschiedenen Tenants ja durchaus möglich.

Nur ob eine Koexistenz wirklich erforderlich ist, sollten Sie unbedingt vorab klären. Es ist ein nicht unerheblicher Aufwand damit verbunden.

Skype Business

In Skype Business gibt es im Gegensatz zu Exchange nur wenige Dinge, die für eine Übernahme in betrachte kommen.

  • SIP-Adresse
    Diese ist sowieso an den UPN gebunden. Mit dem Umzug der Identität kommt die Adresse mit und der Anwender bleibt bei Federation Partnern aktuell. Mit einem neuen UPN müssen Partner den Anwender nur addieren. Leider gibt es kein
  • Buddy-Liste
    Der zweite Datenbestand in Skype for Business sind die eigenen Buddylisten, die sowohl interne als auch externe Kontakte enthalten können. Mit dem "Unified Contact Store" liegen die Daten in Exchange und wären sehr einfach zu migrieren. Leider hat dieses Feature Microsoft in Skype Business Online per Default wieder abgeschaltet und ein Zugriff per UCMA o.a. ist aktuell nicht möglich. Wenn, dann können die Daten nur durch den Anwender selbst übertragen werden.
  • Konferenz-Einladungen und Inhalte
    Mit dem Umzug ändert sich die Meeting URL und Meeting-ID. Da mit werden alle geplanten Termine in Outlook ungültig. Die kann der Anwender durch ein Tool aktualisieren. Eventuell vorab hochgeladene Inhalte müssen aber erneut bereitgestellt werden
  • Rufnummer
    Wenn der Anwender Skype Business Online mit Telefonie nutzt, dann wird es interessant zu erfahren, wann und wie eine Rufnummer mitgenommen werden könnte. Aktuell ist sie an den Tenant gebunden und selbst wenn der abgebende Tenant diese Nummer "zurückgibt" habe ich noch nie gesehen, dass ich eine Nummer "wünschen" kann.

SharePoint

Meines Wissens gibt es keine Hilfsmittel von Microsoft um Daten zwischen SharePoint Instanzen zu verlagern. Es läuft daraus hinaus, wie heute schon mit Drittprodukten die Daten zu verlagern.

OneDrive Business

Daten in OneDrive Business können meines Wissens nicht direkt zwischen zwei Tenants übertragen werden. Hier ist aktuell wohl der Anwender gefordert. Technisch könnte aber ein Programm auf dem lokalen PC die Daten aus dem synchronisierten Bereich woanders hin kopieren und später wieder zurückspielen.

Azure VMs

VMs könne in Azure exportiert und importiert werden. Ob es sinnvoll ist, eine VM umzuziehen, muss im Einzelfall entschieden werden. Technisch sollte es aber möglich sein, dass eine Transfer-VM mit Storage genutzt wird, um die Quell-VM als Container auszulagern und dann direkt in das Ziel einzulagern. Es geht aber wieder nur über einen Zwischenschritt, wobei diese VM natürlich "gut angebunden" sein sollte.

Der Gas ist in der Zeit natürlich "Down" und wenn Sie die VM als Domänenmitglied betreiben, dann muss diese im Ziel natürlich umfangreich konfiguriert werden. Letztlich steht man dann wieder vor der Wahl, ob sich der Aufwand lohnt oder man nicht einfach die relevanten Daten und Einstellungen in eine neue Zielumgebung umsetzt und umschwenkt.

Weitere Dienste und Komponenten werde ich bei Gelegenheit addieren.

Weitere Links