Mehrere AD-Domains in einen Entra-Tenant synchronisieren

Ob, wie und mit welchen Fallstricken – ein Praxisleitfaden für Multi-Domain- und Multi-Forest-Umgebungen

Ulrich B. Boddenberg

boddenberg.de · IT-Consulting · Software Engineering · Technologieseminare

Juli 2026

 

Inhalt

 

Executive Summary

Die kurze Antwort auf die Titelfrage vorweg: Ja, das geht – und zwar deutlich entspannter, als viele befürchten. Ein Entra-Tenant ist ausdrücklich dafür gebaut, Identitäten aus mehreren Active-Directory-Domains und sogar aus mehreren, völlig getrennten Forests aufzunehmen. Microsoft liefert dafür gleich zwei Werkzeuge mit: den klassischen Entra Connect Sync (der dicke Dampfer mit allen Optionen) und den moderneren Entra Cloud Sync (das Schnellboot mit leichtgewichtigen Agenten).

Die eigentliche Arbeit steckt erfahrungsgemäß nicht in der Sync-Technik, sondern in der Datenhygiene: nicht-routbare UPN-Suffixe wie .local, doppelte Mailadressen über Forest-Grenzen hinweg, historisch gewachsene Attribut-Wildwüchse und die Frage, ob ein und derselbe Mensch in zwei Verzeichnissen existiert und in der Cloud zu einem Objekt zusammengeführt werden muss.

Dieser Artikel klärt die Architekturfragen (Kapitel 4), benennt die typischen Stolpersteine aus der Beratungspraxis (Kapitel 5) und liefert einen konkreten, nachvollziehbaren Aktionsplan inklusive Rollback-Optionen (Kapitel 6). Wer nur drei Sätze mitnehmen will: Pro Tenant genau ein aktiver Connect-Server. Pro AD-Objekt genau ein Tenant. Und: Erst die Daten aufräumen, dann synchronisieren – nicht umgekehrt.

 

Die drei goldenen Regeln 1. Ein Tenant hat genau einen aktiven Entra-Connect-Server (weitere nur im Staging Mode). 2. Ein AD-Objekt wird in genau einen Tenant synchronisiert – niemals in mehrere. 3. Jedes UPN-Suffix, mit dem sich Benutzer anmelden sollen, muss als Domain im Tenant verifiziert sein.

 

Ausgangssituation und Scope

Kaum eine gewachsene IT-Landschaft besteht aus einem einzigen, blitzsauberen Active Directory. In der Praxis begegnen einem vor allem vier Konstellationen, die alle auf dieselbe Frage hinauslaufen: Wie bekomme ich das alles ordentlich in einen Entra-Tenant?

Der gewachsene Forest: Eine Root-Domain plus mehrere Child-Domains – oft aus Zeiten, in denen man pro Standort oder Land eine eigene Domain für eine gute Idee hielt.

Die Übernahme (M&A): Das Stammhaus hat seinen Forest, die frisch zugekaufte Tochter bringt ihren eigenen mit. Beide sollen möglichst schnell in einem gemeinsamen Microsoft-365-Tenant zusammenarbeiten.

Der Konzern mit Parallelwelten: Mehrere rechtlich oder organisatorisch getrennte Forests, teils mit Trust, teils bewusst ohne – aber ein gemeinsamer Auftritt in der Cloud ist gewünscht.

Das Account-/Ressourcen-Forest-Erbe: Ein Relikt aus alten Exchange-Tagen: Benutzerkonten leben in Forest A, die Postfächer (mit deaktivierten Schattenkonten) in Forest B. Beides gehört zum selben Menschen.

 

Der Scope dieses Artikels: die Synchronisation lokaler AD-Identitäten (Benutzer, Gruppen, Kontakte, Geräte) in einen einzelnen Entra-Tenant – also das klassische Hybrid-Identity-Szenario. Ausdrücklich nicht behandelt werden die Cross-Tenant-Synchronisation zwischen zwei Entra-Tenants, Tenant-zu-Tenant-Migrationen nach Konzernabspaltungen sowie B2B-Gastszenarien. Das sind eigene, durchaus spannende Baustellen – aber eben andere.

 

