19
Server 2008 R2 w32tm Zeitserver Problematik
Seid gegrüst
Ich möchte mich kurz mit einem Problem an euch wenden. Mein primary DC möchte sich nicht mit dem externen NTP Server verbinden. Ja ich weiss, es gibt unzählige Threads zu diesem Thema im Netz, und ich habe mir bestimmt die meisten davon angesehen.
Problembeschreibung:
Der Peer Status bleibt auf Ausstehend:
Peer: time.windows.com
Status: Ausstehend
Verbleibende Zeit: 0.0000000s
Modus: 0 (Reserviert)
Stratum: 0 (nicht angegeben)
PeerAbrufintervall: 0 (nicht angegeben)
HostAbrufintervall: 0 (nicht angegeben)
PS C:\Windows\system32> w32tm /query /peers /verbose
Anzahl Peers: 1
Zudem bekomme ich bei der Monitor Abfrage einen "WSAECONNRESET" Fehler:
Als Source wird noch immer "Local CMOS Clock" angezeigt. Ja, es handelt sich um eine virtuelle Maschine, und ja ich habe bei VMware den Haken entfernt, damit die VM die Zeit nicht mehr mit dem Host synchronisiert.
Der betroffene DC hat alle FSMO Rollen. Die anderen beiden DCs sind für NT5DS konfiguriert, wie es sein sollte.
Ich habe auch bereits mal eine re-registering des Dienstes durchgeführt; ohne Erfolg.
Der AnnounceFlags Eintrag in der Registry hat den Wert 5.
GPOs mit Zeitdienst Einstellungen sind keine mehr aktiv.
Hat jemand noch eine Idee?
Danke und Gruss, C3dy
Ich möchte mich kurz mit einem Problem an euch wenden. Mein primary DC möchte sich nicht mit dem externen NTP Server verbinden. Ja ich weiss, es gibt unzählige Threads zu diesem Thema im Netz, und ich habe mir bestimmt die meisten davon angesehen.
Problembeschreibung:
Der Peer Status bleibt auf Ausstehend:
Peer: time.windows.com
Status: Ausstehend
Verbleibende Zeit: 0.0000000s
Modus: 0 (Reserviert)
Stratum: 0 (nicht angegeben)
PeerAbrufintervall: 0 (nicht angegeben)
HostAbrufintervall: 0 (nicht angegeben)
PS C:\Windows\system32> w32tm /query /peers /verbose
Anzahl Peers: 1
Zudem bekomme ich bei der Monitor Abfrage einen "WSAECONNRESET" Fehler:
Als Source wird noch immer "Local CMOS Clock" angezeigt. Ja, es handelt sich um eine virtuelle Maschine, und ja ich habe bei VMware den Haken entfernt, damit die VM die Zeit nicht mehr mit dem Host synchronisiert.
Der betroffene DC hat alle FSMO Rollen. Die anderen beiden DCs sind für NT5DS konfiguriert, wie es sein sollte.
Ich habe auch bereits mal eine re-registering des Dienstes durchgeführt; ohne Erfolg.
Der AnnounceFlags Eintrag in der Registry hat den Wert 5.
GPOs mit Zeitdienst Einstellungen sind keine mehr aktiv.
Hat jemand noch eine Idee?
Danke und Gruss, C3dy
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: 581303
Url: https://administrator.de/contentid/581303
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
19 Kommentare
Neuester Kommentar
Moin
Ja... Ich habe die Idee, dass Du vlt. nicht alle Einstellungen korrekt gesetzt hast. Es ist nicht nur der Wert für AnounceFlags zu konfigurieren.
vgl. https://support.microsoft.com/de-de/help/816042/how-to-configure-an-auth ...
und ich nehme immer einen anderen Zeitserver, weil time.windows.com bei mir ab und an auch mal Probleme bereitet.
Gruß
Ja... Ich habe die Idee, dass Du vlt. nicht alle Einstellungen korrekt gesetzt hast. Es ist nicht nur der Wert für AnounceFlags zu konfigurieren.
vgl. https://support.microsoft.com/de-de/help/816042/how-to-configure-an-auth ...
und ich nehme immer einen anderen Zeitserver, weil time.windows.com bei mir ab und an auch mal Probleme bereitet.
Gruß
Ist auch wenig zielführend den Winblows NTP zu verwenden und die Uhrzeit von der anderen Seite der Erde zu holen.
Sinnvoll sind immer lokale NTP Server wie z.B. TU Berlin oder Erlangen:
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Sinnvoll sind immer lokale NTP Server wie z.B. TU Berlin oder Erlangen:
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Hi Hubert
Vielen Dank für deine Antwort. Ich habe sämtliche Werte Im erwähnten Artikel durchgesehen und sie haben alle den richtigen Wert. Ausserdem habe ich den Server time.windows.com durch folgende Zeitserver ersetzt:
0.ch.pool.ntp.org
1.ch.pool.ntp.org
2.ch.pool.ntp.org
3.ch.pool.ntp.org
Leider hat sich dadurch an der Situation nichts geändert, ausser dass nun alle vier Peers den Status "Ausstehend" haben.
Ein resync bringt folgende Meldung:
Die Source Abfrage zeigt immer noch "Local CMOS Clock".
Gruss, Cedy
Vielen Dank für deine Antwort. Ich habe sämtliche Werte Im erwähnten Artikel durchgesehen und sie haben alle den richtigen Wert. Ausserdem habe ich den Server time.windows.com durch folgende Zeitserver ersetzt:
0.ch.pool.ntp.org
1.ch.pool.ntp.org
2.ch.pool.ntp.org
3.ch.pool.ntp.org
Leider hat sich dadurch an der Situation nichts geändert, ausser dass nun alle vier Peers den Status "Ausstehend" haben.
Ein resync bringt folgende Meldung:
Die Source Abfrage zeigt immer noch "Local CMOS Clock".
Gruss, Cedy
Firewall (lokal Winblows oder extern) die irgendwo UDP Port 123 (NTP Protokoll) blockiert ?!
- Windows Firewall wurde deaktiviert
- Kaspersky Security Service deaktiviert
- Watchguard Firewall Policy für externen NTP Zugriff ist geöffnet
- Kaspersky Security Service deaktiviert
- Watchguard Firewall Policy für externen NTP Zugriff ist geöffnet
Hast du wirklich eine Kaspersky Security Suite auf einen DC installiert?
Wer sowas macht, muss sich über Folgefehler nicht wundern.
Wer sowas macht, muss sich über Folgefehler nicht wundern.
Moin,
Gruß,
Dani
Wer sowas macht, muss sich über Folgefehler nicht wundern.
so ist es... deinstalliert die Software. Danach prüfe einmal, ob du auf de Watchguard entsprechend Request vom DC ausgehend zu einem der vier Server siehst. Ansonsten prüfe einmal per Ping, ob die Zeitserver erreichen kannst. Zudem schau einmal in das Ereignisprotokoll, ob dort Warnungen oder sogar Fehler bezüglich TimeService zu finden sind.Gruß,
Dani
Hi
Ja, habe ich wirklich. Und dies war auch die letzten 5-6 Jahre so. Wie gesagt die Kaspersky Dienste wurden deaktiviert und das Problem wurde dennoch nicht gelöst.
Und Ich sehe keine Verbindungsversuche über NTP auf dem Traffic Monitor der Firewall, auch keine blockierten. Ich denke aber solange die Source auf local CMOS clock steht, wird er auch nicht versuchen, sich die Zeit von nem externen Server zu holen.
Ja, habe ich wirklich. Und dies war auch die letzten 5-6 Jahre so. Wie gesagt die Kaspersky Dienste wurden deaktiviert und das Problem wurde dennoch nicht gelöst.
Und Ich sehe keine Verbindungsversuche über NTP auf dem Traffic Monitor der Firewall, auch keine blockierten. Ich denke aber solange die Source auf local CMOS clock steht, wird er auch nicht versuchen, sich die Zeit von nem externen Server zu holen.
Ereignisanzeige Quelle "Time-Service", ID 36:
Der Zeitdienst hat die Systemzeit für 86400 Sekunden nicht synchronisiert, weil keiner der Zeitdienstanbieter einen verwendbaren Zeitstempel bereitgestellt hat. Der Zeitdienst aktualisiert die lokale Systemzeit nur dann, wenn die Synchronisierung mit einer Zeitquelle möglich ist. Wenn das lokale System als Zeitserver für Clients konfiguriert ist, beendet es die Ankündigung als Zeitquelle für Clients. Der Zeitdienst versucht weiter, die Zeit mit den Zeitquellen zu synchronisieren. Überprüfen Sie, ob das Systemereignisprotokoll andere W32time-Ereignisse enthält, um weitere Details zu erhalten. Führen Sie "w32tm /resync" aus, um eine sofortige Zeitsynchronisierung zu erzwingen.
Der Zeitdienst hat die Systemzeit für 86400 Sekunden nicht synchronisiert, weil keiner der Zeitdienstanbieter einen verwendbaren Zeitstempel bereitgestellt hat. Der Zeitdienst aktualisiert die lokale Systemzeit nur dann, wenn die Synchronisierung mit einer Zeitquelle möglich ist. Wenn das lokale System als Zeitserver für Clients konfiguriert ist, beendet es die Ankündigung als Zeitquelle für Clients. Der Zeitdienst versucht weiter, die Zeit mit den Zeitquellen zu synchronisieren. Überprüfen Sie, ob das Systemereignisprotokoll andere W32time-Ereignisse enthält, um weitere Details zu erhalten. Führen Sie "w32tm /resync" aus, um eine sofortige Zeitsynchronisierung zu erzwingen.
Auch das manuelle Abrufen der Zeit vom NTP Server funktioniert:
Gruss, Cedy
Gruss, Cedy
Zitat von @D-Line:
Hi
Ja, habe ich wirklich. Und dies war auch die letzten 5-6 Jahre so. Wie gesagt die Kaspersky Dienste wurden deaktiviert und das Problem wurde dennoch nicht gelöst.
Bitte deinstalliere diese Suite, abgesehen von einer möglichen Verwaltungskonsole für zentral verwaltete AV-Lösungen auf Clients.Hi
Ja, habe ich wirklich. Und dies war auch die letzten 5-6 Jahre so. Wie gesagt die Kaspersky Dienste wurden deaktiviert und das Problem wurde dennoch nicht gelöst.
Und Ich sehe keine Verbindungsversuche über NTP auf dem Traffic Monitor der Firewall, auch keine blockierten. Ich denke aber solange die Source auf local CMOS clock steht, wird er auch nicht versuchen, sich die Zeit von nem externen Server zu holen.
@Dani hat es dir schon geschrieben. Check die Ereignislogs und überprüfe zusätzlich in der Registry die Einstellungen für den Zeitserver.Konfigurieren eines autorisierenden Zeitservers in Windows Server
Hi Goscho
Selbstverständlich läuft Kaspersky server security über die Verwaltungskonsole.
Den Eintrag vom Ereignislog habe ich oben gepostet, ebenso sind alle relevanten Registry Keys in Ordnung.
Selbstverständlich läuft Kaspersky server security über die Verwaltungskonsole.
Den Eintrag vom Ereignislog habe ich oben gepostet, ebenso sind alle relevanten Registry Keys in Ordnung.
Zitat von @D-Line:
Hi Goscho
Selbstverständlich läuft Kaspersky server security über die Verwaltungskonsole.
Nein - die Verwaltungskonsole kann bleiben.Hi Goscho
Selbstverständlich läuft Kaspersky server security über die Verwaltungskonsole.
Einen Echtzeit-AV-Scanner braucht kein DC - das gilt auch für den Defender in neueren Windows-Versionen.
Ich installiere nur auf RDS-Servern eine Endpoint Protection.
Hi Goscho
Trotz meiner Überzeugung, dass die Deinstallation von Kaspersky rein gar nichts an dem Problem ändern wird, habe ich es dennoch getan. Natürlich hat sich das Problem dadurch nicht gelöst. Nichts für ungut, aber wenn die Antiviren Software richtig konfiguriert ist, stellt diese überhaupt kein Problem dar. Über persönliche Methoden kann man streiten, muss man aber nicht.
Aber lassen wir das Thema mal beiseite.
Ich wüsste nun nicht, was ich noch machen soll. Mir sind die Ideen ausgegangen.
Gruss, Cedy
Trotz meiner Überzeugung, dass die Deinstallation von Kaspersky rein gar nichts an dem Problem ändern wird, habe ich es dennoch getan. Natürlich hat sich das Problem dadurch nicht gelöst. Nichts für ungut, aber wenn die Antiviren Software richtig konfiguriert ist, stellt diese überhaupt kein Problem dar. Über persönliche Methoden kann man streiten, muss man aber nicht.
Aber lassen wir das Thema mal beiseite.
Ich wüsste nun nicht, was ich noch machen soll. Mir sind die Ideen ausgegangen.
Gruss, Cedy
Hi Cedy,
lassen wir das Thema AV auf Servern mal sein, genau.
Hast du das hier schon gesehen:
https://community.spiceworks.com/topic/427550-domain-time-sync-with-exte ...
Wie sind die Netzwerkeinstellungen des Servers, nicht das dieser versehentlich in einem öffentlichen Netzwerk ist und die Firewall blockt alles.
lassen wir das Thema AV auf Servern mal sein, genau.
Hast du das hier schon gesehen:
https://community.spiceworks.com/topic/427550-domain-time-sync-with-exte ...
Wie sind die Netzwerkeinstellungen des Servers, nicht das dieser versehentlich in einem öffentlichen Netzwerk ist und die Firewall blockt alles.
Hi Goscho
Vielen Dank. Ja den verlinkten Beitrag habe ich schon bei mehreren Recherchen gefunden. Dort war ja das Ergebnis, dass der USV Dienst den UDP123 Port blockiert hatte. Ich habe die Netstat Abfrage gemacht, und der einzige Prozess der auf den Port 123 zugreift, ist der Windows Time Service.
Der Netzwerktyp steht auf "Domänennetzwerk" wie es sein sollte. Sicherheitshalber wurde aber die Windows Firewall vor 2 Tagen für alle Netzwerke deaktiviert.
Ich warte nun noch auf einen Lösungsvorschlag von nem Bekannten, der mal bei Microsoft tätig war. Falls das nicht hilft werde ich wohl einen bezahlten Case bei MS eröffnen müssen.
Wir sind in der Migrationsplanung der DCs auf Server 2016. Die neuen Server stehen praktisch schon. Jedoch weiss ich nicht ob es schlau ist, die Migration zu starten, solange auf der alten Umgebung noch nicht alles funktioniert.
Danke und gruss, Cedy
Vielen Dank. Ja den verlinkten Beitrag habe ich schon bei mehreren Recherchen gefunden. Dort war ja das Ergebnis, dass der USV Dienst den UDP123 Port blockiert hatte. Ich habe die Netstat Abfrage gemacht, und der einzige Prozess der auf den Port 123 zugreift, ist der Windows Time Service.
Der Netzwerktyp steht auf "Domänennetzwerk" wie es sein sollte. Sicherheitshalber wurde aber die Windows Firewall vor 2 Tagen für alle Netzwerke deaktiviert.
Ich warte nun noch auf einen Lösungsvorschlag von nem Bekannten, der mal bei Microsoft tätig war. Falls das nicht hilft werde ich wohl einen bezahlten Case bei MS eröffnen müssen.
Wir sind in der Migrationsplanung der DCs auf Server 2016. Die neuen Server stehen praktisch schon. Jedoch weiss ich nicht ob es schlau ist, die Migration zu starten, solange auf der alten Umgebung noch nicht alles funktioniert.
Danke und gruss, Cedy
Eventuell stimmt ja sonst noch ein Registry Eintrag nicht:
Moin,
Arbeite einmal den Beitrag Windows Time service tools and settings durch. Davor am Besten die Einstellungen sicherheitshalber vollständig zurücksetzen - siehe hier.
Gruß,
Dani
Auch das manuelle Abrufen der Zeit vom NTP Server funktioniert:
siehst du den Request deiner manuellen Abfrage dann auf der Firewall? Falls nicht, schaust du nämlich an der falschen Stelle bzw. hast die falsche Filter gesetzt. Ja, habe ich wirklich. Und dies war auch die letzten 5-6 Jahre so. Wie gesagt die Kaspersky Dienste wurden deaktiviert und das Problem wurde dennoch nicht gelöst. mäß
Es reicht schon fehlerhaftes Definition/Software Update von Hersteller der AV Lösung, um ungeahne Probleme auslösen zu können. Bestes und bekanntes Beispiel dürften die Upgrades von Windows 10, wo regelmäßig solche AV Lösungen Auslöser für Probleme sind. Wenn du mal Zeit hast, schau mal ins Microsoft Social Technet. Dort findest du regelmäßig Beiträge dazu...Jedoch weiss ich nicht ob es schlau ist, die Migration zu starten, solange auf der alten Umgebung noch nicht alles funktioniert.
Nein ist es nicht... gerade wenn der Zeitunterschied im Bereich von Minuten liegt. Ich warte nun noch auf einen Lösungsvorschlag von nem Bekannten, der mal bei Microsoft tätig war. Falls das nicht hilft werde ich wohl einen bezahlten Case bei MS eröffnen müssen.
Letzteres wird dir nichs bringen. Denn Windows Server 2008R2 ist sei Anfang des Jahres EoeS. Ha hilft nicht einmal mit Geld zu winken.Arbeite einmal den Beitrag Windows Time service tools and settings durch. Davor am Besten die Einstellungen sicherheitshalber vollständig zurücksetzen - siehe hier.
Gruß,
Dani
Hallo Dani
Vielen Dank für deine Antwort. Wir haben in der Zwischenzeit die Migration durchgeführt, da nach etlichen Lösungsversuchen keine Besserung in Sicht war.
Neu haben wir 3x DC Server 2016, einer davon PDC welcher die Zeit einwandfrei vom externen Zeitserver abfragt, und die anderen beiden holen sich die Zeit vom ersten. Alles funktioniert einwandfrei und die Zeitunterschiede sind im Milisekunden-Bereich.
Gruss, Cedy
Vielen Dank für deine Antwort. Wir haben in der Zwischenzeit die Migration durchgeführt, da nach etlichen Lösungsversuchen keine Besserung in Sicht war.
Neu haben wir 3x DC Server 2016, einer davon PDC welcher die Zeit einwandfrei vom externen Zeitserver abfragt, und die anderen beiden holen sich die Zeit vom ersten. Alles funktioniert einwandfrei und die Zeitunterschiede sind im Milisekunden-Bereich.
Gruss, Cedy
