Warum kann man in Windows 10 das Datum nicht mehr per Eingabeaufforderung ändern?


Die Krux mit der Zeit bei Windows 10 oder warum zum Teufel kann ich meinem Windows nicht so einfach das Datum vorgeben, das ich möchte? Ach waren das noch schöne DOS-Zeiten. Man gab DATE ein, setzte das gewünschte Datum, startete seine Anwendung und konnte gemütlich arbeiten.

Vista brachte mit der UAC schon einige Änderungen mit, dass man zwingend Adminrechte zum Datumändern braucht usw. Aber Windows 10 in der aktuellen Ausführung (mind. seit 1607) treibt die Sache nochmal auf die Spitze! Dort gibt es sogenannte sichere Zeiten. Wehe, man befindet sich nicht in der “sicheren” Zeit, dann gibt es ganz schnell Chaos, Windows greift ein und stellt die richtige Zeit wieder her.

Im Grunde läuft die Geschichte so, man macht eine Admin-Eingabeaufforderung auf, gibt

DATE 10.10.18

ein, prüft diese mittels

DATE /t

bekommt meist das korrekte Datum angezeigt. Aber wehe die Zeitgötter sind gegen einen, dann startet man seine Anwendung mit der man in der Vergangenheit arbeiten möchte, doch unversehens hat man wieder die korrekte aktuelle Zeit.

Profis kommen dann und sagen: Ja man muss ja auch den Windows-Zeitgeberdienst W32Time ausschalten, also führt man noch ein

SC.EXE stop w32time

aus und probiert danach nochmal sein Glück. Klappt meist nicht, wenn definitiv nicht, liegt es vielleicht daran dass man sich in einer virtuellen Maschine befindet, da muss man z. B. noch den Hyper-V-Dienst für Zeitsynchronisierung ausschalten, also

SC.EXE stop vmictimesync

Vielleicht klappt es nun aber die meisten werden feststellen, Windows ist so schnell zurück bei der alten Zeit so schnell kann man manchmal gar nicht schauen.

Für die Behandlung von Daten seien hier noch der Vollständigkeit halber der Aufruf der GUI für die Datumsänderung genannt:

timedate.cpl

Und um in Powershell das Datum zu ändern, ohne die aktuelle Uhrzeit zu verlieren verwendet man:

set-Date "10.10.2018 $((Get-Date).ToLongTimeString())"

Die Abfrage der Zeitdienste in Windows sind mittels

get-service *time*

zu erhalten, wo W32Time, TimeBrokerSvc und bei Hyper-V VMs VMIcTimeSync auftauchen. Wobei mir die Rolle des TimeBrokerSync noch nicht klar ist.

Aber nun weiter im Thema. Um die Zufälligkeiten der Datumsrückstellung besser in den Griff zu bekommen, muss man Windows abgewöhnen bei der Kommunikation mit dem Internet SSL-Zertifikate zur Berechnung der Uhrzeit herzunehmen. Das Prinzip nennt sich Secure Time Seed of High Confidence (STSHC). Dabei handelt es sich nicht um ein typisches Microsoft Marketingbuzzword sondern eher um eine interne, und wie so oft, offiziell undokumentierte Sache. Einzig ein MS-Angestellter hat über das Prinzip ein paar Dinge geschrieben: https://blogs.msdn.microsoft.com/w32time/2016/09/28/secure-time-seeding-improving-time-keeping-in-windows/.

Kurz gesagt: Mit jeder verschlüsselten Kommunikation ins Internet kann Windows die Zeit korrigieren. Und das findet in Windows 10 mehr als häufig statt und erklärt auch das erratische Verhalten, welches man meist beobachten kann.

Man kann die aktuelle Einstellung durch folgende Zeile abfragen:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData

wird der Wert 1 geliefert ist die Zeitkorrektur durch SSL-Zertifikate aktiv, bei 0 ist sie ausgeschaltet.

Aktivieren (Vorgabe) kann man das Verhalten mit

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 1

und mit

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0

abschalten.

Läuft der W32Time-Dienst und aktiviert man das Logging z. B. mittels

w32tm /debug /enable /file:C:\temp\w32tm.log /entries:0-300 /size:1000000

dann findet man in w32tm.log solche Eintragungen, wenn STSHC eingreift und die Zeit umstellt:

152670 12:34:36.6488208s – Setting the system time because it is outside the secure time limits.
152670 12:34:36.6488464s -  Current system time:  12:34:36.648 10/10/2018
152670 12:34:36.6488666s -  Target system time:  12:34:36.455 2/11/2019
152712 12:34:36.4608379s -  (AUDIT) Time Jump of 3628799 seconds.
152712 12:34:36.4608764s – ClockDispln Discipline: *SET*SECURE*TIME*

Bei dem STSHC-Komplex sei auch noch dieser Registry Key genannt:

Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits\

der da die Properties

SecureTimeConfidence : 7
SecureTimeEstimated  : 131945739321311682
SecureTimeHigh       : 131945775321311682
SecureTimeLow        : 131945703321311682
SecureTimeTickCount  : 29139718

auflistet. High, Low und Estimated sind wieder interessant und sind zwei Stunden auseinander. Man kann die Werte in normale DateTime-Variablen konvertieren, muss aber noch 1600 dazu addieren, um aktuelle Werte zu erhalten. Die Vorgehensweise sieht so aus

([DateTime](Get-ItemProperty HKLM:\System\CurrentControlSet\Services\W32Time\SecureTimeLimits\ -Name SecureTimeHigh).securetimehigh).AddYears(1600)

und ist hier beschrieben: http://byronwright.blogspot.com/2016/03/windows-10-time-synchronization-and.html.

Wenn man nun die SecureTimeLimits aus der Registry hernimmt, dann scheint immer gegen diese Verglichen zu werden, ob die Uhrzeit angepasst werden muss. Ist die aktuelle Uhrzeit des Rechners also außerhalb von Low und High wird sie auf Estimated gesetzt. Doch wie und wann werden High und Low gesetzt? Scheinbar beim Rauf- und Runterfahren des Rechners: http://byronwright.blogspot.com/2016/03/more-on-secure-time-for-windows-10.html. Wobei ich dies bisher noch nicht getestet habe.

Interessante Geschichte was mit der Zeitgebung durch SSL-Zertifikate passieren kann: https://www.reddit.com/r/sysadmin/comments/61o8p0/system_time_
jumping_back_on_windows_10_caused_by/
. Daraufhin gab es auch noch einen offiziellen KB-Artikel: https://support.microsoft.com/en-us/help/3160312/a-computer-that-is-running-windows-10-version-1511-reverts-to-a-previo.

Das ist sicherlich noch nicht alles was man zum Thema wissen müsste und sollte aber zumindest ein Anfang…

Ach, noch ein Dokument wegen Zeitsynckorrektheit von MS: http://windocs.blob.core.windows.net/windocs/WindowsTimeSyncAccuracy_Addendum.pdf, der Verweis auf den wichtigsten Zeit-Blog von MS: https://blogs.msdn.microsoft.com/w32time/ und noch die aktuelle MSDN-Doku zum Windows Zeitgeber Dienst: https://docs.microsoft.com/de-de/windows-server/networking/windows-time-service/windows-time-service-top.

Werbeanzeigen

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s


%d Bloggern gefällt das: