T2T ADSync-Migration

Bei der Arbeit zum Artikel ADSync GALSync ist mit eine Besonderheit aufgefallen, die bei einer Tenant zu Tenant Migration ganz hilfreich sein kann. Das musste ich mal genauer untersuchen.

Achtung:
Dieser Artikel ist technisch sehr anspruchsvoll und eher schwierige Kost. Beachten Sie dazu auch die Seite ADSync GALSync.

1:N ADSync

Auslöser war eine Dokumente von Microsoft zu den AzureAD Topologien.

Mitten im Dokument findet sich folgendes Bild:

Microsoft pflegt die Dokumentation als Markdown-Dateien in GitHub, so dass sie einfacher ermitteln können, wann der Absatz und das das Bild eingeführt wurden.

Es war ein verspätetes Weihnachtsgeschenk, dass Microsoft offizielle dokumentiert, dass da gleiche AD-Objekt von mehreren ADSync-Instanzen gelesen und in unterschiedliche Tenants geschrieben werden dar. Allerdings listet Microsoft dabei auch gleich alle Einschränkungen auf. Die wichtigste Aussage ist sicher folgende:

Only one Azure AD tenant sync can be configured to write back to Active Directory for the same object. This includes device and group writeback as well as Hybrid Exchange configurations – these features can only be configured in one tenant. The only exception here is Password Writeback...

Ehe ich so etwas bei einem Kunden einsetze, möchte ich natürlich schon wissen, was da im Hintergrund passiert. Zumal es ja noch andere Ansätze gibt.

Kurfassung

Ehe Sie sich nun in die Langform des Artikels mit vielen Details meiner Tests stürzen, gebe ich hier erst eine Kurzfassung eines vermutlich eher häufigen Migrationsszenario wieder.

Phase Beschreibung

Startpunkt

Wir beginnen mit einer bestehenden Umgebung aus einem Forest und einem Tenant, die per ADSync verbunden sind. Die Domain "msxfaq.de" ist an den Tenant gebunden und die Anwender im lokalen AD haben einen UPN aus der Domain. Diverse Dienste können in der Cloud genutzt werden.

Schritt 1: neuer Tenant anbinden

Nun geht es darum, die Anwender mit oder ihrer Domain in einen neuen Tenant zu überführen. Früher habe ich dazu den neuen Tenant beantragt und manuell die gleichen Benutzer und Gruppen wie in der Quelle angelegt und mit einer Lizenz versorgt. Bei kleinen Firmen konnte die E5-Trial-Lizenz reichen oder die Teams Exploratory License. So konnte man etwas "sparsame" mit den Lizenzen sein, die man für den nächsten Schritt braucht.

Hier kommt nun aber die neue unterstützte Topologie von ADSync zum Einsatz. Anstatt die Identitäten im Ziel-Tenant von Hand oder per Skript anzulegen, kann ich eine zweite ADSync-Instanz installieren, die die gleichen Quell-Objekte ausliest und einfach in einen den neuen Ziel-Tenant schreibt. Im Ziel haben die Objekte den gleichen SourceAnchor und Gruppen werden auch mit den Mitgliedschaften übernommen. Ein Writeback in die Quell ist nicht erlaubt aber auch nicht erforderlich, da der erste ADSync ja die msDS-CconsistencyGUID schon geschrieben hat.

Allerdings haben die Objekte im Ziel natürlich nicht den gleichen UPN, da die Domain ja noch im Quell-Tenant steht.

Beachten Sie den Sonderfall msExchMailboxGUID bzw. MailboxGUID. ADSync2 repliziert auch diese Feld und verhindert damit die Anlage eines Postfachs in der Cloud. Das Zuweisen der Exchange -Lizenz triggert die Anlage einer Mailbox und nicht das Filtern der Mailboxguid

Schritt 2: Daten Migration

