22
Client übernimmt nicht die Zeit vom DC - Server 2016
Hallo liebe Leute,
ich habe ein Problem mit der Zeitsync in einer Domäne mit Windows 10 Clients.
Problem: Die Clients ziehen sich nicht die Zeit vom DC, sondern haben immer lokale Zeit, was natürlich zu Problemen im AD führt.
1. Meine Umgebung:
Windows Server 2016 als DC (Virtualisiert, HyperV) - als Zeitserver ist eingestellt: time.windows.com. Der DC dient auch als DNS / DHCP Server
Clients: Windows 10 1909 Pro, WSUS aktiviert, alle Updates soweit drauf
2. Was habe ich bereits gemacht:
- Sichergestellt, dass im DC die Zeit richtig abgerufen wird - laut w32tm /query /status passt alles - der DC synct mit time.windows.com
- Bei den Clients die üblichen Befehle gemacht:
z.B:
w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /unregister
w32tm /register
- Integrationsdienste Hyper V Zeit deaktiviert
- Server + Testclients neugestartet
- Hier im Forum geschaut und einige Lösungen probiert, welche leider nicht geholfen haben
- gewartet...
Leider ist bei den Clients immer noch Local CMOS Clock aktiviert.
3. Was kann ich hier noch kontrollieren bzw ändern?
P.S. GPO für die zeit ist nicht aktiviert - soweit ich weiß, braucht man die auch nicht für die Zeiteinstellungen der Clients.
Vielen Dank schon mal für eure Antworten
ich habe ein Problem mit der Zeitsync in einer Domäne mit Windows 10 Clients.
Problem: Die Clients ziehen sich nicht die Zeit vom DC, sondern haben immer lokale Zeit, was natürlich zu Problemen im AD führt.
1. Meine Umgebung:
Windows Server 2016 als DC (Virtualisiert, HyperV) - als Zeitserver ist eingestellt: time.windows.com. Der DC dient auch als DNS / DHCP Server
Clients: Windows 10 1909 Pro, WSUS aktiviert, alle Updates soweit drauf
2. Was habe ich bereits gemacht:
- Sichergestellt, dass im DC die Zeit richtig abgerufen wird - laut w32tm /query /status passt alles - der DC synct mit time.windows.com
- Bei den Clients die üblichen Befehle gemacht:
z.B:
w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /unregister
w32tm /register
- Integrationsdienste Hyper V Zeit deaktiviert
- Server + Testclients neugestartet
- Hier im Forum geschaut und einige Lösungen probiert, welche leider nicht geholfen haben
- gewartet...
Leider ist bei den Clients immer noch Local CMOS Clock aktiviert.
3. Was kann ich hier noch kontrollieren bzw ändern?
P.S. GPO für die zeit ist nicht aktiviert - soweit ich weiß, braucht man die auch nicht für die Zeiteinstellungen der Clients.
Vielen Dank schon mal für eure Antworten
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: 574078
Url: https://administrator.de/forum/client-uebernimmt-nicht-die-zeit-vom-dc-server-2016-574078.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
22 Kommentare
Neuester Kommentar
hallo,
Wie groß ist den die Abweichung der zeitnzwoschen den beiden?
Nur wenige Minuten? Dann sollte es eigentlich klappen, es sei den im BIOS ist eine Einstellung dafür.
Mehr als 30 Minuten?
Da kenne ich dass das der Client wegen des Stratum wert dem NTP Server nicht vertraut und daher die Zeit nicht übernimmt.
brammer
Wie groß ist den die Abweichung der zeitnzwoschen den beiden?
Nur wenige Minuten? Dann sollte es eigentlich klappen, es sei den im BIOS ist eine Einstellung dafür.
Mehr als 30 Minuten?
Da kenne ich dass das der Client wegen des Stratum wert dem NTP Server nicht vertraut und daher die Zeit nicht übernimmt.
brammer
Kommt auf den Client an - zwischen 2min und 15min. Es ist nur bei einem CLient das Problem aufgetreten, dass er sich nicht mehr anmelden konnte.
Um zukünftige Fehler zu verhindern will ich es halt richtig hinbekommen.
Ausgabe auf dem Client:
Als Quelle sollte dort halt der DC stehen... er mag aber nicht
Um zukünftige Fehler zu verhindern will ich es halt richtig hinbekommen.
Ausgabe auf dem Client:
C:\Windows\system32>w32tm /query /status
Sprungindikator: 3(nicht synchronisiert)
Stratum: 0 (nicht angegeben)
Präzision: -23 (119.209ns pro Tick)
Stammverzögerung: 0.0000000s
Stammabweichung: 0.0000000s
Referenz-ID: 0x00000000 (nicht angegeben)
Letzte erfolgr. Synchronisierungszeit: nicht angegeben
Quelle: Local CMOS Clock
Abrufintervall: 10 (1024s)Als Quelle sollte dort halt der DC stehen... er mag aber nicht
als Zeitserver ist eingestellt: time.windows.com
Keine besonders intelligente Idee wenn man in D oder der EU lebt und zum Uhrzeit ablesen einmal um den Erdball geht... Besser einen dieser NTP Server verwenden:https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Hab ich schon mal ausprobiert - bin halt jetzt bei dem hängen geblieben
Resultat war leider das gleiche.
Du hast aber recht - ich ändere es wieder zurück. Danke
Edit: ist jetzt bei ntp1.t-online.de
Resultat war leider das gleiche.
Du hast aber recht - ich ändere es wieder zurück. Danke
Edit: ist jetzt bei ntp1.t-online.de
Ich glaube ich komme der Lösung näher:
nachdem ich den Hinweis von Aqui umgesetzt hatte - keine Ahnung warum - löst der Client den Zeitserver richtig auf.
Das war vorher nicht der Fall
Wie bringe ich den Client nun dazu auf den PDC umzustellen?
Wie bringe ich den Client nun dazu auf den PDC umzustellen?
Die Befehle
führt er aus - leider ohne Änderung
nachdem ich den Hinweis von Aqui umgesetzt hatte - keine Ahnung warum - löst der Client den Zeitserver richtig auf.
Das war vorher nicht der Fall
Wie bringe ich den Client nun dazu auf den PDC umzustellen?
C:\WINDOWS\system32>w32tm /monitor
***.meine-domäne.de *** PDC ***[xxx.xxx.xxx.2:123]:
ICMP: 0ms Verzögerung
NTP: +0.0000000s Offset von ***.meine-domäne.de
RefID: ntp1.sul.t-online.de [194.125.134.196]
Stratum: 3
[Warnung]
Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht
korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von
NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet.
C:\WINDOWS\system32>w32tm /query /status
Sprungindikator: 3(nicht synchronisiert)
Stratum: 0 (nicht angegeben)
Präzision: -23 (119.209ns pro Tick)
Stammverzögerung: 0.0000000s
Stammabweichung: 0.0000000s
Referenz-ID: 0x00000000 (nicht angegeben)
Letzte erfolgr. Synchronisierungszeit: nicht angegeben
Quelle: Local CMOS Clock
Abrufintervall: 10 (1024s)Wie bringe ich den Client nun dazu auf den PDC umzustellen?
C:\WINDOWS\system32>w32tm /resync
Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet.
Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren.w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
Hallo,
Man kann das auch per GPO konfigurieren. Überprüfe sicherheitshalber, ob eine GPO konfiguriert ist mit rsop.msc auf dem Client.
Zum Thema: https://www.windowspro.de/wolfgang-sommergut/zeiteinstellungen-windows-d ...
Außerdem sollte Deine Firewall entsprechende Anfragen zulassen. Prüfe das am Server.
Domhier bedeutet, dass der Client sich den passenden DC sucht. Wenn Du mehrere DCs hast, solltest Du prüfen, ob deren Kerberos KDC noch einander vertrauen und die Replikation intakt ist.
Grüße
lcer
Man kann das auch per GPO konfigurieren. Überprüfe sicherheitshalber, ob eine GPO konfiguriert ist mit rsop.msc auf dem Client.
Zum Thema: https://www.windowspro.de/wolfgang-sommergut/zeiteinstellungen-windows-d ...
Außerdem sollte Deine Firewall entsprechende Anfragen zulassen. Prüfe das am Server.
Domhier bedeutet, dass der Client sich den passenden DC sucht. Wenn Du mehrere DCs hast, solltest Du prüfen, ob deren Kerberos KDC noch einander vertrauen und die Replikation intakt ist.
Grüße
lcer
Danke dir - GPO für die Zeit ist nicht konfiguriert, Firewall ist nicht das Problem. Auch mal komplett auf PDC und Client deaktiviert - ohne Verbesserung
Ich habe hier z.Z. nur einen DC (ist nur für 10 Clients)
Den DC findet er ja... er frägt ihn nur nicht ab
P.S. Bei meinem Switch, Netgear S3300 ruft er die Zeit erfolgreich vom Server ab...
NACHTRAG:
Wenn ich auf einem Client den Befehl net time ausführe, geht er auch zum DC
Ich habe hier z.Z. nur einen DC (ist nur für 10 Clients)
Den DC findet er ja... er frägt ihn nur nicht ab
P.S. Bei meinem Switch, Netgear S3300 ruft er die Zeit erfolgreich vom Server ab...
NACHTRAG:
Wenn ich auf einem Client den Befehl net time ausführe, geht er auch zum DC
C:\WINDOWS\system32>net time
Aktuelle Zeit auf \\***.meine-domäne.de ist 21.05.2020 16:56:13.
Der Befehl wurde erfolgreich ausgeführt.
Hallo,
https://docs.microsoft.com/de-de/windows-server/networking/windows-time- ...
überprüfe mal am Client manuell den registryschlüssel HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters ob type auf NT5DS steht.
Grüße
lcer
https://docs.microsoft.com/de-de/windows-server/networking/windows-time- ...
überprüfe mal am Client manuell den registryschlüssel HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters ob type auf NT5DS steht.
Grüße
lcer
Ja, alles korrekt auf NT5DS...
Dann prüf auf dem DC HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config AnnounceFlags
Grüße
lcer
Grüße
lcer
Dort steht der Wert 5
Was bedeutet der Wert hier? Da hatte ich bis jetzt noch nie nachgeschaut...
Was bedeutet der Wert hier? Da hatte ich bis jetzt noch nie nachgeschaut...
Zitat von @zer0g2224:
Dort steht der Wert 5
Was bedeutet der Wert hier? Da hatte ich bis jetzt noch nie nachgeschaut...
5 = 0x01 + 0x04Dort steht der Wert 5
Was bedeutet der Wert hier? Da hatte ich bis jetzt noch nie nachgeschaut...
Siehe link oben. Bedeutet „immer Zeitserver“ und „immer zuverlässiger Zeitserver“, also Dein DC sieht sich auch als Zeitserver. Alles passend.
Dann musst Du jetzt mal die Eventlogs vom Client und vom DC überprüfen.
Grüße
lcer
Ah ja, danke.
Da hab ich auch schon nachgeschaut:
Im Client Log zeigt sich eigentlich nur also Info:
Der Zeitanbieter 'VMICTimeProvider' hat angegeben, dass die aktuelle Hardware- und Betriebssystemumgebung nicht unterstützt wird und beendet wurde. Dieses Verhalten wird für VMICTimeProvider in Nicht-HyperV-Gastumgebungen erwartet. Dies kann auch das vom aktuellen Anbieter erwartete Verhalten in der aktuellen Betriebsumgebung sein.
Diese ist aber nicht als Warnung oder Fehler deklariert. Kommt auch einige mal vor
Da hab ich auch schon nachgeschaut:
Im Client Log zeigt sich eigentlich nur also Info:
Der Zeitanbieter 'VMICTimeProvider' hat angegeben, dass die aktuelle Hardware- und Betriebssystemumgebung nicht unterstützt wird und beendet wurde. Dieses Verhalten wird für VMICTimeProvider in Nicht-HyperV-Gastumgebungen erwartet. Dies kann auch das vom aktuellen Anbieter erwartete Verhalten in der aktuellen Betriebsumgebung sein.
Diese ist aber nicht als Warnung oder Fehler deklariert. Kommt auch einige mal vor
Ist der Client eine VM? Oder war der mal eine?
Grüße
lcer
Grüße
lcer
Das ist der Client - ist nicht virtualisiert. War er auch nie
NACHTRAG:
Das funktioniert auch - langsam verzweifle ich hier...
NACHTRAG:
C:\WINDOWS\system32>net time /set
Aktuelle Zeit auf \\*** ist 21.05.2020 19:04:38.
Die aktuelle lokale Zeit ist 21.05.2020 19:08:11.
Soll die Zeit des lokalen Computers mit
der Zeit auf \\*** übereinstimmen? (J/N) [J]: j
Der Befehl wurde erfolgreich ausgeführt.
hallo,
stimmen die Zeitzonen auf dem Client mit der des NTP Servers überein?
brammer
stimmen die Zeitzonen auf dem Client mit der des NTP Servers überein?
brammer
Zeitzonen sind soweit richtig gesetzt. Da ich nun den T-Online ntp1.t-online.de NTP auf dem Server nutze, sollte der auch immer die richtige Zeitzone "vorrätig" haben.
Ich hab mal andere Server kontolliert, 2012R2 und 2019er - dort ist alles korrekt. Die Clients bekommen ganz normal den PDC als Zeitgeber (das sind ganz andere Setups, welche nichts mit dieser hier zu tun haben)
Ich hab mal andere Server kontolliert, 2012R2 und 2019er - dort ist alles korrekt. Die Clients bekommen ganz normal den PDC als Zeitgeber (das sind ganz andere Setups, welche nichts mit dieser hier zu tun haben)
Da ich in einigen Foren über Probleme mit HP Switches gelesen habe, welche NTP Anfragen gefiltert haben, teste ich kurz meine Netgear Switches, aber da scheint auch alles durchzugehen - vom Client und zurück
w32tm /stripchart /computer:***.meine-domäne.de
***.meine-domäne.de wird verfolgt [xxx.xxx.xxx.2:123].
Es ist 21.05.2020 21:38:41.
21:38:41, d:+00.0018992s o:+00.1338062s [ * ]
21:38:43, d:+00.0008695s o:+00.1340625s [ * ]
21:38:45, d:+00.0009319s o:+00.1340580s [ * ]
21:38:47, d:+00.0007655s o:+00.1340018s [ * ]
21:38:49, d:+00.0008458s o:+00.1339814s [ * ]
21:38:51, d:+00.0007922s o:+00.1339909s [ * ]
Also ich denke, das Problem liegst nicht bei w32tm und Deine Einstellungen sind OK. Der Fehler wird woanders liegen.
Check Dein DNS.
Überprüfe, ob die Client-Computerkonten-Passwörter gültig sind.
Du schriebst von Problemen im AD wegen der Zeitsynchonisierung. Was für Probleme? Wurden die behoben?
Wieso wird eigentlich Dein Timeserver auf einen t-online.de Server aufgelöst? Was ist das für ein Konstrukt?
Grüße
lcer
Check Dein DNS.
Überprüfe, ob die Client-Computerkonten-Passwörter gültig sind.
Du schriebst von Problemen im AD wegen der Zeitsynchonisierung. Was für Probleme? Wurden die behoben?
Wieso wird eigentlich Dein Timeserver auf einen t-online.de Server aufgelöst? Was ist das für ein Konstrukt?
Grüße
lcer
Ersteinmal Danke für deine Hilfe, Icer00
DNS Check auf dem DC hatte ich als erstes gemacht - keine Probleme festgestellt. So sind auch keine Auffälligkeiten ersichtlich. Er löst eigentlich alles richtig auf - kann ich da noch was testen?
Wie im obigen Beitrag geschrieben kann ich mit: w32tm /stripchart /computer:***.meine-domäne.de problemlos die Zeit über den Client vom PDC abrufen, also sollte die DNS Auflösung funktionieren.
Die sollten noch gültig sein, Kennwörter müssen standardmäßig nicht geändert werden - Ansosnten könnte sich der Client auch nicht mehr am AD anmelden, oder?
DNS Check auf dem DC hatte ich als erstes gemacht - keine Probleme festgestellt. So sind auch keine Auffälligkeiten ersichtlich. Er löst eigentlich alles richtig auf - kann ich da noch was testen?
Wie im obigen Beitrag geschrieben kann ich mit: w32tm /stripchart /computer:***.meine-domäne.de problemlos die Zeit über den Client vom PDC abrufen, also sollte die DNS Auflösung funktionieren.
Zitat von @lcer00:
Du schriebst von Problemen im AD wegen der Zeitsynchonisierung. Was für Probleme? Wurden die behoben?
Ein Client war ca 2,5 Std weg von der richtigen Zeit -> er konnte sich nicht mehr anmelden. Mit einer neuen BIOS Batterie und der richtigen Zeit war das behoben. Dabei fiel mir halt auf, dass die Zeit generell nicht stimmt (auf den Clients)Du schriebst von Problemen im AD wegen der Zeitsynchonisierung. Was für Probleme? Wurden die behoben?
Zitat von @lcer00:
Wieso wird eigentlich Dein Timeserver auf einen t-online.de Server aufgelöst? Was ist das für ein Konstrukt?
Da ist doch nur der ntp1.t-online.de als NTP Server eingestellt - das gleiche wie 0.ntp pool.ntp.org oder time.windows.comWieso wird eigentlich Dein Timeserver auf einen t-online.de Server aufgelöst? Was ist das für ein Konstrukt?
Die sollten noch gültig sein, Kennwörter müssen standardmäßig nicht geändert werden - Ansosnten könnte sich der Client auch nicht mehr am AD anmelden, oder?
Zitat von @aqui:
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Unabhängig davon, ob wir wissen, wohin time.windows.com von uns aus aufgelöst wird - nach Europa oder Kuba.als Zeitserver ist eingestellt: time.windows.com
Keine besonders intelligente Idee wenn man in D oder der EU lebt und zum Uhrzeit ablesen einmal um den Erdball geht... Besser einen dieser NTP Server verwenden:https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Für Windows Domain Member niemals einen NTP-Server eintragen. Das bringt nur Ärger. Nur genau ein Computer im Forest sollte einen NTP-Server eingetragen bekommen. Und da ist der PDC-Emulator der Stamm-Domäne.
So, nachdem ich hier nicht mehr weitergekommen bin, habe ich mal die Zeit-Einstellungen via GPO verteilen wollen - gemäß dieser Anleitung:
https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaen ...
Auf dem DC klappts wieder problemlos, auf den Clients übernimmt er die Computer Config der GPO, führt sie aber anscheinend nicht aus oder ignoriert sie.
Es kommt immer wieder LOCAL CMOS Clock, beim Befeh w32tm /query /source
Weiß noch jemand Rat? Hab keine Lust auf mauelle Konfig der einzelnen Rechner
P.S. Soweit ich sehe funktioniert ALLES: DNS, DCDIAG ohne Probleme, kann alle Zeitserver pingen, Firewall kanns auch nicht sein.
Was habe ich übersehen? Bzw. kann ich noch testen.
Vielen dank
https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaen ...
Auf dem DC klappts wieder problemlos, auf den Clients übernimmt er die Computer Config der GPO, führt sie aber anscheinend nicht aus oder ignoriert sie.
Es kommt immer wieder LOCAL CMOS Clock, beim Befeh w32tm /query /source
Weiß noch jemand Rat? Hab keine Lust auf mauelle Konfig der einzelnen Rechner
P.S. Soweit ich sehe funktioniert ALLES: DNS, DCDIAG ohne Probleme, kann alle Zeitserver pingen, Firewall kanns auch nicht sein.
Was habe ich übersehen? Bzw. kann ich noch testen.
Vielen dank