Begriffsklärung Wenn hier von „Entra Connect Sync“ die Rede ist, ist das Produkt gemeint, das viele noch als „Azure AD Connect“ kennen. Gleiches Werkzeug, neuer Name – Microsoft hat 2023 die komplette Azure-AD-Produktfamilie in „Microsoft Entra“ umgetauft. Die Konzepte in diesem Artikel gelten unverändert.

 

Technischer Hintergrund: Architekturen und Konzepte

Dieses Kapitel klärt das Warum: Welche Topologien werden unterstützt, wie entscheidet die Sync-Engine, welche Objekte zusammengehören, und wo verlaufen die harten Grenzen? Wer das verinnerlicht hat, für den ist der Aktionsplan in Kapitel 6 reines Handwerk.

Der einfache Fall: ein Forest, mehrere Domains

Fangen wir mit der guten Nachricht an: Mehrere Domains innerhalb eines Forests sind für Entra Connect Sync ein Heimspiel. Der Konfigurations-Assistent verbindet sich mit dem Forest, listet alle Domains auf, und Sie entscheiden per Häkchen, welche Domains und welche Organisationseinheiten (OUs) mitspielen dürfen. Ein Server, eine Konfiguration, fertig.

Skizze 1: Ein Forest mit mehreren Domains – der unkomplizierte Standardfall.

Das Domain- und OU-Filtering ist dabei Ihr Freund: Niemand zwingt Sie, den kompletten Verzeichnisbestand inklusive Dienstkonten-Friedhof und Test-OUs in die Cloud zu schieben. Weniger ist hier mehr – jedes synchronisierte Objekt ist eines, das Sie später pflegen, lizenzieren oder erklären müssen.

Der interessante Fall: mehrere Forests, ein Connect-Server

Jetzt wird es spannender: Mehrere unabhängige Forests in einen Tenant. Auch das ist ein offiziell unterstütztes Standardszenario – mit einer Architektur, die viele überrascht: Es bleibt bei einem einzigen Connect-Server. Dieser eine Server bekommt pro Forest einen eigenen Konnektor (sprich: eigene Verbindungsdaten und ein eigenes Konto) und führt alle Verzeichnisse in seiner internen Datenbank, dem sogenannten Metaverse, zusammen.

Skizze 2: Zwei Forests, ein Connect-Server, ein Tenant – ein Forest-Trust ist dafür nicht erforderlich.

Der Knackpunkt ist nicht die Software, sondern das Netzwerk: Der Connect-Server muss die Domänencontroller aller angebundenen Forests erreichen und deren DNS-Namen auflösen können. Ein Forest-Trust ist ausdrücklich nicht nötig – wohl aber Firewall-Freischaltungen und eine saubere DNS-Strategie (typischerweise über bedingte Weiterleitungen). Die wichtigsten Ports:

 

Protokoll/Dienst	Port	Wofür
DNS	53 TCP/UDP	Namensauflösung der DCs im fremden Forest
Kerberos	88 TCP/UDP	Authentifizierung
RPC Endpoint Mapper	135 TCP	Verbindungsaufbau zu AD-Diensten
LDAP / LDAPS	389, 636 TCP	Verzeichniszugriffe
SMB	445 TCP	u. a. Kennwort-Rückschreiben, Sysvol
Global Catalog	3268, 3269 TCP	forestweite Suchen
RPC dynamisch	49152–65535 TCP	AD-Replikations- und Verwaltungsverkehr

 

Praxistipp aus dem Beratungsalltag Nach einer Übernahme sind die Netze oft noch gar nicht gekoppelt. Dann lohnt der Blick auf Entra Cloud Sync (siehe unten): Dessen Agenten brauchen nur ausgehendes HTTPS – die leidige Standortvernetzungs-Diskussion können Sie damit elegant vom Identitätsprojekt entkoppeln und in Ruhe später führen.

Die harten Grenzen: was nicht geht

Bevor wir weiter in die Möglichkeiten einsteigen, ziehen wir die Leitplanken ein. Zwei Konstruktionen tauchen in Workshops immer wieder als Wunsch auf – und beide sind schlicht nicht supportet:

Skizze 3: Zwei Klassiker aus der Kategorie „klingt praktisch, ist aber verboten“.

Mehrere aktive Connect-Server auf denselben Tenant: Die Idee „jeder Standort betreibt seinen eigenen Sync-Server“ endet im Objekt-Pingpong. Pro Tenant exportiert genau ein Connect-Server. Die einzige legitime zweite Instanz ist ein Server im Staging Mode (dazu gleich mehr).

Ein AD-Objekt in mehrere Tenants: Ein Benutzerobjekt wird in genau einen Tenant synchronisiert. Wer denselben Menschen in einem zweiten Tenant braucht, arbeitet dort mit B2B-Gästen oder Cross-Tenant-Synchronisation – aber nicht mit einem zweiten Verzeichnis-Sync desselben Objekts.

 

Achtung Vorsicht auch beim umgekehrten Fall: Wenn in einem der Forests bereits ein alter Connect-Server in einen anderen Tenant synchronisiert (etwa der Alt-Tenant der übernommenen Firma), müssen Sie sauber entflechten, bevor Sie die Objekte in den Ziel-Tenant aufnehmen. Einfach „zusätzlich“ synchronisieren geht nicht – ein Objekt, ein Tenant.

sourceAnchor und Objekt-Matching: Wer gehört zu wem?

Damit die Sync-Engine ein AD-Objekt dauerhaft und eindeutig seinem Cloud-Gegenstück zuordnen kann, braucht sie einen unveränderlichen Anker – den sourceAnchor. Seit Jahren ist hier ms-DS-ConsistencyGuid der empfohlene Standard: Der Wert wird beim ersten Sync aus der objectGUID befüllt und übersteht danach auch Verschiebungen des Objekts zwischen Domains oder Forests. Genau deshalb ist er in Multi-Forest-Szenarien Pflichtprogramm – wer heute noch auf der nackten objectGUID sitzt, sollte das vor der Erweiterung geraderücken.

Die zweite zentrale Frage stellt Ihnen der Einrichtungs-Assistent wörtlich: Sind Ihre Benutzer über alle Verzeichnisse hinweg nur einmal vorhanden – oder existieren Identitäten mehrfach? Im zweiten Fall (klassisch: Account- und Ressourcen-Forest oder GAL-Sync-Historie) müssen die Duplikate im Metaverse zu einem einzigen Cloud-Objekt verheiratet werden. Dafür bietet der Assistent mehrere Matching-Verfahren an:

Skizze 4: Ein Mensch, zwei Forests – der Join im Metaverse macht daraus ein einziges Entra-Objekt.

mail-Attribut: Beide Konten tragen dieselbe Mailadresse – der Klassiker für zusammengewachsene Umgebungen.

ObjectSID und msExchMasterAccountSid: Das Standardpärchen für Account-/Ressourcen-Forest-Szenarien mit verknüpften Postfächern.

sAMAccountName und MailNickName: Wenn Kontonamen konsistent gepflegt sind – in der Praxis seltener belastbar, als man hofft.

Ein selbst gewähltes Attribut: Etwa die Personalnummer in einem Erweiterungsattribut. Aufwendiger zu befüllen, dafür maximal kontrollierbar.

 

Achtung: Matching ist eine Einbahnstraße mit Anlauf Wenn das Matching beim ersten Sync danebengreift, landen doppelte Benutzer im Tenant – inklusive Chaos in der globalen Adressliste und bei Lizenzen. Das nachträgliche Aufräumen ist deutlich schmerzhafter als eine saubere Vorbereitung. Also: Match-Attribute vorher prüfen und befüllen, erst dann den großen Hebel umlegen.

Die Alternative: Entra Cloud Sync

Entra Cloud Sync verfolgt einen anderen Ansatz: Statt eines zentralen, dicken Sync-Servers installieren Sie in jedem Forest einen leichtgewichtigen Provisioning-Agenten. Die gesamte Sync-Logik, Konfiguration und Attribut-Zuordnung lebt im Entra-Portal in der Cloud. Der Clou für Multi-Forest-Szenarien: Die Agenten brauchen lediglich ausgehendes HTTPS – die Forests müssen sich untereinander weder sehen noch vertrauen.

Skizze 5: Cloud Sync mit einem Agenten je Forest – ohne jede Netzwerkverbindung zwischen den Standorten.

Klingt nach der Universallösung? Fast. Cloud Sync ist bewusst schlanker gehalten und beherrscht (Stand heute) nicht das komplette Funktionsspektrum des großen Bruders. Die Entscheidungshilfe:

 