Nun habe ich in der Quell und im Ziel die gleichen Objekte und mit Lizenzen auch den passenden Speicherplatz. Ich kann mit entsprechenden Werkzeugen nun einfach die Inhalte aus der Quelle in das Ziel vorab synchronisieren. Einige Dinge gehen mit Bordmittel. Manchmal lohnen sich aber auch 3rd-Party-Tools. Darauf gehe ich hier nicht weiter ein.

Schritt 3: Domainumzug

Irgendwann kommen aber Moment, an dem die Domain in den neuen Tenant umgezogen wird. Je nach Umgebung kann es etwas kniffliger sein, die Domain im alten Tenant zu löschen. Wenn der alte Tenant sonst keine Funktion mehr hat, dann würde ich ADSync deinstallieren und DirSync abschalten, da die Entfernung der Domain dann alle Konten auf "<t1>.onmicrosoft.com umstellt.

Sobald ich die Domain im neuen Tenant aktiviert habe, dreht die Cloud alleine schon den UPN auf den richtigen Wert. Das AzureAD muss sich im Hintergrund schon gemerkt haben, wie der richtige UPN ist und es braucht nicht einmal ein ADSync-Durchlauf.

Nachdem der ADSync zum Quell-Tenant nicht mehr vorhanden ist, können Sie den neuen ADSync natürlich auch mit "WriteBack" konfigurieren.

Schritt 4: Nacharbeiten

Nur weil die Anwender im Ziel den gleichen UPN haben, sind es den noch neue AzureAD-Objekte mit einer eigenen GUID. Ensprechend gibt es ein paar Nacharbeiten wie:

  • Outlook-Profile und Teams Profile neu machen
  • Computer neu ins AzureAD aufnehmen
  • OneDrive-Partnerschaften neu einrichten
  • Gäste (Ausgehend und eingehend) neu einrichten und berechtigen

Das sind nur die wichtigsten Punkte.

Diese Kurzfassung kann keine ausführliche Tenant2Tenant-Migration beschreiben sondern hat nur das Ziel, die neue Option von ADSync zu erläutern, bei der zwei ADSync-Instanzen das gleiche lokale AD-Objekt lesen und in unterschiedliche Tenants schreiben können.

Ausgangssituation

Ich habe daher zwei meiner Labor-Umgebungen genutzt, die jeweils aus einem Domain Controller mit ADSync und dazugehörigen Tenant bestehen.

In der weiteren Beschreibung nutze ich folgende Zuordnung. Leider heißen meine Tenants und Forests nicht genau so. Daher ist folgende Übersetzungstabelle hilfreich:

Kennzeichen Realer Name Beschreibung

A1

DOM2016.msxfaq.de

Active Directory Forest mit den Benutzern, die von T1 nach T2 umgezogen werden sollen

A2

UCLABOR.DE

Active Directory Forest, in dem ADSync2 installiert ist. Wenn Sie nicht auch eine ADMT-Migration der Benutzer von A1 nach A2 vorhaben, können Sie diesen Forest einfach ignorieren und sich vorstellen, dass ADSync2 als zweiter Mitgliedsserver in A1 installiert wäre.

T1

fcarius.onmicrosoft.com

Der Tenant, indem die zu migrierenden Anwender aus A1 Anfangs angelegt sind.

T2

msxfaqlab.onmicrosoft.com

Der neue Zieltenant, in den die Anwender aus A1 am Ende landen sollen

Für die weitere Besprechung einer möglichen Migration können Sie sich den A2-Forest auch wegdenken und ADSync2 einfach ebenfalls mit dem Forest A1 verbinden. A2 ist also nur relevant, wenn Sie auch noch eine AD-Konten-Migration im lokalen AD betreiben müssen.

Einrichtung

Diese Umgebung habe ich nun derart angepasst, dass der ADSync2 zusätzlich auch noch die Objekte aus A1 liest.

Hinweis: ADSync blockiert die Einrichtung mit dem Hinweis, dass ms-ds-consitencyguid schon gefüllt wäre. Sie müssen ADSync dann mit der Option "/SkipLDAPSearch" starten:
Command-line switches for Azure AD Connect: https://dirteam.com/sander/2020/11/12/command-line-switches-for-azure-ad-connect/

