Neuer DC / Probleme mit Gruppenrichtlinien

[Sebastian R 10]

Nunja weil ich auf dem alten DC nichtmal vernünftig Fehlersuche betreiben kann, da sich z.B. Ereignisanzeige oder Servermanager sofort wieder schließen.

Daher will ich zuerst die korrupten Dateien wiederherstellen. Oder ist das unklug?

[NilsK 2.968]

Moin,

 

"korrupte Dateien wiederherstellen" - das sind welche? Die du wie identifizierst? Und wie wiederherstellst?

 

Die Ereignisanzeige kann man auch remote aufrufen. Den Servermanager brauchst du zum Troubleshooting nicht. Bevor ich aufs Geratewohl irgendwelche Dateien überschriebe, versuchte ich zunächst, die Lage genauer einzuschätzen.

 

Gruß, Nils

[magheinz 110]

1. .local ist nie eine gute Idee und war es auch nie

2. du mischt ip v4 und v6.

3. deine angaben zur dns-config stimmen nicht mit.den screenshots überein. stichwort "localhost"

bearbeitet 12. Juni 2017 von magheinz

[Sebastian R 10]

"korrupte Dateien wiederherstellen" - das sind welche? Die du wie identifizierst? Und wie wiederherstellst?

CBS.log, DISM & sfc

Ursache war tatsächlich eine korrupte Datei die im Zusammenhang mit dem .NET Framework stand und so zu allerlei Fehlern auf dem alten Server führte.

Und die Replikationsprobleme (sysvol, netlogon) waren auf eine fehlerhafte DFSR-JET-Datenbank zurückzuführen. Das ist nun auch behoben.

[NilsK 2.968]

Moin,

 

OK, danke für die Rückmeldung.

 

Gruß, Nils

[Sebastian R 10]

Zeitprobleme und virtueller DC -> Deaktiviere mal die Zeitsynchronisation mit dem Host. Und: https://www.faq-o-matic.net/2010/04/21/virtuelle-dcs-zeitprobleme-vermeiden/

Zu deiner WINS Konfig: https://www.faq-o-matic.net/2004/10/23/wie-sollte-wins-konfiguriert-werden/

Ich greife das nochmal auf, weil ich im Eventlog des neuen virtuellen DCs noch immer regelmäßig die ID 144 (Time-Service). Bei den Integrationsdiensten habe ich die Zeitsynchronisation schon deaktiviert. Dann auf externe Synchronisation umgestellt:

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x1" /syncfromflags:MANUAL /reliable:yes
w32tm /config /update  
w32tm /resync
w32tm /resync /rediscover

Danach mit /query /status und /query /source überprüft sieht auch alles gut aus. Nach einem Neustart jedoch habe ich wieder Lokal / CMOS Uhr als Zeitquelle. :confused:

[Sebastian R 10]

Keiner ne Idee?

[NilsK 2.968]

Moin,

 

Nicht manuell konfigurieren. Nimm die Anleitung von Norbert bei gruppenrichtlinien.de.

 

Gruß, Nils

[Sebastian R 10]

Moin,

 

Nicht manuell konfigurieren. Nimm die Anleitung von Norbert bei gruppenrichtlinien.de.

 

Gruß, Nils

Danke für den Hinweis. Die Anleitung habe ich abgearbeitet, trotzdem taucht in der Ereignisanzeige immer wieder Event 144 auf. Das wechselt sich ab mit Event 143 (Der Zeitdienst wird als gute Zeitquelle angekündigt). :confused:

[Sebastian R 10]

Und auch alle Clients nehmen als Zeitquelle weiterhin den alten Server. :nene:

[lefg 276]

Und auch alle Clients nehmen als Zeitquelle weiterhin den alten Server. :nene:

 

Moin

 

Warum sollten die Clients einen anderen Server als Zeitquelle benutzen?

[Sebastian R 10]

Da alle FSMO Rollen, also auch PDCE, auf den neuen Server umgezogen sind (siehe #1). Und nur diesen sollten die Clients als Zeitquelle nehmen.

[NorbertFe 2.090]

Und warum sollten sie das, wenn sie genauso gut den anderen DC fragen können?

[lefg 276]

Ich habe es so in Erinnerung: Anmeldeserver ist Zeitquelle für den Client. Ob das heute noch so ist? Und welcher DC Anmeldeserver wird, dass ist eine Frage der Ereichbarkeit vom Client.

 

Bitte @Norbert, korrigiere, kritisiere falls nötig! :)

bearbeitet 29. Juni 2017 von lefg

[NorbertFe 2.090]

Richtig.