Kriterium	Entra Connect Sync	Entra Cloud Sync
Architektur	Ein zentraler Sync-Server mit lokaler Datenbank (Metaverse)	Leichtgewichtige Agenten je Forest, Logik in der Cloud
Multi-Forest ohne Netzkopplung	Nein – Server braucht Sicht auf alle DCs	Ja – nur ausgehendes HTTPS je Agent
Anpassbare Sync-Regeln	Sehr mächtig (eigene Regeln, Ausdrücke)	Attribut-Mapping im Portal, bewusst reduziert
Gerätesynchronisation (Hybrid Join)	Ja	Nein – Geräte bleiben Sache von Connect Sync
Kennwort-Hash-Sync / Writeback-Szenarien	Voller Funktionsumfang	Kernszenarien abgedeckt, Details je Feature prüfen
Sehr große Gruppen und Sonderfälle	Bewährt auch bei großen Objektmengen	Limits beachten (u. a. Gruppengröße)
Hochverfügbarkeit	Staging-Server (manuelles Failover)	Einfach mehrere Agenten je Forest installieren
Betriebsaufwand	Server patchen, Versionen pflegen	Agenten aktualisieren sich weitgehend selbst

 

Wichtig: Die beiden Werkzeuge schließen sich nicht aus. Ein durchaus übliches Muster ist der Parallelbetrieb mit sauberer Arbeitsteilung – Connect Sync bedient die Hauptforests (inklusive Geräte-Sync), Cloud Sync nimmt einen abgelegenen oder frisch zugekauften Forest mit, an den der Connect-Server netzwerktechnisch nicht herankommt. Einzige eiserne Bedingung: Beide dürfen sich nicht um dieselben Objekte kümmern. Jede Domain bzw. OU gehört exklusiv einem der beiden Werkzeuge.

Hochverfügbarkeit: der Staging-Server

„Ein einziger aktiver Sync-Server? Und was ist, wenn der ausfällt?“ – berechtigte Frage. Die Antwort heißt Staging Mode: ein zweiter Connect-Server mit identischer Konfiguration, der brav alle Verzeichnisse mitliest, aber nichts exportiert. Fällt der aktive Server aus, schalten Sie den Staging-Server per Konfigurationsassistent scharf – ein Vorgang von wenigen Minuten, sofern man ihn geübt hat.

Skizze 6: Der Staging-Server liest mit, exportiert aber nicht – Failover per Konfigurationsschalter.

Praxistipp Ein Staging-Server, dessen Failover noch nie getestet wurde, ist kein Notfallplan, sondern Dekoration. Einmal jährlich den Schwenk proben – und dabei gleich prüfen, ob die Konfiguration beider Server wirklich noch identisch ist (Stichwort: nachträglich angepasste Sync-Regeln, die nur auf dem aktiven Server gepflegt wurden).

Attribut-Hygiene: UPN, proxyAddresses und Freunde

Zum Schluss des Grundlagenkapitels das Thema, das in Projekten die meiste Kalenderzeit frisst: die Daten selbst. Drei Dauerbrenner:

UPN-Suffixe: Benutzer melden sich in der Cloud mit ihrem UserPrincipalName an. Ein Suffix wie @contoso.local ist im Internet nicht verifizierbar – solche Konten landen mit dem unschönen Fallback @tenant.onmicrosoft.com in der Cloud. Die Lösung: routbare UPN-Suffixe (z. B. @contoso.com) im AD nachrüsten, als Domain im Tenant verifizieren und die Benutzer umstellen – pro Forest, pro Domain, konsequent.

proxyAddresses und mail: Mailadressen müssen über den gesamten Tenant eindeutig sein. Was in zwei getrennten Forests jahrelang friedlich koexistierte, kollidiert beim Sync in Sekunden. Duplikate vorher finden und bereinigen – sonst bleiben Objekte mit Exportfehlern auf der Strecke.

Ungültige Zeichen und Formatfehler: Leerzeichen im UPN, Umlaute an falscher Stelle, überlange Werte – Microsofts kostenloses Werkzeug IdFix findet diese Klassiker in Minuten und schlägt gleich Korrekturen vor. Pflichtlauf vor jedem Sync-Projekt, je Forest.

 

Typische Analysebefunde aus der Praxis