Bei der Einrichtung über den Assistenten auf ADSync2 (Siehe auch ADSync Multi Forest)) wird in A1 ein weiteres Dienstkonto für den ADSync2 angelegt und identisch berechtigt:

Er arbeitet also komplett unabhängig vom ADSync1 und nach der Einrichtung ist das Bild um folgende Verbindungen erweitert worden:

Variante Beschreibung

Variante1: ADSync2 repliziert nur A1 und ist Mitglied von A1

Dies ist ein "einfachere" Version, bei der ich einige Personen einfach aus dem Tenant T1 in den Tenant T2 verlagern muss. Die lokalen AD-Konten bleiben aber "erst einmal" noch im gleichen Forest A1

Das ist durchaus gängig, wenn ein Teil einer Firma mit ihrer Domain aus dem bisherigen Tenant herausgelöst werden muss und schon viel in der Cloud macht, während die lokale Migration in einen eigenen Forest hinten angestellt wird.

Vielleicht möchte man zukünftig sogar mit Intune u.a. direkt ohne lokales AD arbeiten oder die lokale Umstellung ist einfacher, wenn die Anwender zumindest schon mal im richtigen Tenant sind.

In dem Fall wird der ADSync2-Server natürlich ebenfalls im Forest A1 mit installiert.

Sollt später noch noch mal ein eigener AD-Forest A2 nachinstalliert werden müssen, dann kann man ADSync2 zwei zwar nicht umziehen aber schon neu installieren und ist dann bei der Variante 2

Variante2: ADSync2 repliziert schon einen eigenen Forest A2

Aber natürlich kann es passieren, dass Sie einen komplett neuen Tenant mit eigenen AD-Forest und eigenem ADSync aufbauen. Auch dann müssen wir wissen, wie in diesem Fall sich ADSync2 verhält. insbesondere, wenn Objekte parallel mit ADMT o.ä. migriert werden und daher sowohl in A1 und A1 vorkommen.

Spoiler: Installieren Sie ADSync2 in dem Fall gleich mit der Option, dass es mehrere Objekte in mehreren Forests geben kann und er diese z.B. anhand der Mail-Adresse matched. Ansonsten bekommen Sie doppelte Accounts in T2

In meinem LAB ist ADSync Mitglied von A2, d.h. die komplexere Variante 2.

Achtung: ADSync1 und ADSync2 dürfen in der Konfiguration Niemals beide auf A1 zurückschreiben. Bei mindestens einem ADSync muss daher "Writeback" deaktivieren werden.

Synchronisation

Eine ausführlicher Beschreibung finden Sie auch auf ADSync GALSync. Die Seiten sind zeitgleich entstanden und nutzen die gleiche Umgebung.

Wenn ich dann in die ADSync-Protokolle schaue, dann sehe bei der ersten Synchronisation einen Delta-Import von A2 (UCLABOR.DE) und einen Full Import von A1 (DOM2016.msxfaq.de):

Im Tenant T2 erscheint der Benutzer aus A1. Da A2 allerdings noch nicht autoritativ für die von A1 und damit auch T1 genutzte Domain ist, bekommt der Benutzer eine "onmicrosoft.com"-Adresse.

Bei der nächsten Rückreplikation werden die nun "neuen" Objekte in T2 erneut erkannt und von ADSync2 zurückgeladen. Beim normalen Provisioning würde ADSync2 nun das Feld "msdsConsistencyGUID" im Forst A1 pflegen.

Siehe dazu die Details auf der Seite SourceAnchor

Das muss er aber diesmal nicht machen, da ADSync1 das schon macht.

Wenn Sie ADSync mit den Standardwerten installieren dann nutzt ADSync die ObjectGUID des Quell-Objects, um daraus die "ImmutableID" in der Cloud zu bilden. Die ImmutableID wird dann aber per Rückreplikation in das AD-Feld "msdsConsistencyGUID" zurückgeschrieben. Damit werden spätere Migrationen eines AD-Benutzers in einen anderen Forest möglich, denn dabei ändert sich die ObjectGUID aber ADSync nutzt die "msdsConsistencyGUID", um die Verbindung aufrecht zu erhalten.

