GPOs auf anderen DCs nicht vorhanden

[fredy 10]

Hallo

Ich habe eine Windows Server 2016 Umgebung mit 3 DCs.

Nun sind unter SYSVOL auf dem DC1 alle Policys vorhanden, auf dem DC2 nur ein Teil und auf dem neu installierten DC3 ist noch gar nichts vorhanden unter SYSVOL\sysvol\domain.local

repadmin /syncall /APeD habe ich auf dem DC1 ausgeführt, sowie zuerst repadmin /syncall /AeD auf dem DC3

 

Wie kann ich die Replication der Policys anderweitig in Gang bringen?

 

Danke für Eure Hilfe

 

-fredy

[Nobbyaushb 1.511]

Wirft dir repadmin /syncall /force einen Fehler?

[fredy 10]

@Nobbyaushb nein, Ergebnis ist Syncall wurde ohne Fehler beendet.

[Nobbyaushb 1.511]

Dann mal hören, was noch als Ideen kommt…

[NorbertFe 2.175]

Und steht was im DFS Eventlog?

[fredy 10]

Sehe nichts als Informationen die eigentlich darauf deuten, dass alles ok ist.

[NorbertFe 2.175]

Nutzt du dfs Replikation fürs sysvol?

[fredy 10]

Ja, DFSR ist aktiviert.

dcdiag /test:replications bringt ebenfalls keine Fehler.

 

[NorbertFe 2.175]

Leg doch mal nen neues GPO an. Landet das auf allen DCs? Wenn im Eventlog nichts steht, muss man ja irgendwie mal eingrenzen.

[fredy 10]

@Nobbyaushb Das die GPO Dateien im Policys Ordner nicht vorhanden sind, hat mich ja darauf gebracht, dass etwas nicht stimmt. Beim neuen DC3 ist das Sysvol Verzeichnis ganz leer. Es wird immer noch auf die erste Replikation gewartet, gemäss dem DFS Manager Health Report.

[NorbertFe 2.175]

Und dann steht nix im im DFS-R Eventlog? Kaum vorstellbar. ;)

[lukas2002 1]

Schau dir vielleicht mal das Active Directory Replication Tool an, vielleicht gibt das ja was aus...

Hast du die DNS Einstellungen richtig gesetzt?
Wie lange besteht das System schon, hast du das erst neu aufgesetzt oder ist das schon leer beständig?

Gruß Lukas

[daabm 1.391]

Repadmin ist nur AD-Replikation, das hat bei Sysvol-Replikationsfehlern noch nie geholfen... Finde raus, warum DFS-R Sysvol nicht replizieren will, im Notfall probiere das Analogon zu D4/D2: https://docs.microsoft.com/en-US/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization

 

[fredy 10]

Ich denke mal, dass dies das Problem gewesen sein könnte, dass bei Subnets ein falsches Subnet drin war, wo die DCs nicht teil davon waren.

Auf meinem eigenen DC habe ich gesehen, dass da gar nichts drin war, darum schien mir das Löschen des Subnet-Eintrages die angemessene Lösung.

Ich habe dieses nun mal gelöscht und bin gespannt, ob das was bringt.

 

[NilsK 2.982]

Moin,

 

Das ist sehr unwahrscheinlich. Die Subnets sind im AD für die Clients da, damit sie den "richtigen" DC finden, der für sie am besten erreichbar ist. Es muss kein DC in einem Subnet sein. Mit deinem Problem wird das sehr wahrscheinlich nichts zu tun haben.

 

Falls hingegen die Subnets absichtlich hier eintragen waren, dürfte das Löschen jetzt neue Probleme erzeugen.

 

Gruß, Nils