Veeam Restore Issue auf RODCs - Inkonsistente ntds.dit

[notimportant 1]

Hallo zusammen, ein gutes neues 2025,

 

wie immer habe ich ein interessantes Phänomen auf unseren Read Only DCs. Bei einer größeren Restoresession (knapp 5-stellig) aufgrund einer unbeabsichtigten Löschaktion mit VEEAM (Application Aware) von Userobjekten (kein DC-Restore, nur Userobjectrestore) haben wir das Phänomen, dass die Gruppenmitgliedschaften auf den ReadOnly DCs inkonsistent repliziert wurden.

 

Die Writable DCs haben sowohl den Forward (member) als auch Backlink (memberOf) der Gruppenmitgliedschaften sauber in der Datenbank. Die RODCs haben jedoch ca. im 10%-Bereich die Wiederherstellung nicht ordentlich repliziert.

 

• Editieren wir jetzt die Group-Memberships, replizieren sich die Änderungen sauber durch. Die Lücken aus den Restoresessions bleiben bestehen.
• Die Metadaten der RODCs zeigen, dass die Nutzer aus den Gruppen entfernt wurden.
• Die Logs sind frei von jeglichen Replikationsproblemen und die Replikation der gesamten Umgebung ist zum Status quo einwandfrei.
• Die USNs zeigen, dass VEEAM korrekt restoret. Erst der Nutzer, dann die Gruppe.
• Der komplette Restore wurde auf einem einzelnen Writable DC durchgeführt.
• Die fehlenden Mitgliedschaften sind nicht gleichverteilt über die RODC-Landschaft. Auf jedem RODC fehlen andere User in anderen Gruppen.

 

Tickets sind zwar offen, aber hat jemand vielleicht eine Idee, was speziell dieses Szenario verursachen könnte?

[NilsK 2.971]

Moin, 

 

Was passiert, wenn ihr einen neuen RODC dazu nehmt?

 

Gruß, Nils

[notimportant 1]

Guten Morgen,

 

gute Idee, habe ich über Nacht mal installiert.

Interessant. Wir deployen RODCs über eine IFM-Installation. Betroffene Nutzer haben auf einem neuen IFM-RODC mit ntds-Datum von vor der Löschaktion jetzt tlw. zu viele Gruppen.

 

Müsste man in den Metadaten einer Gruppe eigentlich nicht sehen, dass Nutzer x in dieser nicht mehr vorhanden ist, wenn VEEAM korrekt die Mitgliedschaften wiederherstellen wollte? Dieser Eintrag verschwindet ja bei Löschen eines Objekts, solange das Objekt existiert, benötige ich diesen Eintrag doch, um die Information zu replizieren?

 

Grüße

[NilsK 2.971]

Moin, 

 

Ich fürchte, dazu kann nur @daabm kompetent was sagen. Eure Umgebung scheint speziell zu sein, in der Spielgröße kennt sich sonst kaum jemand aus. 

 

Edit: ich ergänze noch @cj_berlin.

 

Ich könnte da höchstens mutmaßen, aber das wird jetzt nicht helfen. 

 

Gruß, Nils

bearbeitet 4. Januar von NilsK

[notimportant 1]

Guten Abend,

 

ja die Umgebung ist nicht gerade klein und im hohen Maße verteilt.

 

Ein RODC ohne IFM ist fertig, d.h. ntds.dit zu 100% frisch von den Writable DCs. Dieser zeigt dann das erwartete Bild. Datenbank identisch mit den aktuellen Writables.

 

Entweder hat VEEAM Fehler gemacht in der Masse, oder es gab Probleme in unserer Umgebung bei der Replikation. Das diverse Bild über die Umgebung erschließt sich mir aber trotzdem noch nicht. Der Restore ging von einer einzelnen Quelle aus. Das kann eigtl. ja nicht passieren.

 

Auf jeden Fall vielen Dank für die Hinweise und Unterstützung am Wochenende. Der Vergleich hat mich jedenfalls gedanklich/theoretisch nochmal ein gutes Stück weiter gebracht.

 

Schönen Abend

bearbeitet 4. Januar von notimportant

[vkf 0]

Warum spielt man gleich mehrere RODCs zurück? Ist das eine Schulungsumgebung oder wie?

[notimportant 1]

Guten Morgen,

 

nein, leider gar keine Schulungsumgebung

Es werden keine RODCs zurückgespielt oder wiederhergestellt. Das sind ganz einfach zusätzliche Read-Only-DCs in einer separaten Site.

Die tun ja nicht weh, können an der Datenbank nichts verändern, aber man kann die Inhalte und Metadaten vergleichen.

 

Was in diesem Fall wie oben beschrieben interessant ist, da wir unter anderem auch IFM-Installationen vornehmen.

 

Grüße

[notimportant 1]

Ok, zumindest die IFM-RODC-Diskrepanz ist genau so zu erwarten. (Wichtiges Detail ist vielleicht noch, dass der AD Papierkorb nicht aktiv ist und VEEAM die Tombstones wiederherstellt.)

 

Wird ein AD-User gelöscht, verschwindet auch sein ABSENT-Entry der Gruppe, der normalerweise 180 Tage Tombstonelifetime vorgehalten wird.

 

VEEAM restoret nur die postitiven Gruppenmitgliedschaften neu, da es sich einfach die Mitgliedschaften merkt. Mit einer "normalen" neuen Transaktion, neue USN, neue Versionnumber 1 in den Metadaten. Exakt wie ein normaler administrativer Vorgang "Gruppenmitglied hinzufügen". Somit kann die Löschung nicht mehr repliziert werden, da die ABSENT-Daten unwiderbringlich verloren sind.

 

Erklärt natürlich noch nicht das Fehlen der restoreten Group Member auf diversen RODCs. Die Ursprungs-USNs sind auf den RODCs, wo sie eingetragen sind, korrekt, nachvollziehbar und mit den Writables identisch. Ist mir noch ein Rätsel.

[notimportant 1]

Mittlerweile habe ich die Vermutung, dass der Restore mittels VEEAM nicht die Ursache der Probleme ist, sondern der Impact durch die vorherige große Löschaktion (Diese war geskriptet).

 

Die 5-stellige Anzahl an Nutzern waren natürlich in diversen Gruppen Mitglied. Während der Löschaktion loggten die Writable-DCs diverse 1955 und einige 1083. Auf den ersten Blick zwar verschwindend gering im Vergleich zur 5-stelligen Anzahl an Löschungen, aber eben über die Umgebung hinweg. War zuerst nicht aufgefallen, da wir uns auf den Restorezeitraum konzentriert hatten.

 

Hat jemand Erfahrung mit einem solch großen Delete-Impact? Wenn im großen Stil Links und Link-Tables angefasst werden sieht das MS auch kritisch bezüglich der Performance replication-failures-delete-active-directory-objects Sind zwar ja nicht direkt die Gruppenobjekte, diese müssen aber ja in großem Stil angefasst werden, da die Forward-Links gelöscht werden müssen.

[daabm 1.375]

Ich kann da leider gar nichts beitragen - wir haben RODC aus unserem Wortschatz und Portfolio gestrichen...