Auch wenn in meinem Fall ADSync nun nichts zurückschreibt, so ist das keine Garantie, dass andere Änderungen in der Cloud nicht zurückschreiben. ADSync2 darf zu der Phase also nie die Checkboxen in Exchange Hybrid, Device Writeback, Groups Writeback haben.

Der Benutzer aus A1 ist nach der Synchronisation durch ADSync1 und ADSync2

Feld/Tenant Haupttenant FCARIUS Zweittenant MSXFAQLAB
Mail 
aduserA1@dom2016.msxfaq.de
 
aduserA1@dom2016.msxfaq.de
UserPrincipalName 
aduserA1@fcarius.onmicrosoft.com
 
aduserA1@msxfaqlab.onmicrosoft.com
On-PremisesSecurityIdentifier 
S-1-5-21-2342664329-2581643318-3890112866-1112
 
S-1-5-21-2342664329-2581643318-3890112866-1112
ImmutableId 
AdMmxQtWG0K6dmf8O3St8g==
 
AdMmxQtWG0K6dmf8O3St8g==

Wie nicht anders zu erwarten, kann der UPN aus A1 und T1 natürlich nicht in T2 genutzt werden und wird durch den "onmicrosoft.com"-Platzhalter ersetzt.

Das ist natürlich nur ein Objekte. Ich habe in meinem Testumgebung mehrere Benutzer und Gruppen über diesen Weg in die beiden Tenants synchronisieren lassen.

Exchange Postfach

Bei einer klassischen Tenant2Tenant-Migration haben sie nun natürlich die Aufgabe, im Ziel die Benutzer mit Lizenzen zu versehen und dann mit den Hilfsmitteln ihrer Wahl die Inhalte aus T1 nach T2 zu kopieren. Das können Sie teilweise mit Bordmitteln machen oder natürlich bekannte 3rd-Party Tools nutzen. Ich führe hier absichtlich keine Namen oder Produkte auf, damit diese nicht als Empfehlung missverstanden werden. Jede Migration hat sehr individuellen Anforderungen und machen einen Vergleich oder Empfehlung unmöglich . Die kontinuierliche Weiterentwicklung von Produkten und Microsoft APIs als auch diverse Firmenübernahmen erschweren.

In dem Zug könnten Sie auf das Problem stoßen, dass ihre Exchange Postfachmigration mit 3rd Party Tools nicht möglich ist, da Exchange Online sich weitert, dem Benutzer ein Cloud-Postfach zuzuweisen. Da der zweite ADSync auch die msexchMailboGUID kopiert, sieht es für Exchange Online so aus, als ob der Benutzer ein "On-Premises"-Postfach hat.

Wir müssen in dem Fall dafür sorgen, dass der neue Tenant keine Information über das bestehende Postfach im alten Tenant oder On-Premises bekommt. Das geht leider nur durch einen Eingriff im ADSync, um das Feld nicht in Cloud zu replizieren. Dazu gibt es zwei Optionen:

  • Exclude als Application
    Sie könnten in ADSync komplett die Replikation der Exchange Anwendung unterbinden. Dann haben Sie natürlich auch keinen Abgleich der ProxyAddresses etc., was schade ist.

    Daher kann es besser sein, nur die beiden störenden Felder auszuschliessen.
  • Anpassen der Synchronization Rule
    Der andere Weg ist der direkte Eingriff in den Abgleich der Element, indem Sie z.B. auf der "In from AD - User Exchange"-Regel den Import der Felder überschreiben. Denken Sie daran, nicht die Standardregel zu ändern sondern diese zu deaktivieren und eine Kopie zu erstellen, damit ein ADSync Update nicht ihre Änderungen wieder zurückdreht.

Danach sollte das Feld nicht mehr in die Cloud repliziert wird.

Kontrollieren Sie den Erfolg über die AzureADSync UI.

