notimportant

Trotzdem Danke für die Rückmeldung. MS Support ist noch überfordert, mal sehen, ob da noch was kommt. Ich kann ja kurz nachberichten, falls es interessant wird. Hauptsache nichts kumulatives, die Inkonsistenzen können wir ja auflösen, da wir genau wissen, was nicht passt.

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.

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.

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

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

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

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?

Sodala. Aus gut unterrichteter Quelle kann ich berichten, dass hier das Attribut msDS-RevealedDSAs zu sehen sein müsste. Dieses war auch bis 2008R2 in der GUI zu sehen, aber ist auf dem Wege zu 2012 verschütt gegangen und seitdem nicht wieder in der GUI aufgetaucht ; )

Hallo zusammen, bisher habe ich unsere PRP ausschließlich über die DC-Objekte und Skripte gemanaget und mir ist nie bewusst aufgefallen, dass die User und Computerobjekte ja auch einen Reiter "Password Replication" besitzen. Weiß jemand welches Attribut hier angezeigt werden (müsste)? Ich kann mir nämlich einen beliebigen User herauspicken dessen PW-Hash definitiv auf einem RODC zwischengespeichert ist, aber das Feld ist leer. Von der Beschreibung her müsste es eigentlich msDS-RevealedDSAs (Backward link for ms-DS-Revealed-Users. Identifies which RODC holds that user's secret.) sein. Das Attribut ist für den User auch befüllt. Hier: TechNet: active-directory-attributes-in-the-aduc-gui-tool und hier: selfadsi: user-attributes-w2k8 wird allerdings behauptet es wäre das Attribut msDS-AuthenticatedAtDC (The attribute contains a list of computer objects, corresponding to the RODCs at which the user or computer has authenticated). Auch das ist befüllt für den obgen User. Wieso ist das Feld leer? Hier hatte mal jemand dasselbe Problem beschrieben, aber auch ohne Lösungsidee. Ist das vielleicht ein Anzeigefehler, oder wurde das Feld nur in 2008 genutzt?

Hallo, Genau. Das Bild kann ich auch genauso sehen (Die KRB5-Frames sind ausgeblendet): Ich verstehe nur nicht, weshalb ein und derselbe Rechner auch das hier macht. Ich würde erwarten, dass ich immer obiges Bild erhalte. Übersehe ich etwas? Im Testlab erhalte ich immer untenstehendes Bild (aber auch hier sind only-secure-Updates aktiviert). Oder eben die Dynamic Update - Pakete gar nicht auftauchen. Beim Aushandeln mit dem DHCP sieht dann noch immer alles gut aus: Aber es tauchen keine Dynamic Update Pakete auf. Ist definitiv deaktiviert. Grüße

Per default nicht, das haben wir aber bei den traces aktiviert und mitlaufen lassen. Leider so gar nichts ungewöhnliches.

Hallo zusammen, ich habe mal wieder ein sehr spezifisches Problem. Und zwar haben wir in unserer Umgebung Probleme mit den automatischen Updates der DNS-Records. Nur in Kürze die notwendigen Eckpunkte: AD integriertes DNS Clients registrieren ihre A-Records selbst, die Reverseeinträge übernimmt der DHCP (also keine Option 81, sondern Standard) Nichtaktualisierungsintervall 7 Tage + Aktualisierungsintervall 7 Tage ... danach Scavenging der Records Hat jahrelang funktioniert, es wurde keine wissentliche Änderung gerade an solchen Kernfunktionalitäten vorgenommen, jedoch seit dem Herbst gibt es Probleme mit den automatischen Aktualisierungen. D.h. die DNS-Records vieler Clients altern aus dem DNS raus und werden vom Scavengingprozess gelöscht, obwohl diese Rechner: per DHCP versorgt werden täglich neugestartet werden Meines Wissens muss ein Client ja bei Neustart, wenn seine DHCP-Lease erneuert wird ein Dynmaisches DNS Update versuchen. Und gerade das scheinen unsere Clients zum großen Teil nicht mehr zuverlässig zu senden. Wir haben keine GPO bzgl. RegistrationRefreshIntervall o.ä. gesetzt. Die "üblichen" Verdächtigen "primäres Domain Suffix" usw. sollten alle als "passt" angehakt sein. Ich kann folgende Szenarien beobachten, erstellt unter der Zuhilfename einer großen Anzahl von Traces auf verschiedenen Clients: Szenario 1: "Alles OK" Der Client sendet einige Sekunden nach Konfiguration der NIC die folgende Paketreihenfolge: SOA-Anfrage, SOA-Antwort, DNS-Update-Anfrage, DNS-Update-Refused, TKEY-Negotiation, DNS-Update-Anfrage, DNS-Update-Success. Ganz brav, wie es MS hier etwa beschreibt: Secure Dynamic Update Szenario 2: "Keine TKEY Negotiation" Der Client sendet folgende Paketreihenfolge: SOA-Anfrage, SOA-Antwort, DNS-Update-Anfrage, DNS-Update-Success. Es erfolgt keine TKEY-Negotiation. Das sollte doch eigentlich nur passieren, wenn keine Secure Updates verwendet werden. Diese sind aber auf allen DNS-Servern als zwingend konfiguriert. Szenario 3: "Gar nix passiert" Der Client sendet keine DNS-Update-Pakete. Gar nicht. Das sollte, wenn ich es richtig verstehe, definitiv nicht vorkommen. Erklären kann ich es mir nicht. Solche Clients kann ich auch durch Änderung der Richtlinien (explizit DynUpdates aktivieren, RegistrationRefreshIntervall auf fixe 30 Min setzen) nicht dazu bewegen bei Neustarts zuverlässig die Updatepakete zu senden. Anmerkungen zu 1,2,3: Die Szenarien sind nicht fix auf einen Client beschränkt. Es gibt zwar Clients die relativ zuverlässig in Szenario 3 sich bewegen, aber eine große Anzahl der untersuchten Rechner sendet eben mal ein DNS-Update-Paket und eben mal nicht. Das ist über Modellvarianten brav verteilt. Es sind ca. 10-20% der Clients (ca. 3 -7.000 von 30.000) immer betroffen, wir sind ab Sommer/Herbst großflächig auf 20H2 migriert. Die Auffälligkeiten sind zusammengefallen, aber eine logische Verbindung konnte ich noch nicht herstellen. Szenario 2b: "Test Lab" In einem Testlab (DC auf Server 2022, alles ziemlich default) sendet ein Client zuverlässig, d.h. immer zu 100%, kurz nach seinem neuen DHCP-Lease seine DHCP-Update-Pakete. Diese allerdings auch immer ohne TKEY-Negotiation. Frage 1: Hat jemand irgendeine Idee, wo wir noch ansetzen könnten? Ich denke das ist eine Kernfunktionalität des DHCP-Client-Services. Keine Idee, wo man das kaputtkonfigurieren sollte. Frage 2: Kann jemand das seltsame TKEY-Negotiation-Verhalten erklären? Müsste das nicht immer auftreten? Oder ist hier die MS-Doku veraltet? Viele Grüße notimportant

Genauso wollen wir das auch im Fall des Falles handhaben. Das tägliche Leeren und Neubefüllen der Gruppen hat(te) historische Gründe in der Organisationsstruktur. Das stellen wir gerade ab, die Clients und Nutzer bleiben nun dauerhaft (also ohne temporären Ausfall, dauherhaft war das vorher auch) in der PRP-Allow drinnen. Hier techcommunity.microsoft.com wird in einem Nebensatz aber immerhin genau mein Problem erwähnt: Das beschreibt zumindest genau das Bild, das ich sehe. Warum ich das durch das Löschen PRP-Mitgliedschaft provozieren kann erschließt sich mir aber noch nicht. PrtQry-Log gegen den RWDC sieht m.E. sauber aus. Vielleicht sollte ich mich auf Firewall/Netzwerk/AV konzentrieren. Ist wohl aber wirklich zu speziell für ein Forum. Danke Grüße PortQryLog.txt

Stimmt. Die Tickets wären aber immer mit dem Domain-krbtgt-Account signiert, wenn ich es richtig verstehe. Der RODC guckt sich den Request immer an und prüft, ob er das Passwort in seiner lokalen Datenbank hat. (Und frägt auch jedes mal nach, ob er das PW nicht repliziert bekommt? Und ein beschreibbarer DC prüft die PRP jedes mal?) Und ich frage mich, ob genau an diesem Punkt vielleicht etwas schiefgeht, wenn der Rechner kurzfristig aus der PRP fliegt. Wir haben strikt einen RODC pro Site. Dadurch, dass das Problem über einen längeren Zeitraum sehr sporadisch auftritt, verteilt über alle Standorte, schließe ich die üblichen Verdächtigen wie Zeitabweichung usw. aus. Der Dreh mit den PRP-Gruppen war eher Zufall, lässt sich aber wunderbar reproduzieren : )

Verzichten in dem Sinne von "Tausch durch beschreibbare DCs" würde ich jetzt persönlich verneinen, da ich es durchaus als legitimen Grund sehe bei unserer Zweigstellendichte im dreistelligen Bereich Read Only Replikas zu nutzen. Ob man jetzt einen DC unbedingt überall haben möchte aus Gründen der Ausfallsicherheit... Darüber kann - und wird - man sicherlich diskutieren. Die Verwirrung um das aktuelle Phänomen behebt das allerdings nicht. Wie gesagt, das ist nicht mal im Ansatz ein Deal-Breaker für das aktuelle Design. Eher mal wieder die Neugierde eine fachliche Kuriosität aufzuklären : )