AD Sync umziehen andere lokale Domäne

Servus;

Ich muss einen Standort umziehen, dabei wird eine komplett neue Domäne installiert.
Die läuft auch soweit. Die User wurden alle neu angelegt.
Jetzt fehlt nur mehr der Umzug der Mailadressen, die liegen im Office365 und werden mit AD Sync synchronisiert.

Alte Domäne: firma.local
Neue Domäne: ad.firma.at
E-Mail Domäne: @firma.at

Der neue AD Sync ist auch bereits eingerichtet und wartet im Staging Modous auf seinen Einsatz.
Als Quellanker ist "mS-DS-ConsistencyGuid" ausgewählt.
Ist bei allen meinen Standorten so.

Was ich allerdings nicht genau verstehe, wenn ich in den Attribut-Editor schaue, ist dort kein Wert eingetragen.
Was nimmst also AD Sync als Wert?

Hab mit einem Testuser einfach versucht "drüber" zu syncen. Hat erwartungsgemäß nicht funktioniert.

Wie wäre das das richtige Vorgehen?
Eine kurze Idee von mir war, den Quellanker in der alten Domäne zu ändern zb auf "mail".
Nur dazu muss ich glaub ich den kompletten AD Sync neu installieren. Und hab da etwas bedenken beim neu syncen.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3338593345

Url: https://administrator.de/forum/ad-sync-umziehen-andere-lokale-domaene-3338593345.html

Ausgedruckt am: 22.12.2024 um 02:12 Uhr

8 Kommentare

Neuester Kommentar

Moin,

Ich muss einen Standort umziehen, dabei wird eine komplett neue Domäne installiert.

Wie hast du die Benutzer umgezogen, mit Hilfe von ADMT oder einfach neu angelegt?

Was nimmst also AD Sync als Wert?

Ist es nicht so, dass wenn mS-DS-ConsistencyGuid leer ist, wird ObjektGUID verwendet?

Gruß,
Dani

Zitat von @Dani:

Moin,

Ich muss einen Standort umziehen, dabei wird eine komplett neue Domäne installiert.

Wie hast du die Benutzer umgezogen, mit Hilfe von ADMT oder einfach neu angelegt?

Wurden komplett neu angelegt. Hat der Kollege mit einem Tool gemacht.

Was nimmst also AD Sync als Wert?

Ist es nicht so, dass wenn mS-DS-ConsistencyGuid leer ist, wird ObjektGUID verwendet?

Das ist eben die Frage.

Am liebsten wäre mir wenn er das mail Attribut nehmen würde.

Moin,

Hab mit einem Testuser einfach versucht "drüber" zu syncen. Hat erwartungsgemäß nicht funktioniert.

Was steht im Log/Protokoll von deinem Versuch drin?

Gruß,
Dani

Also, er schreibt AttributeValueMustBeUnique.

Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:testschueler@firma.at;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.

Tracking Id: c866efc8-1e2f-40c2-ae59-0d3ed8fa16b3
ExtraErrorDetails:
[{"Key":"ObjectId","Value":["8709b71d-97b1-415b-9edc-1ea7e9c4d3ea"]},{"Key":"ObjectIdInConflict","Value":["9cd23941-0366-4ef2-9c87-450c4652152a"]},{"Key":"AttributeConflictName","Value":["ProxyAddresses"]},{"Key":"AttributeConflictValues","Value":["SMTP:testschueler@firma.at"]}]

Moin,
ich hab mich ein bisschen dazu eingelesen.

Du hast zwei eingeständige Forests, welche nicht von Forest A nach B migriert worden ist sondern alle Objekte neu angelegt wurden. Auf Basis dieser Annahme ist dein Szenario nicht unterstützt: Topologies for Azure AD Connect:

This topology differs from the one below in that multiple sync servers connected to a single Azure AD tenant is not supported.

Im Q&A von Microsoft bin ich auf den Beitrag Migrate AD User and AADConnect to new Forest (Same O365 tenant). Liest sich in der Theorie vielversprechend. Ausprobieren kann ich es jedoch nicht.

Gruß,
Dani

Oha, vielen Dank.
Dass es anscheinend nicht unterstützt wird, hab ich schon gemerkt.

Den Beitrag werde ich mal durchgehen.
Wenn ich was erreicht habe, melde ich mich hier wieder.

Danke

Es wurde jetzt eine Firma beauftragt, der hat ungefähr 5 Stunden herumgewerkt.
Gab einige Probleme.
Wie und was genau der gemacht hat, weiß ich leider nicht.