Environment:Windows 10 Client wird installiert und mit direkter Internetverbindung "grundgepatcht".
Danach wird der ins AD integriert. Ab dem Zeitpunkt gibts keine Internetverbindung mehr.
Zeit kommt wie bei allen anderen Maschinen per NTP vom DC.
Verhalten:Win10 hat anscheinend mehrere Wege, die Systemzeit zu aktualisieren. Solange man direkt im Inet ist, geht das z.B. auch, wenn das w32time service deaktiviert ist.
Es wird offenbar auch hier eine last-known-sync-time vermerkt.
Nach dem "Internetverlust" will ab vergangener Zeit X (ca. 1 Tag) diese Non-NTP Synchronisation "back to the roots" und setzt die Systemzeit zurück auf die bekannte last-known-sync-time, ohne Rücksicht auf die Korrektheit.
Das ist mal das seltsame Verhalten, dessen Analyse und Troubleshooting mich zu folgendem Problem geführt hat:
W32tm Bug?!Das Windows Time Service w32time ist ja recht ordentlich dokumentiert, nicht schlecht zu konfigurieren und loggt zum Glück auch ausführlich.
Es ist wohlbekannt, daß es standardmäßig eine Beschränkung für maximale Abweichung gibt, ab der keine Synchronisation mehr durchgeführt wird.
Der entsprechende Parameter ist per Registry zu konfigurieren - hat aber bei Win10 keinen Effekt wie's ausschaut.
Aus dem Debug-Log:
151719 08:23:39.1520207s - ReadConfig: 'MaxAllowedPhaseOffset'=0xFFFFFFFF (2)
Registry Setting wurde gelesen151719 08:20:35.7940877s - Logging error: The time service has detected that the system time need to be changed by +85399 seconds. For security reasons, the time service will not change the system time by more than +4294967295 seconds. Verify that your time and time zone are correct, and that the time source dc1.domain.net,0x9 (ntp.m|0x9|0.0.0.0:123->10.0.1.1:123) is working properly.
Äääähh ... sorry - 4294967295 (=0xFFFFFFFF wie konfiguriert) IST GRÖSSER als 85399. dafuq?Hat wer a Idee?!
Ein paar Vorab-Antworten:
- tritt auch auf, wenn der Rechner NICHT in der Domain ist
- tritt auch bei einem Bekannten in dessen Domain auf
- Alle Vorversionen (7, 8.1, 2012R2) laufen normal
Anmeldung