Die folgenden Befunde stammen aus realen Multi-Domain- und Multi-Forest-Projekten. Nutzen Sie die Liste als Spiegel für die eigene Umgebung – wer sich hier wiedererkennt, weiß, wo er vor dem ersten Sync ansetzen muss.

Kritisch

Nicht-routbare UPN-Suffixe (.local, .intern): Benutzer würden mit @tenant.onmicrosoft.com in der Cloud landen – für produktive Anmeldung und Mailfluss inakzeptabel.

Doppelte Mailadressen über Forest-Grenzen: Identische proxyAddresses- oder mail-Werte in beiden Forests ohne Matching-Strategie führen zu Exportfehlern oder – schlimmer – zu Duplikaten im Tenant.

Alt-Synchronisation in einen anderen Tenant: Ein Forest hängt noch am Tenant der früheren Muttergesellschaft. Ohne saubere Entflechtung (Sync beenden, Objekte in Cloud-only überführen oder löschen, Anker bereinigen) ist keine Neuaufnahme möglich.

Geplanter Parallelbetrieb zweier aktiver Connect-Server: Taucht regelmäßig in Konzepten auf und muss ersatzlos gestrichen werden – siehe Kapitel 4.

Mittel

Kein Staging-Server vorhanden: Der einzige Connect-Server ist ein Single Point of Failure für Provisionierung und Kennwort-Sync.

Match-Attribute ungepflegt: Bei Mehrfachidentitäten fehlt ein belastbar befülltes Attribut für den Join – das Matching würde dem Zufall überlassen.

sourceAnchor-Strategie unklar: Historische Installationen auf objectGUID-Basis oder unterschiedliche Anker-Konfigurationen erschweren spätere Umzüge zwischen Forests.

OU-Struktur ohne Sync-Tauglichkeit: Produktivkonten, Dienstkonten und Testobjekte liegen bunt gemischt – sauberes OU-Filtering ist so kaum möglich.

Niedrig

Fehlende Betriebsdokumentation: Sync-Regeln, Filterentscheidungen und Notfallprozeduren existieren nur in Köpfen.

Ungetunte Sync-Intervalle und Alarmierung: Standardwerte passen meist, aber niemand würde einen stillstehenden Sync-Zyklus zeitnah bemerken (Stichwort Entra Connect Health).

 

Aktionsplan: Schritt für Schritt zum Multi-Domain-Sync

Das Wie in umsetzbaren Maßnahmen. Die Schritte sind auf ein Szenario mit einem bestehenden Connect-Server (Forest A) und einem neu aufzunehmenden Forest B zugeschnitten – für reine Multi-Domain-Fälle innerhalb eines Forests gilt sinngemäß dasselbe in einfacher.

Maßnahme 1: Bestandsaufnahme und Datenprüfung mit IdFix

Priorität: 1 – vor allem anderen

Schritte:

IdFix von der offiziellen Microsoft-Quelle herunterladen und auf einem Verwaltungsrechner je Forest starten.

Abfrage gegen die zu synchronisierenden OUs laufen lassen und den Bericht exportieren.

Befunde kategorisieren: Formatfehler (direkt korrigierbar), Duplikate innerhalb des Forests, Duplikate über Forest-Grenzen (per Export beider Forests und Abgleich, z. B. über PowerShell, identifizieren).

Korrekturen im AD durchführen bzw. an die Fachverantwortlichen delegieren; Lauf wiederholen, bis der Bericht sauber ist.

Erfolgskriterium: IdFix meldet in beiden Forests null kritische Befunde; die forestübergreifende Duplikatliste ist abgearbeitet oder mit einer Matching-Strategie versehen.

Rollback: Reine Datenkorrekturen im AD – kein Rollback nötig; im Zweifel einzelne Attributänderungen anhand des IdFix-Berichts rückgängig machen.

Maßnahme 2: UPN-Suffixe bereitstellen und Domains verifizieren

Priorität: 1

Schritte:

In „Active Directory-Domänen und -Vertrauensstellungen“ die benötigten routbaren UPN-Suffixe (z. B. contoso.com, fabrikam.com) auf Forest-Ebene hinzufügen.

Im Entra Admin Center unter „Einstellungen > Domänennamen“ jede Domain hinzufügen und per DNS-TXT-Eintrag verifizieren.

