Archive for the ‘NTP’ Category

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

14 Februar 2019

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

Phänomene mit QNAP NAS und großen Dateien, wie Reboots, Abbrüche usw – was das mit der Zeit zu tun hat

11 September 2015

Die primäre Aufgabe eines NAS ist eigentlich große Datenmengen zu speichern, wenn aber diese Aufgabe nicht erfüllt wird, stellt sich die Frage nach dem Sinn. Bei einem QNAP eines Kunden lief auf einmal die Sicherung nicht mehr durch. Es gab ständig Abbrüche nach ca. 32GB. Dabei wurde nur per SMB auf das NAS gesichert eine Funktion die davor über Jahre lief.

Allerdings wurde vor kurzem die NAS-Firmware aktualisiert, lag da das Problem? Tatsächlich gab es kurz darauf nochmal ein Update, allerdings deutete die Changelog nicht auf die Probleme. Also trotzdem das Update probiert aber leider keine Besserung.

Erstaunlich war, dass bei den Systemereignisprotokollen diese Meldung stand:

[Mirror Disk Volume: Drive 1 2] The file system is not clean. It is suggested that you go to [Storage Manager] to run "Check File System".

Der Versuch dieses Problem zu beheben klappte erst nach mehreren Anläufen. Gleichzeitig schien der NAS manchmal Nachts einen Neustart hinzulegen.

An einem Punkt war es sogar so schlimm, dass der Versuch das Dateisystem zu prüfen sofort mit den Meldungen

[Mirror Disk Volume: Drive 1 2] Examination failed(Cannot unmount disk by vs_refres).

und

[Mirror Disk Volume: Drive 1 2] Examination failed(Cannot unmount disk by smbd).

abgebrochen wurde. Diese Meldung blieben auch, obwohl das NAS vor dem Aufruf extra nochmal neu gebootet wurde und damit die Wahrscheinlichkeit recht gering war, dass ein Prozess den Vorgang blockiert.

Kurz davor die große Debugaktion zu starten, um dem Problem auf den Grund zu gehen, fiel mir noch eine Abweichung bei der NAS-Uhrzeit auf. OK einen Versuch ist es Wert. Es waren zwar nur drei Minuten aber für Rechner können das Ewigkeiten sein. Die Überlegung war: Neueste Firmware, damit Samba 4.x und damit Kerberos und deshalb pingelig mit den Zeiten.

Tatsächlich brachte dies dann die Lösung! Nun flutscht wieder alles.