11
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
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: 61029793773
Url: https://administrator.de/forum/sysvol-ordner-berechtigungen-auf-zwei-ad-dc-unterschiedlich-61029793773.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
11 Kommentare
Neuester Kommentar
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 und importiere.
Hab ich auch schon durch. 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 und importiere.
Hab ich auch schon durch. Pass auf das du keinen Dateisystemfehler hast sonst machst du das öfter ;)
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
Sekundären DC runterstufen, aus dem AD entfernen, neu installieren mit neuem Namen, wieder hochstufen.
Und für die Zukunft niemals Inplace Upgrades bei domain-controllern
Und für die Zukunft niemals Inplace Upgrades bei domain-controllern
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
Hallo zusammen,
vielen Dank für Eure Tipps!
Das DCDIAG.EXE hat tatsächlich Fehler im DFSREvent und VerifyReferences gefunden. Ansonsten war alles i.O.
Kann man hier irgendwas reparieren oder sollte ich zunächst erst mal Versuchen die FSMO Rollen zu reparieren?
Leider habe ich dazu im Internet nichts spezifisches gefunden, nur wie man die Rolle übertragen kann.
Persönliche Infos habe ich mit "...." unkenntlich gemacht.
vielen Dank für Eure Tipps!
Das DCDIAG.EXE hat tatsächlich Fehler im DFSREvent und VerifyReferences gefunden. Ansonsten war alles i.O.
Starting test: DFSREvent
Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
......................... Der Test DFSREvent für .......VMDC1 ist fehlgeschlagen. Starting test: VerifyReferences
Bei einigen Objekten für den Domänencontroller ......VMDC1 treten Probleme auf:
[1] Problem: Erwarteter Wert nicht vorhanden.
Basisobjekt: CN=NTDS Settings,CN=.......VMDC1,CN=Servers,CN=.......,CN=Sites,CN=Configuration,DC=....,DC=.....
Beschreibung des Basisobjekts: "DSA-Objekt"
Attributname des Wertobjekts: serverReferenceBL
Beschreibung des Wertobjekts: "SYSVOL-FRS-Mitgliedsobjekt"
Empfohlene Aktion: siehe Knowledge Base-Artikel "Q312862"
[1] Problem: Erwarteter Wert nicht vorhanden.
Basisobjekt: CN=.......VMDC1,OU=Domain Controllers,DC=.....,DC=.......
Beschreibung des Basisobjekts: "DC-Kontoobjekt"
Attributname des Wertobjekts: msDFSR-ComputerReferenceBL
Beschreibung des Wertobjekts: "SYSVOL FRS-Mitgliedsobjekt"
Empfohlene Aktion: siehe Knowledge Base-Artikel "Q312862"
......................... Der Test VerifyReferences für ..........VMDC1 ist fehlgeschlagen.Kann man hier irgendwas reparieren oder sollte ich zunächst erst mal Versuchen die FSMO Rollen zu reparieren?
Leider habe ich dazu im Internet nichts spezifisches gefunden, nur wie man die Rolle übertragen kann.
Persönliche Infos habe ich mit "...." unkenntlich gemacht.
Guten Morgen,
du kannst jetzt einen replikationspartner runter/raufstufen aber das Ergebnis wird lt. meiner persönlichen Erfahrung das gleiche sein.
du kannst jetzt einen replikationspartner runter/raufstufen aber das Ergebnis wird lt. meiner persönlichen Erfahrung das gleiche sein.
Hey, also > Zitat von @user217:
Guten Morgen,
du kannst jetzt einen replikationspartner runter/raufstufen aber das Ergebnis wird lt. meiner persönlichen Erfahrung das gleiche sein.
Hey, also wäre die beste Lösung wirklich ein komplett neuen AD aufzusetzen und diesen dann mit FSMO Rollen ausstatten?
Guten Morgen,
du kannst jetzt einen replikationspartner runter/raufstufen aber das Ergebnis wird lt. meiner persönlichen Erfahrung das gleiche sein.
Hey, also wäre die beste Lösung wirklich ein komplett neuen AD aufzusetzen und diesen dann mit FSMO Rollen ausstatten?
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
