11
AD mit Schuss?
Guten Morgen zusammen,
ich vermute einen Fehler in der ntds.dit Datenbank weil ich im gpoinventory.exe rsop Ergebnisse bekomme in denen Uralte gpos bei den Clients verarbeitet werden welche es schon lange nicht mehr gibt (Stehen da vielleicht alle jemals verarbeiteten drin?).
Diese Annahme bestätigt sich auch in der Praxis da Einstellungen angewendet werden, deren gpo gar nicht mehr existiert.
Außerdem habe ich hidden gpos gefunden welche auf keinem weg zu löschen waren nur ein OU Struktur Umbau mit Objekt verschieben hat dann geholfen. (Resultate per adsisearcher)
Hier ein paar Fakten:
- gpo Anzahl ist im sysvol/adsiedit/gpo.mmc konsistent und repl funktioniert fehlerfrei.
- ntdsutil (integrity & semantic database analysis) fehlerfrei
- 7016 Ereignisse auf den clients von cse's die unauffindbar sind.
- bei allen client gpo tests wurde vor dem gpresult /r der lokale policy Ordner sowie die security config gelöscht als auch das Ereignisprotokoll. gpresult /r zeigt keine alten gpo's an, was korrekt wirkt.
- In den gelöschten Objekte der AD sind diese Objekte auch nicht mehr vorhanden weil die 180 Tage Tombstone Lifetime bereits um sind.
Nun meine Frage zu der offensichtlich defekten Datenbank:
1. könnte ein offline defrag helfen?
2. Wie stehen die Chancen beim Einsatz von ESEUTIL? (werden die Fehler anschließend auch wieder repliziert? müssen beiden offline genommen werden?)
3. Hat jemand gute Erfahrungen mit einem 3rd party tool das die db online repariert?
4. Wo könnten noch Protokolle rumliegen die interessant wären?
PS: die Events sind sehr sauber, es deutet nichts weiter auf Probleme hin. Server & Client
ich vermute einen Fehler in der ntds.dit Datenbank weil ich im gpoinventory.exe rsop Ergebnisse bekomme in denen Uralte gpos bei den Clients verarbeitet werden welche es schon lange nicht mehr gibt (Stehen da vielleicht alle jemals verarbeiteten drin?).
Diese Annahme bestätigt sich auch in der Praxis da Einstellungen angewendet werden, deren gpo gar nicht mehr existiert.
Außerdem habe ich hidden gpos gefunden welche auf keinem weg zu löschen waren nur ein OU Struktur Umbau mit Objekt verschieben hat dann geholfen. (Resultate per adsisearcher)
Hier ein paar Fakten:
- gpo Anzahl ist im sysvol/adsiedit/gpo.mmc konsistent und repl funktioniert fehlerfrei.
- ntdsutil (integrity & semantic database analysis) fehlerfrei
- 7016 Ereignisse auf den clients von cse's die unauffindbar sind.
- bei allen client gpo tests wurde vor dem gpresult /r der lokale policy Ordner sowie die security config gelöscht als auch das Ereignisprotokoll. gpresult /r zeigt keine alten gpo's an, was korrekt wirkt.
- In den gelöschten Objekte der AD sind diese Objekte auch nicht mehr vorhanden weil die 180 Tage Tombstone Lifetime bereits um sind.
Nun meine Frage zu der offensichtlich defekten Datenbank:
1. könnte ein offline defrag helfen?
2. Wie stehen die Chancen beim Einsatz von ESEUTIL? (werden die Fehler anschließend auch wieder repliziert? müssen beiden offline genommen werden?)
3. Hat jemand gute Erfahrungen mit einem 3rd party tool das die db online repariert?
4. Wo könnten noch Protokolle rumliegen die interessant wären?
PS: die Events sind sehr sauber, es deutet nichts weiter auf Probleme hin. Server & Client
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8037015693
Url: https://administrator.de/contentid/8037015693
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
11 Kommentare
Neuester Kommentar
Hi,
so so, Hidden GPOs.
Wenn ein Client eine GPO verarbeitet, welche es nicht mehr geben soll, dann kann das doch nur am Client liegen. Wenn jemand einen Befehl ausführt von einem Offizier, welcher bereits tot oder außer Dienst ist, dann ist die Ursache bei den Oberbefehlshabern? Bzw. bei den Büros, in denen diese amtieren?
Wenn ein Client GPO anwendet, dann kommen die Daten dafür irgendwoher: Entweder vom SYSVOL oder der Client hat diese Daten zwischengespeichert. Das GPO-Objekt im AD allein reicht dafür nicht aus. Normalerweise werden aber beim Löschen von GPO-Objekten aus dem AD auch die zugehörigen Dateien im SYSVOL ebenfalls gelöscht.
Das "Aufräumen" oder "Reparieren" der ntds.dit würde dahingehend überhaupt nichts bringen.
E.
so so, Hidden GPOs.
Wenn ein Client eine GPO verarbeitet, welche es nicht mehr geben soll, dann kann das doch nur am Client liegen. Wenn jemand einen Befehl ausführt von einem Offizier, welcher bereits tot oder außer Dienst ist, dann ist die Ursache bei den Oberbefehlshabern? Bzw. bei den Büros, in denen diese amtieren?
Wenn ein Client GPO anwendet, dann kommen die Daten dafür irgendwoher: Entweder vom SYSVOL oder der Client hat diese Daten zwischengespeichert. Das GPO-Objekt im AD allein reicht dafür nicht aus. Normalerweise werden aber beim Löschen von GPO-Objekten aus dem AD auch die zugehörigen Dateien im SYSVOL ebenfalls gelöscht.
- Bist Du sicher, dass diese GPO nicht mehr existieren?
- Meinst Du stattdessen vielleicht, dass diese GPO Deiner Meinung nach nicht mehr angewendet werden dürften (aber noch existieren)?
- Es gibt einige Richtlinien aus den GPO, welche auch dann noch gelten, wenn die GPO nicht mehr gilt.
- Auch Einstellungen (bzw. deren Ergebnisse) aus den GPO gelten weiter, wenn eine GPO nicht mehr angewendet wird, es sei denn, man hat bei den einzelnen Einstellungen explizit angegeben, dass diese entfernt werden sollen, sobald es die GPO nicht mehr gilt.
Das "Aufräumen" oder "Reparieren" der ntds.dit würde dahingehend überhaupt nichts bringen.
E.
Hi emeriks,
hidden GPO's, genau die..
Ich bin ganz deiner Meinung, GPO's werden vom Client gezogen und lokal ausgeführt, wenn die nicht da sind wird auch nix vom Server gezogen und ausgeführt. Soweit mein Kenntnisstand.
Ich bin der überzeugung das folgender Befehl alle Lokalen Settings löscht: (Bitte um Korrektur falls das falsch ist)
1. Definitiv (sysvol, gpo Backup, gpoinventory, adsiedit haben alle die identische Anzahl)
2. Nein, leider nicht.
3. Aber doch nicht wenn man den lokalen gpo speicher gelöscht hat oder werden die noch irgendwo anders abgelegt?
4. Die lokalen gpos wurden doch gelöscht und am Server liegt nix.
Die ntds.dit habe ich auf allen dc's geprüft, sind "Clean" und "Konsistent". Lediglich auf einem DC konnte die Domäne bei einer Abfrage für die Usergruppe nicht gleich aufgelöst werden. Sonst alles nach Vorgabe.
hidden GPO's, genau die..
Ich bin ganz deiner Meinung, GPO's werden vom Client gezogen und lokal ausgeführt, wenn die nicht da sind wird auch nix vom Server gezogen und ausgeführt. Soweit mein Kenntnisstand.
Ich bin der überzeugung das folgender Befehl alle Lokalen Settings löscht: (Bitte um Korrektur falls das falsch ist)
RD /S /Q "%WinDir%\System32\GroupPolicy" + Reboot
gpupdate /force
gpresult /H c:\gpresult.html1. Definitiv (sysvol, gpo Backup, gpoinventory, adsiedit haben alle die identische Anzahl)
2. Nein, leider nicht.
3. Aber doch nicht wenn man den lokalen gpo speicher gelöscht hat oder werden die noch irgendwo anders abgelegt?
4. Die lokalen gpos wurden doch gelöscht und am Server liegt nix.
Die ntds.dit habe ich auf allen dc's geprüft, sind "Clean" und "Konsistent". Lediglich auf einem DC konnte die Domäne bei einer Abfrage für die Usergruppe nicht gleich aufgelöst werden. Sonst alles nach Vorgabe.
Datenbankdienste stoppen
net stop ntds /force
Status der Datenbank abfragen
ESENTUTL /MH C:\Windows\NTDS\NTDS.DIT
Konsistenz der Datenbank abfragen
ESENTUTL /K C:\Windows\NTDS\NTDS.DIT
Berechtigungen prüfen (SYSTEM" und "BUILDIN\Administrators" hier Vollzugriff (vererbt))
cacls c:\windows\ntds\
cacls c:\windows\ntds\ntds.dit
cacls c:\windows\ntds\*.*
Ich bin mir jetzt nicht sicher, ob wir von der selben Sache reden.
Am Rande: Das Tool gpoinventory.exe stammt aus einer Zeit gleich nach der letzten Sintflut. Auch wenn die aktuelle Release angeblich von 2023 ist. Es sieht immer noch so aus.
Punkt 4: Von lokalen GPO hatte ich gar nichts geschrieben?
Man muss unterscheiden zwischen
Das Löschen von irgendwelchen Dateien auf dem Client ändert doch nichts an den durch die GPO bereits bewirkten Werte in der Registry. Diese sind die eigentlich interessanten Punkte.
Also wenn Du da auf dem Client
Am Rande: Das Tool gpoinventory.exe stammt aus einer Zeit gleich nach der letzten Sintflut. Auch wenn die aktuelle Release angeblich von 2023 ist. Es sieht immer noch so aus.
Punkt 4: Von lokalen GPO hatte ich gar nichts geschrieben?
Man muss unterscheiden zwischen
- GPO (eine Gruppe von Richtlinien, später kamen die Einstellungen dazu)
- Richtlinine (Bestandteil einer GPO)
- Einstellung (Bestandteil einer GPO)
Das Löschen von irgendwelchen Dateien auf dem Client ändert doch nichts an den durch die GPO bereits bewirkten Werte in der Registry. Diese sind die eigentlich interessanten Punkte.
Also wenn Du da auf dem Client
- "%WinDir%\System32\GroupPolicy" löschst
- alle durch GPO bewirkten Werte aus der Registry löschst
- GPOs anwendest
- Wenn ja: Überprüfe erst einmal, ob diese nicht doch durch andere GPO bewirkt werden.
- Wenn nein: Dann ist doch alles gut?
1Ich denke es könnte daran mangeln.
Gibt es eine Möglichkeit alte gpos und deren gesetzte Änderungen in der Registry zu finden und zu löschen?
Oder gibt es evtl. scripts/toolz dafür?
Antworten wie "client neu installieren" würde ich nicht lustig finden..
Was HKCU betrifft, so könnte es reichen, mit einem neuen Benutzerprofil zu testen. Meinetwegen sogar mit einem neuen Benutzer, falls es Sinn macht.
Was HKLM betrifft, ist das nicht so einfach.
Die Werte einiger Richtlininen werden im HKLM\Software\Policies gespeichert.
Die anderer auch direkt irgendwo im HKLM\Software.
Einstellungen hingegen können überall im HKLM gelandet sein. Das hängt davon ab, was da konkret verteilt wurde.
Und dann nicht vergessen, dass die Einstellungen ja auch noch Ordner, Dateien, Drucker, Scheduled Task usw. verteilt haben könnten. Von daher wäre es schon keine schlechte Idee, wenigstens einen "nackten" Test-Client einzusetzen. Das könnte auch eine VM im selben Subnet sein.
Was HKLM betrifft, ist das nicht so einfach.
Die Werte einiger Richtlininen werden im HKLM\Software\Policies gespeichert.
Die anderer auch direkt irgendwo im HKLM\Software.
Einstellungen hingegen können überall im HKLM gelandet sein. Das hängt davon ab, was da konkret verteilt wurde.
Und dann nicht vergessen, dass die Einstellungen ja auch noch Ordner, Dateien, Drucker, Scheduled Task usw. verteilt haben könnten. Von daher wäre es schon keine schlechte Idee, wenigstens einen "nackten" Test-Client einzusetzen. Das könnte auch eine VM im selben Subnet sein.
Übergibt die Automatik der gpo nicht irgendwo eine Eigenschaft welche im HKLM dadurch identifiziert und automatisiert werden könnte? woher hätte den sonst rsop die Information über uralt gpo's..
Oder reicht vielleicht ein regcleaner auch
Oder reicht vielleicht ein regcleaner auch
Wenn Du mit den Standard-Tools von Windows RSOP am Client abfragst, dann werden dort nicht mehr existierende GPO als Quelle von Richtlinien oder Einstellungen genannt?
- gpresult /h "%temp%\gpresult.html"
- mmc.exe --> Snapin "Richtlinienergebnissatz"
In der Zeit, in der wir das hier diskutieren, hätte ich schon 12 Clients als VM aufgesetzt und getestet.
so, den ganzen Tag damit verschissen aber ich konnte es lösen und das Problem lag nicht am client!
Man kann mich für verrück erklären aber nach einem defrag der ntds.dit welche anschließend auf einem dc (vm ich sag immer dc muss auf blech) 20mb weniger hatte sind die komischen UR-alten gpos bei allen clients im rsop verschwunden hurra!
Und noch was, falls jemand mal so ein Problem haben sollte, es lohnt sich auch am client in den folgenden regkeys nachzusehen (löschen):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
Lösung:
Danke an emeriks!
Wenn das nicht hilft, hiermit gehts auf die harte Tour.
Man kann mich für verrück erklären aber nach einem defrag der ntds.dit welche anschließend auf einem dc (vm ich sag immer dc muss auf blech) 20mb weniger hatte sind die komischen UR-alten gpos bei allen clients im rsop verschwunden hurra!
Und noch was, falls jemand mal so ein Problem haben sollte, es lohnt sich auch am client in den folgenden regkeys nachzusehen (löschen):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
Lösung:
wbadmin start backup -systemstate -backuptarget:\\smb\irgendeinordner -quiet
net stop ntds /y
ntdsutil
activate instance ntds
files
Compact to c:\
Integrity
Quit
Quit
copy c:\ntds.dit c:\windows\NTDS\ntds.dit
del c:\Windows\NTDS\*.log
net start ntdsDanke an emeriks!
Wenn das nicht hilft, hiermit gehts auf die harte Tour.
Man sollte anschließend dringend noch die beiden SYSVOL Verzeichnisse z.B. mit Beyond & Compare/robocopy händisch vergleichen. Besonders was die Berechtigungen angeht. Quasi DFSR manuell..
AD mit Schuss klingt nach einem guten Getränk für ITler
Schönes WE.
Trommel
Schönes WE.
Trommel