Benutzer-UPNs auf das neue Suffix umstellen – gestaffelt per PowerShell, beginnend mit einer Pilotgruppe.

Anwendungen prüfen, die sich am UPN festhalten (Legacy-Logins, Zertifikat-Mappings, SSO-Konfigurationen).

Erfolgskriterium: Alle zu synchronisierenden Benutzer tragen ein UPN-Suffix, das im Tenant als verifizierte Domain vorliegt.

Rollback: UPN-Umstellung ist skriptgesteuert reversibel (alte Werte vorher exportieren!); verifizierte Domains können im Tenant wieder entfernt werden, solange keine Objekte daran hängen.

Maßnahme 3: Matching-Strategie festlegen und Attribute befüllen (nur bei Mehrfachidentitäten)

Priorität: 2

Schritte:

Entscheiden, über welches Attribut die Konten beider Forests zusammengeführt werden (mail, ObjectSID/msExchMasterAccountSid oder ein eigenes Attribut).

Das gewählte Attribut in beiden Forests vollständig und konsistent befüllen – per Skript, mit anschließendem Abgleichbericht.

Stichprobe: Für 20 bis 30 zufällige Benutzer manuell prüfen, ob die Werte wirklich paarweise übereinstimmen.

Sonderfälle dokumentieren (Konten, die bewusst nicht gematcht werden sollen, etwa Admin-Zweitkonten).

Erfolgskriterium: Für jede Mehrfachidentität existiert genau ein eindeutiges, beidseitig identisch befülltes Match-Attribut; Stichprobe fehlerfrei.

Rollback: Attributbefüllung per Skript rückgängig machen; solange kein Sync des zweiten Forests läuft, hat die Änderung keine Cloud-Auswirkung.

Maßnahme 4: Forest B in Entra Connect Sync aufnehmen

Priorität: 2

Schritte:

Vorab: aktuelles Backup/Snapshot-Konzept für den Connect-Server prüfen; Wartungsfenster und Kommunikationsplan festlegen.

Firewall-Freischaltungen und DNS (bedingte Weiterleitung auf die DCs von Forest B) einrichten und mit nslookup sowie Portprüfung testen.

Auf dem Connect-Server den Assistenten starten: „Konfigurieren > Verzeichnisse hinzufügen“, Forest B mit einem eigenen AD-Konto (Prinzip der minimalen Rechte, vom Assistenten erstellbar) anbinden.

Unter „Domänen- und OU-Filterung“ ausschließlich die Pilot-OU von Forest B auswählen.

Bei Mehrfachidentitäten: die Frage nach eindeutigen Benutzern mit „Identitäten sind in mehreren Verzeichnissen vorhanden“ beantworten und das in Maßnahme 3 festgelegte Match-Verfahren wählen.

Konfiguration abschließen, Synchronisationszyklus laufen lassen (Start-ADSyncSyncCycle -PolicyType Initial).

Ergebnis prüfen: Pilotobjekte im Entra Admin Center kontrollieren – UPN, Mailadressen, Match-Ergebnis (ein Objekt statt zwei!), Anmeldetest mit einem Pilotbenutzer.

Nach erfolgreicher Pilotphase das OU-Filtering schrittweise auf die produktiven OUs erweitern.

Erfolgskriterium: Alle Zielobjekte aus Forest B erscheinen korrekt im Tenant, Mehrfachidentitäten sind zu je einem Objekt zusammengeführt, Pilotanmeldungen funktionieren, keine Exportfehler im Synchronization Service Manager.

Rollback: Forest-B-Konnektor über den Assistenten wieder entfernen bzw. OU-Filterung zurücknehmen; danach entfernt der Folgesync die betroffenen Cloud-Objekte (30 Tage im Papierkorb wiederherstellbar). Achtung auf den Löschschwellenwert – siehe Kapitel 7.

Maßnahme 5: Alternativroute: Forest B per Entra Cloud Sync anbinden

Priorität: 2 (alternativ zu Maßnahme 4)

Schritte:

Im Entra Admin Center unter „Entra Connect > Cloud Sync“ den Provisioning-Agenten herunterladen.

Agenten auf einem Server in Forest B installieren (nur ausgehendes HTTPS erforderlich) und mit einem Konto mit Verzeichnisrechten in Forest B registrieren; für Ausfallsicherheit direkt einen zweiten Agenten installieren.

