Jump to content

Server 2016 (DC) hat nicht die korrekte Systemzeit


Direkt zur Lösung Gelöst von NorbertFe,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar
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

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

Moin,

besten Dank schon mal für die Antworten.
 

Zitat

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.

Link zu diesem Kommentar

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)
:eye2:

 

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 von Bitdrop
Link zu diesem Kommentar

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:rolleyes:

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...