Es gibt noch einen "Sonderfall" zu betrachten, wenn Sie diese Änderungen erst nachträglich durchführen. Sie sollten dann kontrollieren, dass vielleicht bereits im Ziel vorhandene Informationen aktiv überschrieben und gelöscht werden:

Wenn das Online-Konto zu dem Zeitpunkt aber schon eine Exchange P1/P2-Lizenz hatte, dann triggert das Entfernen der MailboxGUID nicht die Neuanlage eines Postfachst. Aus Sicht von Exchange Online hat der Benutzer kein Postfach.

Lösung: Entfernen Sie beim dem Benutzer in Microsoft 365 den Exchange Plan und weisen Sie ihn nach einigen Minuten neu zu. Anscheinend triggert ein "Add License" im Hintergrund erst den "Enable-CloudMailbox" für den Benutzer.

Dann sollten Sie aber im Zieltenant entsprechende Benutzer mit leerem Exchange Online-Postfach haben, in welches nun ihre 3rd Party Lösung die Daten kopieren oder synchronisieren kann.

Datenmigration

Neben Exchange gibt es natürlich noch andere Datentöpfe, die sie im Rahmen einer Tenant2Tenant-Migration übertragen müssen. Die Qualität der Übertragung hängt stark von den Daten und dem Hilfsmittel ab. Mails, Termine und Kontakte sind einfacher zu migrieren. CDR-Report können gar nicht übertragen werden. SharePoint und OneDrive Dateien verlieren meist ihre Version und Zeitstempel. Letztlich ist es auch eine Frage der APIs, die Microsoft bereitstellt.

Domain Umzug

Wenn ihre Benutzer im Ziel sowieso einen neuen UPN bekommen sollen, dann sollten die die neue Domain schon im Ziel-Tenant aktiviert haben. Denn dann können Sie einfach den Konten in A1 einen neuen UPN verpassen. Wenn dann alles richtig funktioniert, wird ADSync1 diese Änderung in T1 schreiben, was aber nicht geht. Im Quelltenant wird dem Benutzer aber der UPN entfernt und er bekommt eine "onmicrosoft.com"-Adresse.

Der Benutzer "fctest1" hatte vorher noch die fctest1@uclabor.de aber nachdem ich lokal den UPN auf eine Domain geändert habe, die im Tenant nicht vorhanden ist, ändert sich der UPN auf die onmicrosoft.com.

Diese Änderung ist wichtig, damit ich die Domain in dem Tenant T1 auch entfernen kann. Siehe auch Office 365 Domain Umzug/Löschen

Wenn Sie im Ziel einfach eine eine "andere" Domain aktivieren, weil die Benutzer nicht nur in den anderen Tenant übertragen wurden sondern sich auch die Domain ändert, dann müssen Sie nur den UPN ändern und im Ziel-Tenant T2 die Domain aktivieren. Das habe ich mit einem anderen Benutzer getestet. Wenn ich im Tenant T2 eine Domäne aktivieren, die ich vorher T1 gelöscht habe, dann dreht AzureAD automatisch den temporären "onmicrosoft.com"-UPN auf die native Domain. Das können Sie im Audit-Log sehr schön sehen:

Interessant ist auch, dass bei "initiated" by" nichts drin steht und der Zeitstempel schön zeigt, dass ADSync schon länger keine Änderung mehr an dem Objekt vornehmen musste.

Aus meiner Sicht hat der AzureAD Provisioning Service den "richtigen" UPN im Hintergrund als "pending" gemerkt und wartet nur darauf dass die Domain im Tenant aktiviert wird.

Cleanup

Danach bleibt natürlich die Frage, wie Sie die ADSync1 und dem Tenant T1 umgehen. Wenn der Forest A1 zukünftig nur noch mit T2 verbunden sein soll, dann wäre es an der Zeit die Verbindung von ADSync1 zu entfernen. T1 kann ja noch einige Wochen weiter laufen, wenn Sie noch irgendwelche Daten weiter erneut migrieren wollen.

