SYSVOL Ordner-Berechtigungen auf zwei AD DC unterschiedlich
Guten Tag zusammen,
wir haben einen Primären und einen Sekundären AD-DC bei uns im Einsatz die sich gegenseitige replizieren.
Leider kommt es häufiger vor, dass sich unsere Clients die GPOs nicht richtig oder nur teilweise ziehen. Manchmal schlägt auch der Befehl "gpupdate /force" fehl und manchmal klappt er...
Nach längeren Recherchen haben wir festgestellt, dass der SYSVOL Ordner unter C:\Windows unterschiedliche Berechtigungen besitzen (siehe Screenshot).
Beide ADs wurden damals von 2016 auf 2019 und dann auf 2022 hochgezogen (Upgrade / InPlace Upgrade)
Des Weiteren wurden damals auch die Rolle des Primären und Sekundären AD-DC getauscht.
Ich vermute einfach mal, dass durch die ganzen Upgrades und Rollentausch sich auch die Berechtigungen etwas "zerschossen" haben...
Wir wissen nun nicht, wie wir das ganze Problemlos reparieren können.
Wir haben auch festgestellt, dass bestimmte GPOs, welche auf dem Primären AD-DC unter C:\Windows\SYSVOL\domain\Policies liegen, nicht auf dem Sekundären AD-DC liegen... Vermutlich daher auch immer wieder der fehler, dass die Clients sich einige GPOs nicht greifen können...
Auch direkt in der "Gruppenrichtlinienverwaltung" zeigt er uns das ein Zugriff auf SYSVOL nicht möglich wäre (siehe Screenshot).
Ich hoffe Ihr könnt uns helfen, die Berechtigungen wieder gerade zu biegen.
Vielen DanK!
Mit vielen Grüßen,
Max
wir haben einen Primären und einen Sekundären AD-DC bei uns im Einsatz die sich gegenseitige replizieren.
Leider kommt es häufiger vor, dass sich unsere Clients die GPOs nicht richtig oder nur teilweise ziehen. Manchmal schlägt auch der Befehl "gpupdate /force" fehl und manchmal klappt er...
Nach längeren Recherchen haben wir festgestellt, dass der SYSVOL Ordner unter C:\Windows unterschiedliche Berechtigungen besitzen (siehe Screenshot).
Beide ADs wurden damals von 2016 auf 2019 und dann auf 2022 hochgezogen (Upgrade / InPlace Upgrade)
Des Weiteren wurden damals auch die Rolle des Primären und Sekundären AD-DC getauscht.
Ich vermute einfach mal, dass durch die ganzen Upgrades und Rollentausch sich auch die Berechtigungen etwas "zerschossen" haben...
Wir wissen nun nicht, wie wir das ganze Problemlos reparieren können.
Wir haben auch festgestellt, dass bestimmte GPOs, welche auf dem Primären AD-DC unter C:\Windows\SYSVOL\domain\Policies liegen, nicht auf dem Sekundären AD-DC liegen... Vermutlich daher auch immer wieder der fehler, dass die Clients sich einige GPOs nicht greifen können...
Auch direkt in der "Gruppenrichtlinienverwaltung" zeigt er uns das ein Zugriff auf SYSVOL nicht möglich wäre (siehe Screenshot).
Ich hoffe Ihr könnt uns helfen, die Berechtigungen wieder gerade zu biegen.
Vielen DanK!
Mit vielen Grüßen,
Max
Please also mark the comments that contributed to the solution of the article
Content-ID: 61029793773
Url: https://administrator.de/contentid/61029793773
Printed on: September 1, 2024 at 08:09 o'clock
11 Comments
Latest comment
Moin,
Wenn der SYSVOL Inhalt unterschiedlich ist, dann stimmt wohl was mit der Replikation/DFSR nicht - da nützt auch kein Backup/Restore was. Lass doch mal dcdiag auf beiden DCs laufen.
lg,
Slainte
die Rolle des Primären und Sekundären AD-DC getauscht.
Was genau meinst du damit? Es gibt im AD keinen Primären/sekundären DC. Oder sprichst du von den FSMO Rollen?Wenn der SYSVOL Inhalt unterschiedlich ist, dann stimmt wohl was mit der Replikation/DFSR nicht - da nützt auch kein Backup/Restore was. Lass doch mal dcdiag auf beiden DCs laufen.
lg,
Slainte
Moin @MadMax93
bei den div. Upgrades auf neuere Server Versionen kann ich mir gut vorstellen, dass da was mit den FSMO Rollen durcheinander gekommen ist. Normalerweise gibt es bei mehreren DCs eben EINEN Betriebsmaster, und weitere Replikatoren. So wie ich das verstanden habe replizierend sich die DCs nicht gegenseitig, sondern immer nur vom Betriebsmaser (mit den FSMO Rollen) auf alle nachgeordneten Replikations-DCs.
Denkbar ist aber, dass die FSMO Rollen eben nicht korrekt auf einem DC verankert sind, Sonden irgendwie bei den Upgrades verteilt wurden, wie das der Kollege @SlainteMhath bereits anmerkte.
Kreuzberger
bei den div. Upgrades auf neuere Server Versionen kann ich mir gut vorstellen, dass da was mit den FSMO Rollen durcheinander gekommen ist. Normalerweise gibt es bei mehreren DCs eben EINEN Betriebsmaster, und weitere Replikatoren. So wie ich das verstanden habe replizierend sich die DCs nicht gegenseitig, sondern immer nur vom Betriebsmaser (mit den FSMO Rollen) auf alle nachgeordneten Replikations-DCs.
Denkbar ist aber, dass die FSMO Rollen eben nicht korrekt auf einem DC verankert sind, Sonden irgendwie bei den Upgrades verteilt wurden, wie das der Kollege @SlainteMhath bereits anmerkte.
Kreuzberger
mach dir ein Backup der GPO's per powershell:
Get-GPO -All | Backup-GPO -Path "C:\Program Files\MSCT\_AktuelleGPOs"
lösch anschließend (mit Backup) alles raus (GPO Editor) und importiere diese wieder nachdem du nur noch einen DC laufen hast. (Vergleiche die Menge der Gpo*s mit der Menge der Sysvol Dateiobjekte. Du kannst die über die SID eindeutig identifizieren. Ist viel arbeit aber dann ist ruhe.
Und pass auf das du keinen Dateisystemfehler hast sonst machst du das öfter ;)
Get-GPO -All | Backup-GPO -Path "C:\Program Files\MSCT\_AktuelleGPOs"
lösch anschließend (mit Backup) alles raus (GPO Editor) und importiere diese wieder nachdem du nur noch einen DC laufen hast. (Vergleiche die Menge der Gpo*s mit der Menge der Sysvol Dateiobjekte. Du kannst die über die SID eindeutig identifizieren. Ist viel arbeit aber dann ist ruhe.
Und pass auf das du keinen Dateisystemfehler hast sonst machst du das öfter ;)
@MadMax93
es ist sicher eine verfahrene Situation. einen AD DC komplett neu aufsetzen würde bedeuten, dass du ein komplett jungfräuliches AD bekommst, wo erst ei mal nichts drin ist. D. h., alle deine User, alle deiner Rechner, schlicht alles müsste neu aufgebeut werden. Wie umfangreich das wäre kann hier niemand beurteilen.
Bei 20 Usern und einem Fileserver macht es sinn, alles neu zu machen.
Bei 200 Usern und 15 Fileserver plus XYZ ist der aufwand schon ein ganz anderer und es könnte lohnend sein, das eigentliche Problem zu lösen.
ggf hierzu:
https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
Man kann sicher über PowerShell (ggf. weiss da jemand die Befehle) Analysen zu den FSMO Rollen starten, wo denn welche rolle gerade verankert ist, vielleicht doppelt läuft usw.
Kreuzberger
es ist sicher eine verfahrene Situation. einen AD DC komplett neu aufsetzen würde bedeuten, dass du ein komplett jungfräuliches AD bekommst, wo erst ei mal nichts drin ist. D. h., alle deine User, alle deiner Rechner, schlicht alles müsste neu aufgebeut werden. Wie umfangreich das wäre kann hier niemand beurteilen.
Bei 20 Usern und einem Fileserver macht es sinn, alles neu zu machen.
Bei 200 Usern und 15 Fileserver plus XYZ ist der aufwand schon ein ganz anderer und es könnte lohnend sein, das eigentliche Problem zu lösen.
ggf hierzu:
https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
Man kann sicher über PowerShell (ggf. weiss da jemand die Befehle) Analysen zu den FSMO Rollen starten, wo denn welche rolle gerade verankert ist, vielleicht doppelt läuft usw.
Kreuzberger
Moin,
ohauahauaha! Da geht ja einiges durcheinander.
Nein, habt Ihr nicht.
Die Clients ziehen sich nie irgendwelche GPOs.
Aha. Fehlermeldung?
Das ist schlecht.
Wieso zwei ADs? Sind es nun zwei Domain Controller oder sind es zwei ADs mit Vertrauensstellung? Und InPlace-Upgrades macht man auf DCs grundsätzlich nicht.
Das ist spannend, da es ja keine solchen Rollen gibt. Was willst Du uns damit mitteilen?
Ich vermute eher, dass bei so viel geballtem Expertenwissen einer Eurer Spezialisten an den Rechten rumgefummelt hat, weil er auf www.wirwissenallesbesser.de gaaaaaaaaaanz tolle Sicherheitstipps bekommen hat. So ein Murks kommt nicht davon, dass man Upgrades gemacht hat oder Rollen korrekt verschiebt.
Ganz ehrlich: Warum holt Ihr Euch dann nicht jemanden ins Haus, der was davon versteht?
Nochmal: Es gibt keinen primären oder sekundären DC. Alle DCs sind gleichberechtigt. Euer Problem ist aber genau dieses, dass Sysvol nicht korrekt repliziert wird.
Nein. Er zeigt, dass auf den einen DC nicht zugegriffen werden kann. Das ist was vollkommen anderes.
Hier eine Anleitung, wie man ein kaputtes DFS-R des SYSVOL reparieren kann. Euer Ausgangspunkt ist der, den Du den primären nennst. Hier scheinen auf den ersten Blick die Rechte korrekt zu sein.
https://sbsland.me/2022/02/15/fix-der-sysvol-replikation-dfs-r/
Nochmal der Rat: Holt Euch jemanden dauerhaft ins Haus, der vom AD was versteht. Ihr tut es offensichtlich nicht.
Viel Glück!
Liebe Grüße
Erik
ohauahauaha! Da geht ja einiges durcheinander.
Zitat von @MadMax93:
wir haben einen Primären und einen Sekundären AD-DC bei uns im Einsatz die sich gegenseitige replizieren.
wir haben einen Primären und einen Sekundären AD-DC bei uns im Einsatz die sich gegenseitige replizieren.
Nein, habt Ihr nicht.
Leider kommt es häufiger vor, dass sich unsere Clients die GPOs nicht richtig oder nur teilweise ziehen.
Die Clients ziehen sich nie irgendwelche GPOs.
Manchmal schlägt auch der Befehl "gpupdate /force" fehl und manchmal klappt er...
Aha. Fehlermeldung?
Nach längeren Recherchen haben wir festgestellt, dass der SYSVOL Ordner unter C:\Windows unterschiedliche Berechtigungen besitzen (siehe Screenshot).
Das ist schlecht.
Beide ADs wurden damals von 2016 auf 2019 und dann auf 2022 hochgezogen (Upgrade / InPlace Upgrade)
Wieso zwei ADs? Sind es nun zwei Domain Controller oder sind es zwei ADs mit Vertrauensstellung? Und InPlace-Upgrades macht man auf DCs grundsätzlich nicht.
Des Weiteren wurden damals auch die Rolle des Primären und Sekundären AD-DC getauscht.
Das ist spannend, da es ja keine solchen Rollen gibt. Was willst Du uns damit mitteilen?
Ich vermute einfach mal, dass durch die ganzen Upgrades und Rollentausch sich auch die Berechtigungen etwas "zerschossen" haben...
Ich vermute eher, dass bei so viel geballtem Expertenwissen einer Eurer Spezialisten an den Rechten rumgefummelt hat, weil er auf www.wirwissenallesbesser.de gaaaaaaaaaanz tolle Sicherheitstipps bekommen hat. So ein Murks kommt nicht davon, dass man Upgrades gemacht hat oder Rollen korrekt verschiebt.
Wir wissen nun nicht, wie wir das ganze Problemlos reparieren können.
Ganz ehrlich: Warum holt Ihr Euch dann nicht jemanden ins Haus, der was davon versteht?
Wir haben auch festgestellt, dass bestimmte GPOs, welche auf dem Primären AD-DC unter C:\Windows\SYSVOL\domain\Policies liegen, nicht auf dem Sekundären AD-DC liegen... Vermutlich daher auch immer wieder der fehler, dass die Clients sich einige GPOs nicht greifen können...
Nochmal: Es gibt keinen primären oder sekundären DC. Alle DCs sind gleichberechtigt. Euer Problem ist aber genau dieses, dass Sysvol nicht korrekt repliziert wird.
Auch direkt in der "Gruppenrichtlinienverwaltung" zeigt er uns das ein Zugriff auf SYSVOL nicht möglich wäre (siehe Screenshot).
Nein. Er zeigt, dass auf den einen DC nicht zugegriffen werden kann. Das ist was vollkommen anderes.
Ich hoffe Ihr könnt uns helfen, die Berechtigungen wieder gerade zu biegen.
Hier eine Anleitung, wie man ein kaputtes DFS-R des SYSVOL reparieren kann. Euer Ausgangspunkt ist der, den Du den primären nennst. Hier scheinen auf den ersten Blick die Rechte korrekt zu sein.
https://sbsland.me/2022/02/15/fix-der-sysvol-replikation-dfs-r/
Nochmal der Rat: Holt Euch jemanden dauerhaft ins Haus, der vom AD was versteht. Ihr tut es offensichtlich nicht.
Viel Glück!
Liebe Grüße
Erik
Moin,
Eher nicht. Und wenn, dann hätte das ganz andere Auswirkungen.
Nein, es gibt fünf. Zwei auf Ebene der Gesamtstruktur und drei auf Ebene der Domain. Schema-Master und Domain-Name-Master gibt es nur einmal im Forest. Infrastruktur-Master, RID-Master und PDC-Emulator gibt es nur einmal pro Domain (auch jeweils einmal in der Subdomain). Siehe: https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
Das hast Du falsch verstanden. Selbstverständlich replizieren alle DCs die Änderungen, die auf ihnen vorgenommen wurden, an alle anderen DCs.
Das Verteilen der Rollen ist nicht nur nicht schädlich, sondern in größeren Umgebungen sogar üblich und nützlich. Die fünf Rollen können auch auf fünf verschiedene DCs verteilt werden. Das ist überhaupt kein Problem.
Im Übrigen hat das vorliegende Problem nichts mit den FSMO-Rollen zu tun.
Liebe Grüße
Erik
Zitat von @kreuzberger:
bei den div. Upgrades auf neuere Server Versionen kann ich mir gut vorstellen, dass da was mit den FSMO Rollen durcheinander gekommen ist.
bei den div. Upgrades auf neuere Server Versionen kann ich mir gut vorstellen, dass da was mit den FSMO Rollen durcheinander gekommen ist.
Eher nicht. Und wenn, dann hätte das ganz andere Auswirkungen.
Normalerweise gibt es bei mehreren DCs eben EINEN Betriebsmaster, und weitere Replikatoren.
Nein, es gibt fünf. Zwei auf Ebene der Gesamtstruktur und drei auf Ebene der Domain. Schema-Master und Domain-Name-Master gibt es nur einmal im Forest. Infrastruktur-Master, RID-Master und PDC-Emulator gibt es nur einmal pro Domain (auch jeweils einmal in der Subdomain). Siehe: https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
So wie ich das verstanden habe replizierend sich die DCs nicht gegenseitig, sondern immer nur vom Betriebsmaser (mit den FSMO Rollen) auf alle nachgeordneten Replikations-DCs.
Das hast Du falsch verstanden. Selbstverständlich replizieren alle DCs die Änderungen, die auf ihnen vorgenommen wurden, an alle anderen DCs.
Denkbar ist aber, dass die FSMO Rollen eben nicht korrekt auf einem DC verankert sind, Sonden irgendwie bei den Upgrades verteilt wurden, wie das der Kollege @SlainteMhath bereits anmerkte.
Das Verteilen der Rollen ist nicht nur nicht schädlich, sondern in größeren Umgebungen sogar üblich und nützlich. Die fünf Rollen können auch auf fünf verschiedene DCs verteilt werden. Das ist überhaupt kein Problem.
Im Übrigen hat das vorliegende Problem nichts mit den FSMO-Rollen zu tun.
Liebe Grüße
Erik