[English]In Windows scheint es in letzter Zeit Probleme mit der Synchronisierung der Internetzeit zu geben. Nach einem Problem mit der automatischen Sommerzeitumstellung, Ende März 2020, noch ein kurzer Nachtrag mit Leserrückmeldungen zum Thema.
Anzeige
Ende März 2020 hatte ich im Artikel Windows 10: Problem bei der Sommerzeitumstellung 2020? ja über Probleme mancher Nutzer mit der automatischen Zeitumstellung durch Windows berichtet. Nun noch ein Nachtrag in Form zweier Nutzermeldungen, die mir ihrer Beobachtungen schilderten. Ich stelle die Beobachtungen einfach mal so ein, wie sie mir berichtet wurden.
Merkwürdiges Verhalten von Windows 7
Blog-Leser Wilfried L. arbeitet noch mit Windows 7 und ist durch den obigen Beitrag animiert worden, seine Beobachtungen mitzuteilen. Dazu schreibt er:
angesichts Ihres Beitrags zur Umstellung auf Sommerzeit und der vielen Kommentare will ich doch noch auf meine rätselhaften Beobachtungen zur eine Stunde nachgehenden Uhr bei Windows 7 (Home Premium SP1 32bit) hinweisen. Vielleicht besteht ein Zusammenhang.
Dank Armbanduhr verzichte ich eigentlich auf die Anzeige der Uhrzeit am Rechner, habe sie aber jetzt seit Dezember 2019 längere Zeit beobachtet, nachdem mir falsche Zeiten in Mail-Anzeigen aufgefallen waren. Manchmal wechselte die Zeit während einer Sitzung nach einer oder mehreren Stunden zur korrekten, auch mal nach einem Update von Windows, nach Neustart konnte sie, musste aber nicht, wieder falsch sein – kein System zu erkennen.
Zeitzone, Wechsel zwischen Sommer- und Winterzeit und Synchronisation über das Internet mit einem Zeitserver waren korrekt eingestellt. Wechsel des Zeitservers halfen nur vorübergehend.
Die Uhr ging im Winter eine Stunde nach, und dabei blieb es nach Beginn der Sommerzeit. Noch verrückter: nach Deaktivierung der Synchronisation mit einem Zeitserver und manueller Einstellung ging die Uhr am nächsten Tag gleich zwei Stunden nach, und dies wiederholte sich auch, wenn unter Windows zwischenzeitlich keine Internetverbindung bestand. Unter Linux (Dual Boot) ist die Zeit korrekt. Ein anderer, wenig genutzter, Rechner scheint nicht betroffen. Es muss also Windows auf dem Rechner verrückt spielen.
Bereits am 24.3.18 (einen Tag vor Umstellung auf Sommerzeit) musste ich so etwas beobachten bei einer fehlerhaften Timer-Aufnahme. Bei den Zeiteinstellungen wurde kurz darauf behauptet, die Zeit sei (planmäßig) am 25.3.18 um 8:19 synchronisiert worden, und "Jetzt aktualisieren" führte zur Meldung: "Fehler beim Ermitteln des Status der letzten Synchronisierung. Die Schnittstelle ist unbekannt." Daraufhin hatte ich den Zeitserver damals erfolgreich umgestellt von time.windows.com auf time.nist.gov.
Insgesamt scheinen die Zeitserver von Microsoft immer mal wieder Probleme zu bereiten.
Rückmeldung von Andi
Auch von Blog-Leser Andi O. erreichte mich eine Rückmeldung zum Thema Zeitsynchronisation unter Windows. Auch Andi bezieht sich auf meinen obigen Artikel und schreibt.
Anzeige
In den Kommentaren [zu obigem Artikel] hatte es mal geklappt, mal aber auch nicht. Das hab´ ich mir zum Anlass genommen, und mal geschaut, wie der Stand der Dinge in meiner [Windows 10] 1909 ist.
Ich habe den Starttyp des Zeitgebers eingestellt, den Rechner neugestartet, und dann versucht, mit der Eingabeaufforderung den Zeitgeber zu starten.
Anmerkung: Mein Konto für den Test war Administrator. Wenn der Starttyp des Zeitgebers auf "Deaktiviert" steht, dann kommt ´ne Fehlermeldung und der Zeitgeber verweigert seinen Dienst. Siehe Screenshot "Fehlermeldung Zeitgeber deaktiviert".
Bei "Manuell" sieht es anders aus. Man könnte denken, bei "Manuell" kann der Zeitgeber immer starten. Dem ist aber nicht ganz so. Öffne ich die Eingabeaufforderung über das Kontextmenü "Als Administrator", startet der Zeitgeber, siehe Screenshot "Zeitgeber manuell cmd als Administrator".
Öffne ich die Eingabeaufforderung aber normal, wird der Zeitgeber blockiert. Siehe Screenshot "Zeitgeber manuell cmd normal".
Bei der Windows 10 Version 1909 ist es also so, dass beim Zeitgeber der Starttyp "Manuell" von der Benutzerkontensteuerung blockiert wird. Synchronisierung geht also nur, wenn man sie selber manuell ausführt, oder wenn man einen lokalen Benutzer hat.
Ähnliche Artikel:
Windows 10: Problem bei der Sommerzeitumstellung 2020?
Windows 10: Probleme mit der Zeitsynchronisation – Teil 1
Windows 10: Probleme mit der Zeitsynchronisation – Teil 2
Anzeige
Beide Phänomene sind erklärbar.
Die erste Sache mit dem Win7 ist simpel: Linux nimmt die in der Hardware-Uhr gespeicherte Zeit standardmäßig als UTC an, Windows nimmt aber immer lokale Zeit an. Der Unterschied zwischen UTC und lokaler Zeit ist eben eine Stunde (MEZ) bzw. zwei Stunden (MESZ). Wenn man also zwischen Linux und Windows wechselt, ist es logisch, dass die Uhr immer verstellt wird bzw. es eine Weile dauert, bis sie korrigiert wird.
Will man das Hin- und Herschalten der Uhr verhindern, muss man entweder Linux so einstellen, dass es in der Hardware-Uhr ebenfalls lokale Zeit annimmt, oder Windows sagen, dass es UTC annehmen soll. Für beide Fälle gibt es ausreichend Anleitungen im Netz, unter anderem bei wiki.ubuntuusers.de (Suche nach Systemzeit).
Die zweite Sache ist ebenfalls logisch: Deaktivierte Dienste können nicht gestartet werden, von keinem Nutzer oder Admin. Ist einfach so, egal womit man versucht, den Dienst zu starten. Das MMC Snap-In services.msc bietet das Starten eines deaktivierten Dienstes deswegen auch gar nicht an (ausgegraut). Und zum anderen wird aus nachvollziehbaren Gründen einem Benutzer ohne Adminrechte das Starten von Diensten mit manuellem Starttyp verweigert – hier im Falle einer als Nutzer laufenden CMD. Fazit: Will man deaktivierte Dienste starten, braucht man zuerst Adminrechte, muss dann den Starttyp des Dienstes ändern und erst dann kann der Dienst gestartet werden. Das war übrigens schon immer so, selbst unter Win2k, und seit Vista sorgt die UAC für das Entfernen der Adminrechte auf fast allen Prozessen.
Das zweite Problem ließe sich übrigens ebenfalls lösen, indem man den Starttyp des w32time auf Automatisch (oder Automatisch Verzögert) stellt.
Ich hoffe, das bringt etwas Licht ins Dunkel.
Grüße
Absolut richtig. Die beiden "Fehlerbeschreibungen" sind ein Tiefpunkt dieses Blogs.
Auch wenn Corona – einfach eine Runde nach draußen spazieren gehen ….
Ich bin das Wochenende sogar über 150 km Rad gefahren. Wäre gestern das Wetter nicht so schlecht gewesen, wären es sicher über 200 geworden. Aber das unterschiedliche Zeitverhalten von Windows und Linux, genau wie dass man als Nicht-Administrator keine Dienste starten kann, schon garnicht deaktivierte Dienste, das sind eben Basics, die man Microsoft nicht in die Schuhe schieben kann.
@ 1ST1
Jetzt mach Dich mal ein bisschen locker!
1. Auch wenn Du solche Probleme offenbar per SSH von Deinem Fahrradcomputer aus bei Kilometer 144 lösen kannst, heißt das nicht, dass das jeder kann.
2. Auch wenn es hier manchmal MS-kritisch zugeht, so geht es dennoch in erster Linie darum Probleme zu lösen und nicht um Schuldzuweisungen.
3. Auch als erfahrener IT-ler hängt man manchmal viel zu lange an Problemen aus der Kategorie "Basics", man sieht den Wald vor lauter Bäumen nicht. Da sind gerade solche Artikel wie dieser hilfreich.
4. Auch wenn in vielen IT-Foren ein eher rauer Ton herrscht, so ist es doch gerade wohltuend, dass es hier in Günters Blog meist freundlich und konstruktiv zugeht. Es gibt keine "dummen Fragen". Lass es bitte dabei!
Kurze Rückmeldung von Blog-Leser Winfried:
"…Zeitzone, Wechsel zwischen Sommer- und Winterzeit und Synchronisation über das Internet mit einem Zeitserver waren korrekt eingestellt. Wechsel des Zeitservers halfen nur vorübergehend…"
Die Batterie auf dem Motherboard hast Du auch schon mal gewechselt? Ich hatte das Problem auch schon, und mit dem Wechsel der Batterie war es weg.
Ich habe noch den Kommentar von Dalai gelesen, der das Problem erklärt, somit meine Lösung für diesen Fall nicht zum Tragen kommt. Das mit der Batterie führt oder kann zu Problemen mit der Zeitanzeige führen.
>"Insgesamt scheinen die Zeitserver von Microsoft immer mal wieder Probleme zu bereiten."
Kann sein, aber ich aktualisiere über die PTB, von daher liegt der Fehler im OS. Wie kann es sein, dass hier Nutzer Detektive spielen müssen? Noch immer keine Antwort aus Redmond, im ernst Microsoft?
"Allzeit Atomzeit" (https://www.netzwelt.de/download/4687-allzeit-atomzeit.html)
Bei mir aktualisiert AzAz drei Minuten nach Systemstart im Hintergrund, hält diesen also nicht auf, und beseitigte dabei zuverlässig den Sommerzeitfehler.
Da sprechen Sie trotzdem ein sehr wichtiges Thema an. :-! Zeitsensitive Prozesse, wie Kerberos und Co., brauchen richtig gehende Zeiten in einem Netzwerk. Wusstet ihr z.B, dass die Fritz!Box, wenn DSL nicht da, eine Zeit vom 01.01.1970 ins interne Netz schickt, wenn man sie als Intranet-Zeitquelle angibt. Ich grübelte vor einiger Zeit eine kleine Ewigkeit, warum bei mir die Anmeldung an bestimmte Intranetzknoten nicht mehr funktionierte. Bis ich dann mal einen Blick auf die PC-Zeiten warf. Ich habe auch schon AVM danach gefragt. Nun versuche ich mir einen eigenen kleinen Zeitserver (batteriegepufferten) zusammenzubasteln, den ich einfach neben meinem Router in die Ecke stelle und als Zeitquelle im Intranet zur Verfügung stelle. Ich bin nämlich faul😁 und will so wenig wie möglich mit Logins und Passwörtern arbeiten… 🙄😁