Aber natürlich sind noch ganz viele andere Optionen denkbar, die ich aber hier nicht alle beschreiben kann.

Sonderfall: Andere UPN-Domain

Normalerweise synchronisiert ADSync aus dem lokalen AD das Feld "UserPrincipalName" in die Cloud als Cloud UPN / Anmeldename. Das ist aber nicht zwingend, denn über den Alternate Login ID kann ich natürlich auch ein anderes Feld des lokalen AD dazu nutzen. Damit ist es aber auch denkbar, dass ein Benutzer in zwei Tenants mit unterschiedlichen UPNs arbeitet.

Dieser Fall beschreibt auch eine Migration in einen anderen Tenant mit dem Wechsel der UPN-Domain. Dieser Fall ist gar nicht mal so selten und beschreibt üblicherweise die CarveOut oder Merger-Projekte, in denen eine Firma einen Teil mit einem neuen Namen ausgliedert oder von einer anderen Fima einen Teil eingliedert.

Sonderfall Desktops

ADSync ist nicht nur für den Abgleich von Benutzern und Gruppen zuständig, sondern auch Computer können im AzureAD "Domainmitglied" werden. Dazu können Sie in ADSync einen Service Connection Point konfigurieren.

Über diese Konfiguration wird im lokalen AD dann ein Eintrag hinterlegt, damit die Clients wissen, bei welchem Tenant sie sich anmelden können. Ein SCP ist aber immer pro Forest und nicht mit einem Scope versehen. Daher ist es keine gute Idee, in mehreren ADSync-Installationen diesen Wert zu setzen.

Wenn Sie Computer aus einem AD-Forest in unterschiedlichen Tenants registrieren möchten, dann müssen sie die Konfiguration über eine lokale Konfiguration in der Registrierung vorgeben.

Wichtig: Damit diese Einstellung wirksam wird, müssen Sie den SCP entfernen

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]
"TenantID"="<tenantid>"
"TenantName"="<tenant>.onmicrosoft.com"

Dies kann natürlich auch per Gruppenrichtlinien oder Software-Verteilung erfolgen.

Entsprechend müssen Sie beim Umzug eines Benutzers samt Client natürlich auch auf dem Client die AzureAD-Mitgliedschaft entfernen und nach Zuweisung der neuen Richtlinie wieder aktivieren

Zusammenfassung

Bei einer klassischen Tenant2Tenant-Migration legen Sie im Ziel T2 die Benutzer von Hand oder per Skript oder Tool als "onmicrosoft.com"-Konten an, kopieren die Inhalte und stellen zu einem Stichtag die Domain um und lassen ADSync2 die Objekte "matchen" und aktualisieren. Der letzte Schritt ist bislang immer etwas Nervenkitzel und während der Migration müssen Sie immer darauf achten, die Änderungen in der Quelle auch im Ziel nachzuführen, d.h. Benutzer anlegen/ändern/Löschen und auch Mitgliedschaften in Gruppen pflegen.

Mit der Option das gleiche Quell-Objekte mit zwei ADSync-Instanzen in zwei Tenants identisch zu managen, ersparen Sie sich manuelle Updates im Ziel und auch die ImmutableID ist schon optimal vorbereitet, um den Wechsel gefahrlos durchzuführen.

Allerdings sollten sie schon aufpassen, dass nur nicht beide ADSync-Instanzen ein WriteBack machen. Das bedeutet auch, dass nur ein Tenant einen Exchange Hybrid Mode nutzen kann und eine Migration der Benutzer von A1 nach A2 mit ADMT oder anderen Tools habe ich hier nicht weiter ausgeführt. Es sollte nicht passieren, dass in A1 und A2 Benutzer mit der gleichen msdsConsistencyGUID vorliegen, die vom gleichen ADSync gelesen werden.

Wenn Sie Unterstützung bei Migrationen, Merger, Akquisition und CarveOuts brauchen, dann können Sie meine Kollegen bei Net at Work oder mich gerne ansprechen.
Net at Work und MSXFAQ.

Weitere Links