Bitdrop 1 Geschrieben 24. Januar 2023 Melden Teilen Geschrieben 24. Januar 2023 Hallo miteinander, ich bin langsam echt am verzweifeln. Ich hoffe ihr könnt mir hierbei helfen. Folgende Lage: Windows Server 2016 (PDC, Zeitserver für alle andere Clients/Server in der Domäne). läuft als VM in VMware. Die Uhrzeit auf dem Server geht um circa 45 Sekunden "hinterher". Ist es auf dem Server 15:00, ist es auf allen anderen Geräten schon 15:01. Das klingt erst mal nicht schön, aber eigentlich auch nicht richtig schlimm. Die Sache ist aber das sich auch unsere Zeiterfassung die Uhrzeit vom PDC holt. Somit könnte einem theoretisch jeden Tag eine knappe Minute Arbeitszeit fehlen. (Ja... es gibt Menschen die nach Punkt 8 Stunden den Hammer fallen lassen wollen). Der Aufbau ist folgender: Firewall holt sich aus dem Internet die korrekte Zeit <-- Funktioniert Server 2016 (PDC) soll sich die Zeit von der Firewall holen <-- Funktioniert nicht Alle anderen holen sich die Zeit vom Server 2016 (PDC) <-- Funktioniert Die Firewall holt sich die korrekte Zeit aus dem Internet, das klappt. Jetzt fängt es aber schon an: Wenn ich auf dem Server 2016 in der Registry schaue steht dort folgendes: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters NtpServer: (IP der Firewall) 1.pool.ntp.org 2.pool.ntp.org Also insgesamt 3 Zeitserver die theoretisch zum holen der Zeit da wären. Type = NTP soweit so gut. Also weiter in der Powershell/CMD w32tm /query /status Sprungindikator: 0(keine Warnung) Stratum: 1 (Primärreferenz - synchron. über Funkuhr) Präzision: -6 (15.625ms pro Tick) Stammverzögerung: 0.0000000s Stammabweichung: 10.0000000s Referenz-ID: 0x4C4F434C (Quellname: "LOCL") Letzte erfolgr. Synchronisierungszeit: 24.01.2023 15:49:55 Quelle: Local CMOS Clock Abrufintervall: 6 (64s) Jetzt ist die Frage warum hier auf einmal Local CMOS Clock steht Also weiter in der Powershell/CMD w32tm /query /peers Anzahl Peers: 1 Peer: Status: Ausstehend Verbleibende Zeit: 1753.7860163s Modus: 0 (Reserviert) Stratum: 0 (nicht angegeben) PeerAbrufintervall: 0 (nicht angegeben) Da sollte doch bei Peer: Zumindest die IP der Firewall drin stehen (steht ja so auch in der Registry) net stop w32time net start w32time Dienste gestoppt und erneut gestartet. Aber keine Veränderung. Quelle bleibt auf Local CMOS Clock und in den Peers steht nichts drin. Hat hier noch jemand eine Idee? Hab ich irgend etwas über sehen? Server wird heute Abend einmal neu gestartet aber ich denke daran wird es nicht liegen. Beste Grüße Zitieren Link zu diesem Kommentar
NorbertFe 2.045 Geschrieben 24. Januar 2023 Melden Teilen Geschrieben 24. Januar 2023 vor 13 Minuten schrieb Bitdrop: Server 2016 (PDC) soll sich die Zeit von der Firewall holen <-- Funktioniert nicht Tjo, dann ist das die Stelle. Vielleicht hilft ja das, anstatt da von Hand rumzufummeln. https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo Im Zweifel mal den Time Service de-registrieren und wieder registrieren, dann ist zumindest erstmal alles wieder auf default. Ansonsten sicherstellen, dass deine VM definitiv die Zeit nicht vom VMware-Host erhält. Bye Norbert Zitieren Link zu diesem Kommentar
cj_berlin 1.323 Geschrieben 24. Januar 2023 Melden Teilen Geschrieben 24. Januar 2023 vor 18 Minuten schrieb Bitdrop: Somit könnte einem theoretisch jeden Tag eine knappe Minute Arbeitszeit fehlen. Hmm. Die würde ja beim Ausstechen genauso verschoben werden wie beim Einstechen - wenn in der Realtiät exakt 8 Stunden (09:00-17:00) vergehen, dann auch in der Zeiterfassung (09:01-17:01) Aber dennoch muss es natürlich korrigiert werden. Der Hinweis von @NorbertFe auf die Konfiguration per GPO ist goldrichtig. Dennoch muss manchmal die betroffene Maschine rebootet werden, damit die Konfiguration greift. Zitieren Link zu diesem Kommentar
Nobbyaushb 1.472 Geschrieben 24. Januar 2023 Melden Teilen Geschrieben 24. Januar 2023 Moin, das stimmt, und ist der beste Weg OT - es gibt schon lange keinen PDC mehr - OT off Zitieren Link zu diesem Kommentar
daabm 1.356 Geschrieben 24. Januar 2023 Melden Teilen Geschrieben 24. Januar 2023 w32tm /stripchart /computer:<IP-der-Firewall> Und das gleiche noch für alle anderen Zeitquellen, die der PDCe hat. Und darauf achten, daß der VMIC-Timeprovider nicht aktiv ist. Zitieren Link zu diesem Kommentar
NilsK 2.939 Geschrieben 24. Januar 2023 Melden Teilen Geschrieben 24. Januar 2023 Moin, VMware. Nix VMIC. Da muss man ein bisschen mehr tun, um den im Zaum zu halten. Und zumindest vor ein paar Jahren ging es gar nicht zu 100 Prozent. Gruß, Nils Zitieren Link zu diesem Kommentar
daabm 1.356 Geschrieben 24. Januar 2023 Melden Teilen Geschrieben 24. Januar 2023 Mist - mit HyperV verwechselt Zitieren Link zu diesem Kommentar
Bitdrop 1 Geschrieben 25. Januar 2023 Autor Melden Teilen Geschrieben 25. Januar 2023 Moin, besten Dank schon mal für die Antworten. Zitat Vielleicht hilft ja das, anstatt da von Hand rumzufummeln. https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo Werden die Einstellungen nicht von den "Händischen" überschrieben? Ansonsten würde ich das nochmal versuchen. Ein Neustart hat leider auch nicht geholfen. Zitat Ansonsten sicherstellen, dass deine VM definitiv die Zeit nicht vom VMware-Host erhält Das ist nicht der Fall. Also die Zeit wird definitiv nicht vom VMware Host geholt. Zitat w32tm /stripchart /computer:<IP-der-Firewall> Das zeigt mir witzigerweise, genau die falsche Zeit an. Also nicht die Zeit der Firewall, sondern die Zeit des PDC. Ich habe es nun schon mit /unregister und /register versucht, wie es halt viele Anleitungen im Netz beschreiben. Alles ohne Erfolg. Die Zeit bleibt "falsch" und die Quelle bleibt Local CMOS Clock. Da werd ich mich mal mit den GPO's beschäftigen. Zitieren Link zu diesem Kommentar
cj_berlin 1.323 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 vor 27 Minuten schrieb Bitdrop: Das zeigt mir witzigerweise, genau die falsche Zeit an. Also nicht die Zeit der Firewall, sondern die Zeit des PDC. Ja, links im Ergebnis zeigt er die lokale Zeit an, in diesem Fall die falsche. Zitieren Link zu diesem Kommentar
NorbertFe 2.045 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 vor 43 Minuten schrieb Bitdrop: Werden die Einstellungen nicht von den "Händischen" überschrieben? Ansonsten würde ich das nochmal versuchen. Nee policies haben Vorrang. Wo warst du denn die letzten 22 Jahre? ;) Zitieren Link zu diesem Kommentar
Bitdrop 1 Geschrieben 25. Januar 2023 Autor Melden Teilen Geschrieben 25. Januar 2023 (bearbeitet) Zitat Ja, links im Ergebnis zeigt er die lokale Zeit an, in diesem Fall die falsche. Richtig, was bringt mir dann aber das Kommando? Zitat Wo warst du denn die letzten 22 Jahre? ;) Ohweh... Ich hab glaub ich schon Matsch im Kopf :-D Ich werd es mal damit probieren. bearbeitet 25. Januar 2023 von Bitdrop Zitieren Link zu diesem Kommentar
cj_berlin 1.323 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 vor 13 Minuten schrieb Bitdrop: Richtig, was bringt mir dann aber das Kommando? Das zeigt Dir in der *rechten* Spalte die Abweichung an. Zitieren Link zu diesem Kommentar
Bitdrop 1 Geschrieben 25. Januar 2023 Autor Melden Teilen Geschrieben 25. Januar 2023 (bearbeitet) Okay also ich habe das Ganze jetzt mal so ausgeführt, wie es hier https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo beschrieben ist. Im Log des DC tauchen 5 Ereignisse auf: -Der Zeitdienst wird als Zeitquelle angekündigt. -Der Zeitdienst wird als gute Zeitquelle angekündigt. -Aufgrund eines Ermittlungsfehlers konnte von "NtpClient" kein Domänenpeer als Zeitquelle festgelegt werden. In 15 Minuten wird ein weiterer Versuch ausgeführt und das Intervall für weitere Versuche anschließend verdoppelt Fehler: Der Eintrag wurde nicht gefunden. (0x800706E1) -Dienst "Windows-Zeitgeber" befindet sich jetzt im Status "Ausgeführt". -Aufgrund eines Ermittlungsfehlers konnte von "NtpClient" kein Domänenpeer als Zeitquelle festgelegt werden. In 15 Minuten wird ein weiterer Versuch ausgeführt und das Intervall für weitere Versuche anschließend verdoppelt Fehler: Der Eintrag wurde nicht gefunden. (0x800706E1) Die neue Gruppenrichtlinie wurde laut Log angewandt. Die Zeit hinkt nach wie vor eine knappe Minute hinterher. Nur mal zum Verständnis (ich zweifel hier schon an mir selbst) Sollte die GPO nicht die Einstellungen in der Registry, die ich vorher per Hand abgeändert habe, überschreiben? Denn dort stehen noch die alten Werte drin (NTP Server) bearbeitet 25. Januar 2023 von Bitdrop Zitieren Link zu diesem Kommentar
NorbertFe 2.045 Geschrieben 25. Januar 2023 Melden Teilen Geschrieben 25. Januar 2023 vor 14 Minuten schrieb Bitdrop: Sollte die GPO nicht die Einstellungen in der Registry, die ich vorher per Hand abgeändert habe, überschreiben? Denn dort stehen noch die alten Werte drin (NTP Server) Nein, die Policy schreibt natürlich in \Policies ;) Zitieren Link zu diesem Kommentar
Bitdrop 1 Geschrieben 25. Januar 2023 Autor Melden Teilen Geschrieben 25. Januar 2023 Ich habe mal mit rsop auf dem DC nach gesehen. Jetzt ist mir aufgefallen das der DC die Default Domain Policy zieht, statt die extra erstelle neue GPO mit dem WMI Filter. Das dürfte wohl der Grund sein warum das Ganze nicht funktioniert. Jetzt muss ich ja nur noch raus finden warum der DC die Default Policy zieht und nicht die für ihn vorgesehene Policy Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.