Im Portal eine neue Konfiguration für die Domain von Forest B anlegen, Bereichsfilter auf die Pilot-OU setzen.

Attribut-Zuordnung prüfen (Standard reicht meist), Kennwort-Hash-Synchronisation aktivieren, Konfiguration im Bereitstellungsmodus „Ausführen“ starten.

Pilotobjekte und Anmeldung wie in Maßnahme 4 verifizieren, danach den Bereichsfilter erweitern.

Erfolgskriterium: Wie Maßnahme 4 – zusätzlich: der Agent meldet sich im Portal als fehlerfrei, beide Agenten sind aktiv.

Rollback: Konfiguration im Portal deaktivieren bzw. löschen; die bereitgestellten Objekte werden entfernt und sind 30 Tage wiederherstellbar.

Maßnahme 6: Staging-Server aufbauen und Failover proben

Priorität: 3

Schritte:

Zweiten Server bereitstellen (gleiche Version wie der aktive Connect-Server!), Installation mit der Option „Staging Mode“ durchführen bzw. die Einstellungen des Produktivservers per Export/Import übernehmen.

Beide Server einige Tage parallel beobachten; per CSExport/Vergleichsskript prüfen, dass der Staging-Server dieselben Ergebnisse berechnen würde.

Failover-Übung: aktiven Server in den Staging Mode versetzen, Staging-Server scharf schalten, einen Sync-Zyklus verifizieren – anschließend zurückschwenken.

Prozedur dokumentieren und als jährlichen Termin einplanen.

Erfolgskriterium: Der Staging-Server läuft konfigurationsgleich mit; die Failover-Übung wurde erfolgreich durchgeführt und dokumentiert.

Rollback: Staging-Server kann jederzeit gefahrlos abgeschaltet werden – er exportiert nichts.

 

Risiken und Nebenwirkungen

Risiko	Auswirkung	Gegenmaßnahme
UPN-Umstellung irritiert Benutzer und Alt-Anwendungen	Anmeldeprobleme, Supporttickets, im schlimmsten Fall Produktionsstörung bei UPN-abhängigen Systemen	Pilotgruppe, Anwendungsinventur vorab, klare Benutzerkommunikation, gestaffelter Rollout
Fehlgeschlagenes Matching erzeugt Duplikate im Tenant	Doppelte Einträge in der Adressliste, Lizenz- und Berechtigungswirrwarr, aufwendige Bereinigung	Match-Attribute vorab verifizieren (Maßnahme 3), Pilot-OU klein halten, Ergebnis vor Ausweitung prüfen
Massenlöschung durch Filter- oder Konfigurationsfehler	Cloud-Konten verschwinden, Zugriff auf Postfächer und Daten stockt	Löschschwellenwert (Deletion Threshold) aktiviert lassen, Änderungen an Filtern grundsätzlich erst im Pilotumfang, Papierkorb-Wiederherstellung kennen
Initial-Sync großer Forests dauert und erzeugt Last	Lange Wartezeiten, temporäre Inkonsistenzen während der Erstsynchronisation	Wartungsfenster einplanen, OU-weise vorgehen, Fortschritt im Synchronization Service Manager überwachen
Exchange-Hybrid-Seiteneffekte bei Ressourcen-Forest-Szenarien	Falsche oder unvollständige Mail-Attribute, Probleme bei Frei/Gebucht und Weiterleitung	Exchange-Konfiguration in die Planung einbeziehen, Hybrid-Spezifika separat testen
Sync-Server-Ausfall ohne Staging-Instanz	Keine Provisionierung, keine Kennwortänderungs-Übernahme, wachsender Rückstau	Maßnahme 6 umsetzen, Monitoring über Entra Connect Health

 

Offene Punkte

Diese Punkte lassen sich erst im konkreten Projekt klären – die Tabelle dient als Arbeitsvorlage für den Kickoff:

 

Nr.	Offener Punkt	Verantwortlich	Termin
1	Vollständige Inventur aller Forests, Domains und bestehender Sync-Instanzen (inkl. Alt-Tenants)	IT-Infrastruktur	offen
2	Entscheidung Connect Sync vs. Cloud Sync je Forest (Netzwerklage, Geräte-Sync-Bedarf)	Architektur / Consulting	offen
3	Liste UPN-abhängiger Anwendungen und Systeme	Applikationsverantwortliche	offen
4	Klärung Mehrfachidentitäten: betroffene Benutzerkreise und Match-Attribut	IT-Infrastruktur / HR	offen
5	Kommunikationsplan für Benutzer (UPN-Änderung, neue Anmeldung)	IT-Service / Kommunikation	offen
6	Lizenzsituation für neu synchronisierte Benutzer im Tenant	Einkauf / Lizenzmanagement	offen
7	Betriebsübergabe: Monitoring, Dokumentation, Failover-Termin	IT-Betrieb	offen

 

Anhang

Checkliste für den Schnellstart

Bestandsaufnahme: Forests, Domains, bestehende Sync-Server, Alt-Tenants

IdFix je Forest – Bericht sauber?

Routbare UPN-Suffixe im AD angelegt und im Tenant verifiziert?

Forestübergreifende Duplikate identifiziert, Matching-Strategie entschieden?

Netzwerk/DNS für Connect Sync geklärt – oder bewusst Cloud Sync gewählt?

Pilot-OU definiert und synchronisiert, Ergebnis verifiziert?

Rollout auf produktive OUs, Löschschwellenwert aktiv?

Staging-Server bzw. zweiter Agent im Betrieb, Failover geprobt?

Dokumentation und Monitoring (Entra Connect Health) eingerichtet?

Häufige Fragen (FAQ)

Brauche ich einen Forest-Trust zwischen den Forests?

Nein. Weder Connect Sync noch Cloud Sync setzen einen Trust voraus. Connect Sync braucht Netzwerk- und DNS-Sicht auf die DCs aller Forests, Cloud Sync nicht einmal das – dort genügt ausgehendes HTTPS je Agent.

Kann ich pro Forest einen eigenen Connect-Server betreiben?

Nicht in denselben Tenant. Pro Tenant exportiert genau ein aktiver Connect-Server; er bindet alle Forests über je einen Konnektor an. Der einzige zulässige Zweitserver ist eine Staging-Instanz.

Was passiert mit Benutzern, deren UPN-Suffix nicht verifiziert ist?

Sie werden trotzdem synchronisiert, erhalten aber ein UPN auf Basis der onmicrosoft.com-Standarddomain. Anmelden können sie sich damit zwar, aber spätestens beim Mailversand und in der Außendarstellung wird es unschön – daher: Suffixe vorher geraderücken.

Kann ich Connect Sync und Cloud Sync mischen?

Ja, das ist ein unterstütztes und gängiges Muster – solange jede Domain bzw. jeder OU-Bereich exklusiv von genau einem der beiden Werkzeuge bedient wird. Doppelte Zuständigkeit für dieselben Objekte ist tabu.

Wie lange dauert so ein Projekt realistisch?

Die Technik ist in Tagen erledigt. Die Kalenderzeit bestimmen Datenbereinigung, UPN-Umstellung und Abstimmung – je nach Umgebungsgröße und Datenqualität reden wir über Wochen bis wenige Monate. Der Pilotbetrieb mit einer kleinen OU liefert dabei früh belastbare Erkenntnisse.

Und was ist mit den Geräten (Hybrid Join) aus dem zweiten Forest?

Gerätesynchronisation bleibt eine Domäne von Connect Sync – Cloud Sync klammert Geräteobjekte aus. In Multi-Forest-Umgebungen ist zusätzlich die Registrierungskonfiguration je Forest zu betrachten (Service Connection Point bzw. clientseitige Vorgaben). Das ist gut lösbar, gehört aber als eigener Punkt in die Planung.

Quellen und weiterführende Hinweise

Microsoft Learn: Topologien für Microsoft Entra Connect (unterstützte und nicht unterstützte Szenarien)

Microsoft Learn: Was ist Microsoft Entra Cloud Sync? (inkl. Funktionsvergleich mit Connect Sync)

Microsoft Learn: Entra Connect – Staging-Server und Notfallwiederherstellung

Microsoft IdFix – Werkzeug zur Verzeichnisbereinigung vor der Synchronisation

Alle Microsoft-Dokumente sind über die Suche auf learn.microsoft.com auffindbar; auf Link-Nennungen wurde bewusst verzichtet, da sich URLs erfahrungsgemäß schneller ändern als Architekturen.