Defenders 4 Geschrieben 21. Oktober 2020 Melden Teilen Geschrieben 21. Oktober 2020 Hallo, wir haben folgendes Problem, vor ca. 6 Jahren haben wir fünf Windows 2012 R2 Server eingerichtet und um Zeit zu sparen wurden das System geklont. Die Server hatten alle keine Verbindung und somit gab es auch keine Probleme... Nun haben wir auf allen 5 Servern im AD ca. 1500 User, die wir mit Azure AD Connect in Microsoft365 importieren und synchronisieren wollen. Leider kommt es bei einigen Usern zu einem SyncError: Error Type: AttributeValueMustBeUnique Unable to update this object because the OnPremiseSecurityIdentifier value System.Byte[] associated with this object may already be associated with another object in your local directory services. Durch das "Klonen" der Server gibt es nun leider User (ca. 150 Stück), die die gleiche SID haben und somit können diese nicht synchronisiert/importiert werden. Wie kann ich die Synchronisation über ein anderes Attribut also quasi nicht über die SID (OnPremiseSecurityIdentifier) im Azure AD Connect einstellen? Ich habe schon das Azure AD Connect deinstalliert und bei der Neuinstallation anstatt der ObjectGUID ein anderes Attribut gewählt, leider hat das nichts gebracht?! Kann da Jemand helfen? Danke, VG Thomas Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 22. Oktober 2020 Melden Teilen Geschrieben 22. Oktober 2020 (bearbeitet) Hey Defenders, soweit ich weiß wird die SID immer benötigt, genau aus deinem genannten Grund, da die SID nun einmal die Benutzer im AD verankert. Du musst wohl per Powershell Hand anlegen und die Attribute ausgleichen/angleichen. ## Kommt der Fehler bei allen Postfächern? Grüße Phil bearbeitet 22. Oktober 2020 von Gerber Zitieren Link zu diesem Kommentar
Defenders 4 Geschrieben 22. Oktober 2020 Autor Melden Teilen Geschrieben 22. Oktober 2020 Am 22.10.2020 um 14:32 schrieb Gerber: ### Kommt der Fehler bei allen Postfächern? Der Fehler kommt nur bei den Postfächern wo die SID nachweislich doppelt vergeben ist. Welches Attribut müssen wir dann nachbessern, wir haben schon diverse Versuche gestartet... Zitieren Link zu diesem Kommentar
NorbertFe 2.066 Geschrieben 22. Oktober 2020 Melden Teilen Geschrieben 22. Oktober 2020 vor 16 Stunden schrieb Defenders: um Zeit zu sparen wurden das System geklont. Total OT: Schönes BEispiel für "so macht man das nicht", weil es einem _immer_ irgendwann auf den Fuß fällt. 1 Zitieren Link zu diesem Kommentar
Defenders 4 Geschrieben 22. Oktober 2020 Autor Melden Teilen Geschrieben 22. Oktober 2020 vor 1 Minute schrieb NorbertFe: Total OT: Schönes BEispiel für "so macht man das nicht", weil es einem _immer_ irgendwann auf den Fuß fällt. Es hat immerhin 5 Jahre problemlos funktioniert und uns damals den Ar*** gerettet Zitieren Link zu diesem Kommentar
NorbertFe 2.066 Geschrieben 22. Oktober 2020 Melden Teilen Geschrieben 22. Oktober 2020 Gerade eben schrieb Defenders: Es hat immerhin 5 Jahre problemlos funktioniert und uns damals den Ar*** gerettet Nein. Einfach nein. Egal ob du es dir schön reden willst. ;) 1 Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 22. Oktober 2020 Melden Teilen Geschrieben 22. Oktober 2020 (bearbeitet) vor 4 Minuten schrieb NorbertFe: Total OT: Schönes BEispiel für "so macht man das nicht", weil es einem _immer_ irgendwann auf den Fuß fällt. Da muss ich NorbertFe leider Recht geben. ... vor 5 Minuten schrieb Defenders: Der Fehler kommt nur bei den Postfächern wo die SID nachweislich doppelt vergeben ist. Welches Attribut müssen wir dann nachbessern, wir haben schon diverse Versuche gestartet... Na dann musst du dir mal die Logs vom AzureAD Sync genau anschauen und nachsehen was er anmeckert. Es gibt einige Fehler welche unter diese Fehlermeldung fallen. Im NOrmalfall solltest du mit einem Hard Match klarkommen: https://docs.microsoft.com/de-de/archive/blogs/praveenkumar/how-to-do-hard-match-in-dirsync und hier: https://docs.microsoft.com/de-de/archive/blogs/praveenkumar/how-to-do-hard-match-part-2 bearbeitet 22. Oktober 2020 von Gerber 2 Zitieren Link zu diesem Kommentar
Defenders 4 Geschrieben 22. Oktober 2020 Autor Melden Teilen Geschrieben 22. Oktober 2020 Das sieht nach einer Lösung aus das werde ich probieren! Danke!!! 1 Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 22. Oktober 2020 Melden Teilen Geschrieben 22. Oktober 2020 Bitte gib kurz Rückmeldung ob es geholfen hat. Danke. Grüße Phil Zitieren Link zu diesem Kommentar
Defenders 4 Geschrieben 22. Oktober 2020 Autor Melden Teilen Geschrieben 22. Oktober 2020 Mach ich... Zitieren Link zu diesem Kommentar
Defenders 4 Geschrieben 23. Oktober 2020 Autor Melden Teilen Geschrieben 23. Oktober 2020 Hallo, ich kann nun die "Immutable ID" (source anchor) des CloudUser temporär anpassen und dann wird der User angelegt, aber spätestens bei der nächsten Synchronisation bekommen ich wieder ein SyncError, da er ja wieder die alten Daten verwendet. Ich müsste auf beiden Seiten eine Anpassung machen, was ja nicht geht. Oder habe ich da einen Denkfehler? VG Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 23. Oktober 2020 Melden Teilen Geschrieben 23. Oktober 2020 (bearbeitet) Hi, naja ich muss leider sagen, dass du mit den Informationen ziemlich sparsam umgehst. Vllt mal ein wenig mehr Infos: - Handelt es sich um komplett neue Benutzer - Benutzer bereits in M365 angelegt - Was hast du jetzt gemacht? Etc etc Edit: Was sagt denn der Azure Active Directory Connect Health im Azure AD? bearbeitet 23. Oktober 2020 von Gerber Zitieren Link zu diesem Kommentar
NorbertFe 2.066 Geschrieben 23. Oktober 2020 Melden Teilen Geschrieben 23. Oktober 2020 Ich würde an deiner Stelle: 1. Entweder den MS Support bemühen 2. Die 150 Nutzer halt "neu anlegen" lokal mit allen Schmerzen die das bereitet 3. weiterprobieren und auf die nächsten zu erwartenden Probleme bei sowas warten. Die 4. Variante schreib ich lieber nicht hin, sonst steinigst du mich gleich. Bye Norbert Zitieren Link zu diesem Kommentar
Gerber 15 Geschrieben 23. Oktober 2020 Melden Teilen Geschrieben 23. Oktober 2020 Ein kurzes Edit: Waren die Benutzer schon einmal mit dem Azure AD Synchronisiert? Wurden bei den lokalen Benutzern welche einen Fehler verursachen lokal etwas geändert? Eventuell kannst du ja wie oben beschrieben nochmals die genaue Fehlermeldung posten und beschreiben was du in welcher Reihenfolge gemacht hast. Aus meiner Erfahrung kommt der Fehler "AttributeValueMustBeUnique" am häufigsten, wenn zwei Objekte mit verschiedenen Source Anchors irgendwo den gleichen Wert im Attribut haben. z.B. proxyAdress oder UserPrincipalName. Ebenso können gleiche Aliase zu Problemen führen. Ich würde ebenfalls einmal das IdFix Tool in deiner Umgebung laufen lassen um solche Fehler zu finden. Diese hatte ich vergesse dir mit an die Hand zu geben. Grüße Phil Zitieren Link zu diesem Kommentar
Defenders 4 Geschrieben 24. Oktober 2020 Autor Melden Teilen Geschrieben 24. Oktober 2020 Es läuft aktuell auf jedem der 5 Server eine Synchronisation (Azure AD Connect), die in ein Azure AD geschrieben wird. Im Azure AD sind ca. 4000 User gelistet, die fehlerfrei laufen. Täglich wird alle 6 Stunden synchronisert... Das Azure AD Connect ist auf allen 5 Servern identisch konfiguriert und der Source Anchors ist die "ObjectGUID". Um keinen weiteren Fehler zu machen habe ich jetzt ein Testsystem aufgesetzt (ein geklonter Server, quasi Server Nr. 6) der identisch zu den anderen 5 Servern ist. Hier habe ich 20 TestUser angelegt und diese nun auch über AzureAD Connect synchronisiert. Von den 20 TestUsern konnten 16 problemlos angelegt werden und 4 haben die Fehlermeldung "AttributeValueMustBeUnique". Was ich schon vermutet hatte, bei der Überprüfung der User stellte sich heraus, das sie die gleiche SID mit einem der 4000 User im Azure AD aufweisen. So der aktuelle Stand... Nun hatte ich ja dank deiner Idee die "Immutable ID" (source anchor) des CloudUser temporär angepasst und die 4 TestUser wurden auch importiert. Leider klappt das nur einmal, sobald dann nach 6 Stunden wieder synchronisiert wird sind die Fehler wieder da. VG Thomas Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.