Hat Win10 Probleme mit dem Zeitdienst?

Mitglied: DerWoWusste

DerWoWusste (Level 5) - Jetzt verbinden

07.03.2016, aktualisiert 12:47 Uhr, 7374 Aufrufe, 55 Kommentare, 2 Danke

Hi.

Ich frage mich, ob noch andere dies Problem beobachten:
Wir haben netzwerkweit von Win8.1 auf 10 migriert. Alles läuft gut, bis auf die Zeitsynchronisation mit dem DC.
Seltsamerweise betrifft dies ausschließlich Rechner, die neue CPUs (Intel Skylake) haben (verschiedene Mainboards, verschiedene Typen [i3/i5]).
Diese werden an Tag X installiert/upgegradet und ihr Datum fällt alle paar Tage zu unterschiedlichsten Uhrzeiten ohne erkennbaren Anlass auf genau diesen Tag X zurück, immer die selbe Uhrzeit.
Höchst mysteriös. Ich habe nun bei allen den Dienst "Windows-Zeitgeber" deaktivieren müssen und stattdessen ein Skript
net time /set /y
per Taskplaner alle paar Stunden laufen, seitdem gibt es keine Probleme mehr.

Hat noch irgendjemand davon gehört?

Wie gesagt, alle haben Skylake CPUs. Die IT hatte Win10 seit einem halben Jahr abteilungsweit getestet, nie gab es jemals auch nur ein Zeitproblem. Keiner von Ihnen hat Skylake.
55 Antworten
Mitglied: Stephan601
07.03.2016 um 14:11 Uhr
Hi!

Ja, ich kann das Problem bestätigen. Gleiches Phänomen, Skylake CPU setzt sich auf Installationsdatum zurück. Steht bei mir aber weiter hinten auf der ToDo-Liste, deswegen hab ich da noch keinen Lösungsansatz.
Welches OS fahrt ihr auf dem DC?
Bitte warten ..
Mitglied: DerWoWusste
07.03.2016 um 14:19 Uhr
Hi.

Cool, servus Leidensgenosse!
Das OS des DCs spielt keine Geige, wie ich schon feststellen konnte (hier Server 2008). Ich habe hier auch manuell einen Zeitserver eingetragen (Linux NTP-Server), selbes Problem.
Bitte warten ..
Mitglied: Stephan601
08.03.2016 um 07:51 Uhr
Moin,

na gut, dann würde ich den DC ausklammern. Das Kuriose ist, ich hab identische Hardware verbaut, hänge (natürlich) am selben DC, fahre aber das aktuelle Insider Preview -> keine Probleme. Der einzige Unterschied ist: auf meiner Maschine hab ich über Win7 drüber gebügelt und beim betroffenen Kollegen nen Clean-Install gemacht.

Am Donnerstag ist der Kollege außer Haus, da werd ich mich der Problematik intensiver annehmen.
Bitte warten ..
Mitglied: DerWoWusste
08.03.2016 um 09:26 Uhr
Bei uns tritt es sowohl bei Upgrades als auch bei Neuinstallationen auf. Bislang 5 PCs von den ca. 15 mit Skylake, aber nun werden keine weiteren mehr hinzukommen, da der Zeitgeber deaktiviert ist.
Bitte warten ..
Mitglied: colinardo
08.03.2016, aktualisiert um 23:14 Uhr
Hallo zusammen,
ich werfe mal das neue Feature Speed-Shift in Zusammenhang mit dem Threshold 2 Update und den neuen Skylake-Prozessoren in den Raum, bei welchem der Prozessor die Taktrate selbst an die aktuelle Last anpasst und nicht mehr das OS.

http://winfuture.de/news,89736.html
http://www.chip.de/news/Windows-Update-macht-PC-schneller-Wegen-dieser- ...

Könnte durchaus damit im Zusammenhang stehen, vermutlich noch ein fieser Bug in diesem Feature. Würde mich nicht wundern wenn das noch so neu ist.

Grüße Uwe
Bitte warten ..
Mitglied: Stephan601
17.03.2016 um 11:00 Uhr
Huch, mein Feedback fast vergessen....

Schnödes "aus Domäne, in Domäne" hat geholfen. Alle geschilderten Probleme hatten sich damit erledigt.
Bitte warten ..
Mitglied: DerWoWusste
17.03.2016 um 12:14 Uhr
Stephan, bei wie vielen Rechnern hat das denn geholfen und wie lange hilft es schon?
Bei uns kam dieses Zurückstellen ja auch manchmal tagelang nicht vor und dann wieder.
Bitte warten ..
Mitglied: Stephan601
17.03.2016 um 13:12 Uhr
Grüße!
Ich hatte das Problem nur bei einem Kollegen. Jeden Morgen wenn er seine Maschine gestartet hat, setzte sich das Datum auf das Installationsdatum zurück. Nun ist seit einer Woche Ruhe, die Maschine holt sich das richtige Datum und die richtige Zeit.
Bitte warten ..
Mitglied: DerWoWusste
17.03.2016 um 13:15 Uhr
Wünsche viel Glück, dass es so bleibt, habe aber Zweifel :-) face-smile
Bitte warten ..
Mitglied: Kuemmel
12.04.2016 um 17:30 Uhr
Sachen gibt's :-) face-smile:
clock - Klicke auf das Bild, um es zu vergrößern

Windows 10 Pro x64
aktuellster Updatestand
Bitte warten ..
Mitglied: colinardo
12.04.2016, aktualisiert um 17:53 Uhr
Zitat von @Kuemmel:

Sachen gibt's :-) face-smile:


Windows 10 Pro x64
aktuellster Updatestand
Zeitzone zufällig auf GMT ? :-) face-smile käme hin mit den zwei Stunden zur CEST
Oder was soll uns der Screenshot sagen?
Bitte warten ..
Mitglied: Kuemmel
12.04.2016 um 18:01 Uhr
Nö passt alles. War jetzt schon ein paar Mal auf unterschiedlichen Systemen mit Skylake.
Bitte warten ..
Mitglied: DerWoWusste
12.04.2016 um 18:35 Uhr
Aber Datum passte?
Bitte warten ..
Mitglied: Kuemmel
12.04.2016 um 18:44 Uhr
Jop.
Bitte warten ..
Mitglied: DerWoWusste
13.04.2016, aktualisiert um 08:12 Uhr
Da wir nun die Zeit anders setzen, verfolge ich das Problem nicht weiter, möchte aber noch einmal zusammenfassen:
-Skylake scheint beteiligt (nicht gesichert, da ein anderer Leidensgenosse hier im Forum auch auf doppelte Rückfrage nicht angeben kann/mag welche CPUs die PCs bei ihm haben)
-die Zeit scheint sich bei einigen auf das Installationsdatum zurückzustellen, sogar immer auf die Sekunde genau auf die selbe Zeit
-bei anderen (Kümmel) nur um Stunden, aber zumindest stimmt das Datum
-die Häufigkeit, mit der das auftritt ist scheinbar regellos (hatten hier ein System, das von heute auf morgen ständig (alle 5 Minuten) die Uhrzeit um Wochen zurückgestellt hat)
-bei zumindet mir hat es eindeutig mit dem Dienst Windows-Zeitgeber zu tun (wenn deaktiviert, tritt es nie auf)

In toto ein ziemlich rätselhaftes Phänomen. Ich werde weiter aktualisieren, wenn ich was finde.
Bitte warten ..
Mitglied: pluto13
20.04.2016 um 10:47 Uhr
Hallo zusammen!

Wir hatten/ haben hier im Unternehmen das selbe Problem.
Eine Lösung bei allen Rechnern ist bisher das aktualisieren des BIOS.
Wir setzen größtenteils Lenovo-Desktops ein - die CPU Generation ist in allen fällen Haswell, nicht Skylake.

Model: ThinkCentre M83
SKU: LENOVO_MT_10BE
Memory: 8 GB DDR3
Processor: Intel Core i5-4590 CPU @ 3.30GHz


Gruß,
Pluto13
Bitte warten ..
Mitglied: colinardo
20.04.2016, aktualisiert um 11:40 Uhr
So, hatte in den letzten Tagen mal Skylake-Hardware zum Test hier und habe einige Tests gefahren (ASUS Z170 Board mit Intel® Core™ i7-6700HQ).

Fazit:
Wie ich in meinem letzten Post vermutet habe liegt, es mit ziemlicher Sicherheit am neuen Speed-Shift-Feature im Zusammenspiel mit Windows 10 bei dem Ende 2015 Speedshift als neues OS-Feature eingeführt wurde.
Ich habe diverse Neuinstallationen mit unterschiedlichsten BIOS-Settings im Bereich CPU durchgeführt.
Gerade weil das Problem nur mit dem Build 1511 auftritt bestätigt das meinen Verdacht nur noch mehr.

Schuld sind die Speed-Step bzw. C-State Settings der CPU, die ja das Heruntertakten der CPU im Betrieb regeln und zum Stromsparen eingesetzt werden.

Genau da setzt das neue Feature von Windows 10 und Intel an, wobei hier dann der Prozessor selber seine Taktrate viel schneller hoch und runter regeln kann als es das OS könnte.

Bei aktivierten C-States wurde nachvollziehbar die Uhrzeit in unregelmäßigen Zeiträumen verstellt. Mal nur ein paar Stunden und mal auf das Installationsdatum, so wie ihr es oben auch schon beschrieben habt. Die meisten "größeren" Zeitänderungen fanden dabei beim Start und Herunterfahren statt. Für die Aufzeichnung habe ich ein automatisiertes Powershell-Skript verwendet das Useraktivität simuliert und in Abständen den Rechner auch mal neu startet und Zeitunterschiede registriert.
Nach Deaktivierung der C-States und folgender Neuinstallation war keinerlei Änderung der Zeit mehr zu beobachten.

Somit komme ich persönlich hier zu dem Schluss das hier das SpeedShift oder BIOS-Firmwares an irgendeiner Stelle wohl noch verbuggt sein müssen, wenn das so offensichtlich nachvollzogen werden kann.

Hoffe das bringt etwas Licht ins Dunkel.

Grüße Uwe
Bitte warten ..
Mitglied: DerWoWusste
20.04.2016 um 11:44 Uhr
Großen Dank an Dich!
Nun müssen wir noch dafür sorgen, dass sich etwas ändert, also Microsoft/Mainbaordhersteller informieren.
Ich habe hier keine so schön belastbare Testreihe wie Du - wenn Du mir Dein Skript geben würdest, könnte ich das nachstellen und würde das auch weiterleiten (evtl. samt Skript).
Bitte warten ..
Mitglied: colinardo
20.04.2016 um 11:54 Uhr
Die Info habe ich schon vorsorglich an die entsprechenden Stellen weitergeleitet ;-) face-wink, also mal abwarten.
Bitte warten ..
Mitglied: foxdevilswild
25.04.2016 um 16:59 Uhr
Hi Zusammen,

habe nach längerer Zeit mal wieder nach diesem Problem gegoogelt, welches ich im Januar auch hatte und das mich viel Zeit und Nerven gekostet hat. Damals kam es mir so vor als hätte nur ich das Problem, anscheinend aber wohl doch nicht. Ich hatte das Problem mit einem gebrauchten Lenovo T520 (genauen CPU-Typ habe ich nicht im Kopf, bin unterwegs), aber kein brandneues Teil. Der Client ist Teil meiner Domäne und zieht somit die Zeit per NTP. Die Uhrzeit hat sich auch da nach kurzer Zeit immer wieder auf das Installationsdatum zurück gestellt.

Ich bezweifle, dass es ein reines BIOS/Hardware-Problem ist, denn in meinem Fall habe ich klar den w32tm als Zeitrücksteller identifiziert. Als ich den deaktiviert hatte, blieb die Zeit aktuell, abgesehen von den sich akkumulierenden Abweichungen. Also genau wie bei DeWoWusste. Am NTP-Server lag es auch nicht, denn mehrere andere Win-10-Clients des selben Builds (aber anderer Hardware) ziehen sich die Zeit von dort ohne Probleme. Insofern möchte ich einen Hardware-Bezug auch nicht leugnen.

Ich habe dann das Logging von dem Dienst aktiviert und im Logfile war schön zu sehen, dass sich der w32tm zunächst 2-3 Mal problemlos die Zeit von meinem internen Zeitserver zieht. Dann, plötzlich und ohne erkennbaren Grund, tauchte im Logfile eine Meldung der Art "Secure Time not trusted" oder so ähnlich auf (habe leider kein Logfile aufgehoben). Dann stellt der w32tm die Zeit auf den Installationszeitpunkt zurück. Danach findet er dann (zu Recht) die Differenz zu groß und macht keinen Synch mehr. Stellt man die Zeit wieder manuell, blieb sie mal länger mal kürzer stabil, um dann wieder zurück zu springen.

Ich habe das Problem umgangen, indem ich den alternativen Zeitdienst von Meinberg installiert habe. Keine echte Lösung, aber ich war es einfach leid. Bin daher der Meinung, es ist ein Bug im w32tm, der ggfs. nur unter bestimmten Randbedingungen zum Tragen kommt.
Bitte warten ..
Mitglied: DerWoWusste
25.04.2016 um 17:39 Uhr
Sehr interessant. Logging für w32time: https://support.microsoft.com/en-us/kb/816043 - darauf war ich leider nicht gekommen.
Wenn Du nocheinmal so ein Logfile hättest, bitte hier reinstellen.

PS: für andere, die evtl. den T520 von Lenovo nicht kennen - das ist kein Skylake.
Bitte warten ..
Mitglied: foxdevilswild
26.04.2016 um 17:03 Uhr
Nee, der KB-Artikel ist zu kompliziert, bzw. so habe ich es nicht gemacht. Logging war vielleicht das falsche Wort, eher Debuggng. Einfach so (bei laufendem Dienst):

w32tm /debug /enable /file:c:\Temp\w32time.log /size:10000000 /entries:0-116

Dann 'ne Weile laufen lassen bis der Rücksprung passiert ist und dann ausschalten mit w32tm /debug /disable
Ich habe nachgesehen und kein Logfile mehr gefunden, leider. Dann dachte ich mir gestern Abend, ich stelle es nochmal rasch nach und habe das Meinberg-NTP-Paket deaktiviert und w32tm wieder angemacht. Tja, Pustekuchen, der Fehler tritt nicht mehr auf (was an sich ja Grund zur Freude ist). Allerdings habe ich wegen einigen anderen Problemen mit dieser Büchse zwischendrin alles nochmal neu aufgesetzt inkl. BIOS-Update, Wechsel von Legacy-Boot zu UEFI-Boot und natürlich Patches. Könnte also doch gut sein, dass es am BIOS liegt, wie andere Beiträge im Threat schon meinten.
Der Vollständigkeit halber: die CPU ist ein i5-2540@2.60GHz und das Win10 ist 1511 Build 10586.218 mit aktuellen Patches.

Hoffe, Ihr kommt mit dem Thema weiter, aber ich bin wohl keine Hilfe mehr.
Bitte warten ..
Mitglied: MrTentacleGuy
27.04.2016 um 16:07 Uhr
Hi Folks, das Problem nervt mich schon seit Sept 2015!

Hab eigentlich gehofft es hätte sich evtl. mit aktuellen Bios Updates oder einem aktuellen Win10 Build gelöst, aber das war wohl Wunschdenken.

Habe alle erdenklichen Fehlerquellen getestet und schiebe es derzeit auf das verbaute Mainboard (siehe unten) und dessen Bios bzw. Chipsatz! Der Prozessor alleine kann es nicht sein, da das Zeitproblem (Rückstellen auf Tag der Clean Install von Windows 10) auch auftrat als ich einen i5 verwendete (Sandy und Ivy haben also das gleiche Problem).

Der einzige Workaround ist bislang tatsächlich den W32Time (Windows Zeitgeber) Dienst abzuschalten. Das kann allerdings in der Domain zu Sicherheitsproblemen (Kerberos) bei zu großer Differenz zum DC führen, aber das ist ein anderes Problem.

Specs meiner 3 Testmaschinen:

Core I7 3770K
MB Asus Sabertooth Z77 mit Bios V2104 (derzeit aktuell) American Megatrends V.2.10.1208
Windows 10 Pro Build 1511 64bit

Sollte jemand die Lösung mit einem funktionierenden TimeSync mit dem DC finden (die Skript Variante schließe ich aus, es sollte der W32Time Dienst sein) mach ich 3 Saltos aus dem Stand vor Freude....und dann die Weltherrschaft ;-) face-wink

Ach ja, ich kann noch festhalten, das es nicht zwingend das Installationsdatum ist auf das er zurückspringt, vielmehr ist es das Datum/Uhrzeit als der Client das letzte Update über den jeweiligen Zeitserver (meist time.windows.com) aus dem Internet bekommen hat. Läuft der Client nämlich mit Zeitserver aus dem Internet (dabei darf er nicht Zeitgleich in einer Domain hängen) und macht einen Timesync, dann setzt er beim anmelden an der Domain die Uhr zukünftig auf dieses Datum/Uhrzeit.

Ich LEIDE mit Euch! MTG (MrTentacleGuy)
Bitte warten ..
Mitglied: DerWoWusste
27.04.2016, aktualisiert um 16:20 Uhr
Hi.

die Skript Variante schließe ich aus, es sollte der W32Time Dienst sein
Warum schließt Du diese aus? Ich lebe mit der einen Zeile in einem Scheduled Task sehr gut:

Bitte warten ..
Mitglied: MrTentacleGuy
27.04.2016 um 17:05 Uhr
Servus!

Ich hatte die Skript Variante im Einsatz und musste feststellen das ich eine sehr hohe Ausführfrequenz des Skripts einstellen musste um zu 100% auszuschließen das die Uhrzeit nicht doch für ein paar Minuten umspringt. Ich arbeite in einer sehr zeitkritischen Umgebung und da wäre es fatal. Die Rechner in meiner Umgebung sollten im 5-10 Sek Bereich synchron sein.

Es ist allerdings schon ein paar Monate her das ich die "net time" Variante am Start hatte, bin mir grad nicht sicher ob die funktioniert wenn der W32Time Dienst deaktiviert ist. Bei deaktiviertem W32Time Dienst müsste die Frequenz natürlich nicht ganz so hoch sein da hier nichts mal eben um ein paar Tage verspringt ;-) face-wink

Ich habe das Problem hier gelöst, indem ich die 3 Rechner durch andere mit einem anderen Mainboard Typ ersetzt habe. Allerdings wäre es schön die anderen Geräte wieder ihrer urprünglichen Aufgabe in der Domain zuzuführen, zudem bin ich ein Freund von funktionierenden Betriebssystemen bzw. Boardmitteln (ja, ich weiß, "net time" ist auch ein Boardmittel ;-) face-wink ). Meine Philosophie ist einfach das Produkte (Betriebssysteme und Hardware) so funktionieren sollten, wie es originär vom Hersteller erdacht war (hier: Timesync über DC in 0815 standard Konfiguration wie schon seit Jahren). Da das aber bei unserem konkreten Problem wohl nicht so leicht durch Admins zu lösen ist, hoffe ich auf einen fix vom OS Hersteller oder eben dem Mainboardhersteller.

Ausser meiner Grundphilosophie und dem im 1. und 2. Absatz kurz skizzierten Problem spricht natürlich nichts gegen die "net time" Variante, die ist schlank und zweckmäßig. Ich geh nur gern Sachen auf den Grund und hoffe jemand findet des Pudels kern ;-) face-wink.

Gruß MTG
Bitte warten ..
Mitglied: DerWoWusste
27.04.2016 um 17:21 Uhr
Net time funktioniert ohne den Dienst, ein oder zwei Mal täglich sollte reichen für 5 Sekunden Toleranz.
Bitte warten ..
Mitglied: Raynor
05.06.2016, aktualisiert um 19:40 Uhr
Hallo,

möchte mich hier auch mal zum Thema zu Wort melden.

Ich habe das angesprochene "Zeitphänomen" im Februar 2016 erstmals in einer Testumgebung mit zwei Maschinen als Hyper-V-Hosts beobachtet.
Zum Einsatz kam Windows Server 2016 TP4 (oder war's TP3?) auf zwei INTEL XEON E3-1246v3 Maschinen mit ASUS H97 Boards.
Beide Maschinen zogen die Zeit aus dem Inet. Eines Tages stimmte auf dem einen Host Datum und Zeit nicht mehr. Da mehrere Syncversuche und schließlcih das ganze Abschalten der Syncerei mit externen Servern auch keinen Erfolg brachte, hab ich die Maschinen neu installiert. Dauerte nicht lange, war schon wieder Datum und Zeit verstellt. Weitere Neuinstallation, same procedure.

Eine virtuelle Maschine auf dem anderen Host lief lange Zeit als virt. DC mit Zeitsync mit einem dedizierten Server, der per DCF77 die offizielle Zeit empfängt. Irgendwann....bums: Ein Datum ein paar Wochen vorher und eine um ein paar Stunden verschobene Uhrzeit.
Auch diesen Server gefühlte zweihundert Mal neuinstalliert und zurückgesnapshottet. Egal, über kurz oder lang der gleiche Mist wieder.
Dann vor ein paar Wochen auf TP5 gewechselt, nachdem ich auch irgendwo im Netz von MS etwas über gefixte time probs in der TP4 bzw. TP5 gelesen habe. Die zwei Hyper-V-Hoste also frisch mit TP5 bespielt, virtuelle Maschinen drauf und hübsch... bis diese Woche ein virt. Server mir rotzfrech ein falsches Datum und eine falsche Uhrzeit präsentierte. Auch diese nun wieder platt gemacht und neu installiert. Mal sehen wie's weitergeht.

Doch nun nervt mich auch noch ein Client in der Fertigung: WIN 10 Pro 1511 10586.318 Build: Falsches Datum und Uhrzeit. Das Ding ist Domänenmitglied und bekommt von PDC die richtige Zeit mitgteilt. Aber das scheint WIN 10 irgendwann nicht mehr zu interessieren und macht seinen Weg Back in The Past. Hardware ist ein Baytrail (N2930), also SoC und was völlig anderes als die erwähnten Hyper-V-Hosts.
Mich ko... es richtig an mittlerweile, weil ich überhaupt keinen Ansatzpunkt habe.

Behelfe mich eben auch mittels net time /set blabla (Danke an DerWoWusste), aber es sollte doch von MS längst Anhilfe geschaffen sein.
Ansonsten wundert mich, dass das Thema in Inet außer hier und im mcseboard nicht behandelt wird.
Da wir bei uns auch Windows 7 und auch noch XP und Windows Server 2008 haben und diese nicht betroffen sind und ich auch sonst ein solches Phänomen in meiner "EDV-Karriere" nocht nicht beobachten konnte, komme ich zu dem Schluß, dass hier einzig die aktuellen Windowsversionen (Desktop und Server) verbuggt sind.

Liebe Grüße an alle Leidgenossen
Bitte warten ..
Mitglied: doc-jochim
14.06.2016 um 15:07 Uhr
Hallo,

irgendwie scheint das ja ein grundlegendes Problem in Windows10 zu sein, das komischerweise aber scheinbar nicht in jeder Umgebung auftritt oder bemerkt wird

Wir haben hier ein kleines als Domäne aufgebautes Netzwerk mit ca. 12 Rechnern und Win2003Server(Standard) als Server (nur ein Server, der alles macht, PDC, DC, DNS, DHCP usw.). Das Netzwerk hat normalerweise keine Verbindung ins Internet.

Bisher hatten die Rechner mit Win7pro64bit installiert, einer davon noch XPpro(32bit).

Stück für Stück habe ich jetzt angefangen, die Win10-Upgrades zu installieren (Win10-Image von Microsoft heruntergeladen, damit nicht jeder Rechner das einzeln machen muss, auf USB-Stick gespeichert, über Setup.exe auf dem Stick installiert)

Alle Rechner haben sich bisher immer brav die Uhrzeit vom Server geholt und waren dadurch immer synchron.

Aber mit den Windows10-Rechnern habe ich jetzt genau das beschriebene Problem: Plötzlich verändert sich das Datum (auf das Windows10-Installationsdatum) und auch die Uhrzeit wird verstellt. Wenn ich den Rechner neu starte, holt sich das System wieder die korrekte Zeit vom Server, aber nach einiger Zeit dann plötzlich wieder schwupps, ab in die Vergangenheit.

Wenn ich cmd als Administrator starte und 'net time /set' eingebe, wird die Zeit nach der Beantwortung der Frage mit Ja wieder richtig gesetzt, aber es dauert nicht lange und ... täglich grüßt das Murmeltier...

Im Ereignisprotokoll sieht man auch nur die plötzlichen Zeitsprünge und einen Eintrag, daß irgendwer oder -was die Zeit verstellt hat. Aber was?

Het jemand von Euch inzwischen eine Idee? In den Rechnern sind i5-3330-Prozessoren drin.

Ich habe selbst zu wenig Ahnung, um hier selbst Lösungen zu sehen, aber vielleicht kann ich mit irgendwelchen Infos für Euch noch zur Lösungssuche beitragen?

Ich weiss nur, daß es vor Win10 keine Probleme mit Uhrzeit und Datum gab.

André
Bitte warten ..
Mitglied: DerWoWusste
14.06.2016 um 15:24 Uhr
Hi André.

Ersteinmal: schön, dass dieser Thread noch lebt und gefunden wird. Dann: super, dass wir jemanden haben, der seine CPU benennt und ein weiteres Mal bestätigt, dass es kein Problem von Skylake-CPUs ist, sondern auch auf älteren PCs auftritt!

Zur Lösung: mein Workaround hat keine wirklichen Nebenwirkungen und löst es:
Ich habe nun bei allen den Dienst "Windows-Zeitgeber" deaktivieren müssen und lasse stattdessen ein Skript
net time /set /y
per Taskplaner alle paar Stunden laufen
Bitte warten ..
Mitglied: doc-jochim
14.06.2016 um 15:41 Uhr
Zitat von @DerWoWusste:
net time /set /y per Taskplaner alle paar Stunden laufen

Ich habe noch keine belastbaren Zahlen darüber, nach welcher Zeit das System immer die Zeitmaschine betritt und in die Vergangenheit reist.

Aber heute morgen, nachdem ich den Befehl mehrfach manuell benutzt habe, ist zumindest kurz danach immer wieder ein Zeitsprung dagewesen. Das müsste dann aber ja kein Problem mehr sein, wenn der Windows-Zeitgeber durch Deaktivierung des Dienstes mundtot gemacht wird...

Ich probiere das mal aus.

Ich bin nur entsetzt darüber, daß solche Fehler in der Kommunikation - gerade vor dem Hintergrund, wie lange Win10 jetzt schon verfügbar ist - noch nicht bei MS behoben wurden. Im Netz findet man auch irgendwie nicht soviel darüber.

André
Bitte warten ..
Mitglied: doc-jochim
15.06.2016, aktualisiert um 14:50 Uhr
Hello,

ich habe jetzt nochmal an einem der Rechner gesessen, an dem die Zeit ständig auf das Installationsdatum vom 1.6. springt.

Wenn der Zeitgeberdienst noch aktiv ist und ich über 'net time /set /y' in einer als Administrator gestarteten Batch-Datei die Zeit vom Server hole, dann ist in der Taskleiste das korrekte Datum zu sehen - aber dann hat es nur 4-5 Sekunden gedauert, bis wieder der hartnäckige 1.6. dort stand.

Ich habe das 4x direkt in Folge wiederholt und dann mal in das Ereignisprotokoll geschaut, was dort festgehalten wurde.

Die Ereignisse habe ch dann mal markiert und gespeichert, da ich selbst daraus keine Informationen gewinnen kann. Vielleicht jemand von Euch?

Hier mal der Link zu den exportierten Ereignissen: http://goo.gl/Nfhdm1 (Edit: Link funktioniert nicht, Korrektur s. mein nächster Beitrag)

André
Bitte warten ..
Mitglied: DerWoWusste
15.06.2016 um 11:28 Uhr
Du kannst das Ereignis ruhig hier reinkopieren. Deine goo.gl-Links gehen nicht.
Wenn Du mehr über das Problem rausfinden willst (ich bitte ausdrücklich darum), dann schalte mal Logging für den Zeitdienst an:
https://support.microsoft.com/en-us/kb/816043
Bitte warten ..
Mitglied: doc-jochim
15.06.2016, aktualisiert um 18:25 Uhr
uuuups - da scheint der Link-Verkürzer von google wohl etwas gesperrt zu haben...

Hier nochmal der Link zum gezippten Export der Ereignisse:

http://www.DresMatthiesJochim.de/win10/ereignis.zip

Das mit dem Logging muss ich mir mal vornehmen. Ein - wie an anderer Stelle empfohlen - Herausnehmen des Rechners aus der Domäne, Löschen des Computerkontos und wieder neu in die Domäne Aufnehmen hat keinen Erfolg gezeigt.

André

Edit: Die in o.g. Link zum Aktivieren der log-Funktion des Zeitdienstes angegebene Anleitung ist seitens MS ziemlich unvollständig, denn ohne eine Angabe, ob der Wert des einzugebenden DWORD-Schlüssels ein Hex-Wert oder ein Dezimalwert ist, kann hier etwas ziemlich falsches in der Registry landen...
Nähere Infos habe ich hier gefunden. Sogar mit einem Befehl zur Aktivierung / Deaktivierung über die Konsole ohne Reg-Eingriff. Wenn ich diese Befehle zum Aktivieren oder deaktivieren jew. in eine *.cmd-Datei schreibe, kann ich so ganz einfach das Logging ein- und ausschalten. Die Reg.-Einträge werden so (Starten als Administrator vorausgesetzt) automatisch gesetzt und wieder entfernt.
Ich probiere das dann mal aus...
Bitte warten ..
Mitglied: doc-jochim
17.06.2016 um 12:38 Uhr
Hallo,

so, ich habe jetzt mal ein bisschen herumprobiert:

Ich habe an einem W10-Rechner, bei dem die Zeitdienst-Synchronisierung mit dem Server problemlos funktioniert, mal die zum Zeitdienst gehörenden Reg-Einstellungen exportiert sowie ein Debug-Log mitschreiben lassen.

Zusätzlich habe ich an einem der W10-Rechner, an dem es die Vergangenheits-Zeitsprünge zum Installationsdatum gibt, eine Batch-Datei geschrieben, die nach Aktualsierung der Systemzeit diese festhält, bei Veränderungen automatisch erneut synchronisiert sowie die Uhrzeit des Zeitrückfalls in eine Protokolldatei schreibt. An diesem Rechner wurden ebenfalls die zum Zeitdienst gehörenden Reg-Einstellungen exportiert, ein Debug-Log erstellt sowie die aus diesem Zeitraum stammenden Ereignisse aus dem System-Protokoll gespeichert.

Alle diese Dateien hab ich mal hier zum Herunterladen abgelegt.

Jetzt wäre es nur noch toll, wenn jemand anhand dieser Daten mal eine Idee hätte, warum Windows 10 hier mit der Zeitsynchronisierung Probleme hat.

Viele Grüße und ein schönes Wochenende

André
Bitte warten ..
Mitglied: DerWoWusste
17.06.2016 um 13:02 Uhr
Jetzt wäre es nur noch toll, wenn jemand anhand dieser Daten mal eine Idee hätte, warum Windows 10 hier mit der Zeitsynchronisierung Probleme hat.
Ich nicht. Habt Ihr einen MS-Supportvertrag? Dann schick denen das zur Analyse. Ich habe für 2016 genug vom MS Support.
Bitte warten ..
Mitglied: doc-jochim
17.06.2016 um 13:31 Uhr
Nein - wir haben leider keinen Support-Vertrag...

André
Bitte warten ..
Mitglied: doc-jochim
22.06.2016, aktualisiert um 11:05 Uhr
Hallo,

so, ich habe jetzt nochmal ein bißcher - auch im englischsprachigen Internet herumgelesen - und es gibt nicht nur hier die Probleme. Und meist scheint es wohl an einer aus welchem Grund auch immer fehlerhaften Konfiguration des Zeitdienstes der Clients zu liegen.

An einem Rechner, bei dem ich den Zeitdienst deaktiviert hatte und die Synchronisation über 'net time /set /y' durchgeführt hatte, habe ich jetzt mal folgendes probiert:

deaktivierten Zeitdienst unter msconfig wieder aktiviert
cmd-Konsole (als Administrator starten)
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
w32tm /resync /nowait

Und dann zur Kontrolle
w32tm /query /status
w32tm /monitor

An diesem Rechner habe ich seit gestern keinen einzigen Zeitsprung mehr gehabt. So wie beschrieben sollte man - wenn irgendetwas im Zeitdienst des Clients durcheinandergekommen sein sollte, die Einstellungen wieder auf Standard zurücksetzen können. Bin mal gespannt, ob es reproduzierbar auch bei den anderen Clients funktioniert.

Viele Grüße

André
Bitte warten ..
Mitglied: DerWoWusste
22.06.2016 um 11:54 Uhr
Interessant. Hast Du Links für uns, die das Vorgehen untermauern?
Bitte warten ..
Mitglied: doc-jochim
22.06.2016, aktualisiert um 12:25 Uhr
z.B. hier oder hier
Bitte warten ..
Mitglied: DerWoWusste
22.06.2016 um 12:52 Uhr
Nein, ich meinte eher zu "Und meist scheint es wohl an einer aus welchem Grund auch immer fehlerhaften Konfiguration des Zeitdienstes der Clients zu liegen"
Bitte warten ..
Mitglied: colinardo
22.06.2016, aktualisiert um 13:04 Uhr
Das wäre dann wohl eher was für Clients die schon richtig "verkonfiguriert" sind. Ein clean aufgesetzter W10-Client wird wohl keine Fehlkonfiguration aufweisen, zumal das hier mit einer der betroffenen Kisten so auch keine Besserung bringt.
Laut dem Kollegen an den ich die Bug-Meldung weitergeleitet habe soll es wohl tatsächlich ein Bug im Zeitdienst (w32tm.dll) (ab Threshold) sein. Microsoft wäre wohl dabei die Ursache zu klären.
Bitte warten ..
Mitglied: doc-jochim
24.06.2016, aktualisiert 26.06.2016
Hmmmm.... - richtig funktioniert hat es wohl doch nicht.

An dem Rechner, an dem ich angefangen habe, die W32time-Einstellungen so wie oben von mir beschrieben zurückzusetzen, gab es heute dann doch wieder einen Zeitsprung. Diesmal aber nicht auf das Installationsdatum des W10-Updates (bei mir sind die Pro-Versionen installiert), sondern auf das Datum, an dem ich den Zeitdienst de- und wieder neu registriert habe.


Warum nur?

Doch ein Bug im W10-Zeitdienst? Nur warum zeigt der sich dann nicht an jedem Rechner?

André
Bitte warten ..
Mitglied: pluto13
06.07.2016, aktualisiert um 16:16 Uhr
So, nach mehreren Monaten ergebnisloser Suche mal meine Ergebnisse (Unternehmen mit 2500 Mitarbeitern und ca. 800 Rechnern):

Hier sind bisher 4 Rechner betroffen (Zahl zunehmend):

- Es ist Herstellerübergreifend (Lenovo, Dell, VMWare, Forsis)
- Ist ist CPU und Board unabhängig
- Keiner der Clients wurde "geupgraded". - Alle neu installiert.
- Es tritt sporadisch auf
- Es ist nie ein und das selbe Datum

- Der Rechner ist nicht mit dem Internet verbunden
- Die Rechner wurden nach dem gleichen Verfahren installiert


Weitere Punkte? Ich erweitere die Liste gerne!

Gruß,
Pluto13
Bitte warten ..
Mitglied: bernd.h
09.07.2016, aktualisiert um 15:30 Uhr
Hallo
nachdem ich diese Beiträge seit einiger Zeit verfolge, da ich dieselben Probleme habe ich hier meine Ergebnisse aufgelistet, die sich weitgehend mit denen von Pluto 13 decken:

- Herstellerübergreifend (Lenovo, HP, VMWare)
- es ist CPU und Board unabhängig
- Keiner der Clients wurde "geupgraded". - Alle neu installiert (Win 10 -1511)
- Es tritt sporadisch auf
- Es ist nie ein und das selbe Datum
- Der Rechner ist nicht mit dem Internet verbunden
- Die Rechner wurden nach dem gleichen Verfahren installiert

- bei einem NB verschwand das Problem einfach so
- bei einem NB gleicher Reihe versuche ich bisher erfolglos das Problem zu lösen
- 2 baugleiche PC wurden auf Win 8.1 zurück migriert (Neuinstallation) -> keine Probleme mehr

Gruß Bernd
Bitte warten ..
Mitglied: itisnapanto
18.07.2016 um 09:44 Uhr
Hier bei uns auch dasselbe ... Mal sehen ob das Problem gelöst werden kann.

Heute auch mal einige Clients mit Batch Dateien versorgt .
Mal schauen ob das temporär hilft.

Gruss Michael
Bitte warten ..
Mitglied: S.tefan
08.08.2016 um 11:15 Uhr
Guten Morgen,

hat jemand mitlerweile jemand eine Lösung (kein Workaround) gefunden?

Wir haben nun vor kurzem auch auf 10 umgestellt und haben das Problem an diversen Recher (ca. 50).

Die Rechner sind zwischen 5 Jahren und ganz aktuell. Daher können wir keinen Hardwaretechnischen zusammenhang erkennen.

Gruß

Stefan
Bitte warten ..
Mitglied: colinardo
08.08.2016, aktualisiert um 13:39 Uhr
Zitat von @S.tefan:
hat jemand mitlerweile jemand eine Lösung (kein Workaround) gefunden?
Hallo Stefan,
habt Ihr schon auf 1607 umgestellt ? Seit dem Anniversary Update sind hier die Probleme ausnahmslos nicht mehr aufgetreten. Die "w32time.dll" weist auch schon eine Änderung zur letzten Version 1511 auf, was darauf schließen lässt das sie den angekündigten Patch (s. weiter oben) schon haben einfließen lassen.

Grüße Uwe
Bitte warten ..
Mitglied: pelzfrucht
08.08.2016 um 13:09 Uhr
habt Ihr schon auf 1607 umgestellt ?
Wird der schon per WSUS ausgeteilt?
Hab mal in der Kategorie Upgrade nachgeguckt.. Aber kein neu(eres) Upgrade gefunden.

Grüße
pelzfrucht
Bitte warten ..
Mitglied: colinardo
08.08.2016, aktualisiert um 13:14 Uhr
Zitat von @pelzfrucht:
habt Ihr schon auf 1607 umgestellt ?
Wird der schon per WSUS ausgeteilt?
Hab mal in der Kategorie Upgrade nachgeguckt.. Aber kein neu(eres) Upgrade gefunden.
Werf die Suche an, gab's die letzten Tage schon diverse Threads dazu ...

So ein Upgrade per WSUS anzuwerfen ist gewagt und sollte man nur machen wenn keiner vor den Kisten sitzt (Client kann Admin-Rechte mit SHIFT-F10 während der Installation erlangen)

Das ist hier aber nicht das Thema des Threads, bitte diskutiere das an einem anderen Ort, Merci!
Bitte warten ..
Mitglied: S.tefan
08.08.2016 um 13:29 Uhr
Nein, nur auf ein paar Testgeräten, die haben allerdings eine Internetverbindung auf auf solchen Rechnern ist das Problem gar nicht erst aufgetreten. Ich hatte aber auch die Hoffnung, dass es sich durch das Update erledigt.

Werde berichten. Danke!

Gruß

Stefan
Bitte warten ..
Mitglied: pelzfrucht
08.08.2016, aktualisiert um 16:16 Uhr
Werf die Suche an, gab's die letzten Tage schon diverse Threads dazu ...
Nicht gesehen sorry. (Jedenfalls nicht vor ein paar Tagen)
Aber hab jetzt die Antwort: (16 Aug.)

So ein Upgrade per WSUS anzuwerfen ist gewagt und sollte man nur machen wenn keiner vor den Kisten sitzt (Client kann Admin-Rechte mit SHIFT-F10 während der Installation erlangen)
Ist zu Hause ;-) face-wink Und das Problem kannte ich schon. @DerWoWusste hat es angeschnitten.
Trotzdem Danke für den Hinweis :-) face-smile

Das ist hier aber nicht das Thema des Threads, bitte diskutiere das an einem anderen Ort, Merci!
War ja nur ne kurze Frage. Sorry :-( face-sad

Merci
pelzfrucht

PS: Um etwas zum Beitrag beizutragen:
Bei uns tritt der Fehler auf keinem physischen Computer auf. Ist mir nur einmal in einer virtuellen Maschine begegnet.
Hier hat er mich allerdings nicht gestört da VirtualBox die Gast Uhrzeit automatisch auf die Host Uhrzeit zurücksetzt.
Bitte warten ..
Mitglied: Goldhuhn
11.08.2016, aktualisiert um 11:42 Uhr
@mitglied: doc-jochim
doc-jochim
ich hatte ebenfalls die Probleme in fast allen Zeiterfassungsterminals, das Problem tritt anscheinend nur an Clients auf, die keine Internetverbindung haben und im Dauerbetrieb laufen. In Win10 Build 10240 Testphase hatte ich die Probleme nicht, erst ab Win10 10568.

Auch wenn ab Win10 1607 Redstone der Bug in W32time.dll anscheinend beseitigt wurde, möchte ich dennoch meine Lösung posten, falls der Fehler doch irgendwann wieder beim nächsten ungetesteten Update von Microsoft auftreten soll, ist ja nicht der erste üble Bug, den MS in W32time leichtsinnig einbaute.

Die von dir beschriebene Lösung,. die ich zunächst ebenfalls anwendete, half bei mir ebenfalls nur kurzzeitig:
deaktivierten Zeitdienst unter msconfig wieder aktiviert
cmd-Konsole (als Administrator starten)
net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
w32tm /resync /nowait
Und dann zur Kontrolle
w32tm /query /status
w32tm /monitor

spätestens als ich w32tm /config /syncfromflags:domhier /update eingegeben hatte, war die Zeit wieder falsch, ich konnte es zum Glück diesmal nachvollziehen, da der Fehler diesmal statisch und nicht irgendwann sporadisch auftrat:

Ich hatte daher einfach folgendes versucht:
w32tm /unregister
Neustart
w32tm /register
Neustart

w32tm /config /syncfromflags:domhier /update hatte ich bewusst weggelassen.

Die Zeit wird jede Stunde mit dem ersten Domänencontroller synchronisiert, time.windows.com usw. wurden alle in der Registry entfernt.
Weitere zwei DCs wurden als Ausweichserver konfiguriert, falls DC1 nicht antwortet.

In den nächsten zwei Tagen dann zum Glück die Erleichterung, neun Terminals liefen endlich in der richtigen Zeit, bis auf zwei Terminals, hier wiederholte ich einfach nochmal den Workaround, dann war endlich Ruhe. Seit drei Wochen laufen alle Terminals mit der richtigen Zeit, bislang wurde keins auf Win10 1607 Redstone aktualisiert.

Edit: Fehler beseitigt Win10 1611 Redstone zu Win10 1607 Redstone
Bitte warten ..
Mitglied: colinardo
11.08.2016, aktualisiert um 10:53 Uhr
Auch wenn ab Win10 1611 Redstone der Bug in W32time.dll anscheinend beseitigt wurde
auf Win10 1611 Redstone aktualisiert.
Liegt bei euch auch schon Schnee, oder geht bei euch die Uhr doch noch 4 Monate vor :-) face-smile?
Bitte warten ..
Mitglied: Goldhuhn
11.08.2016 um 11:45 Uhr
danke, habs ausgebessert, auch wenn noch kein Schnee liegt, obwohl wir heute morgen mit 5 Grad mitten im Sommer nicht weit davon entfernt sind.
Bitte warten ..
Mitglied: DerWoWusste
14.10.2016 um 11:51 Uhr
Moin.

News: eben gerade mal wieder getestet auf einem aktuellen Win10 1607 - das Problem besteht fort. Die Zeit sprang munter zwischen Installationsdatum und heutigem Datum hin und her, bis ich den Zeitdienst wieder deaktivierte. Klasse. Es ist noch nicht ausgestanden.
Bitte warten ..
Heiß diskutierte Inhalte
Sicherheit
Verpackter Laptop entwendet
r0x3llVor 1 TagFrageSicherheit11 Kommentare

Hallo. Mir wurde aus dem Büro ein noch verpackter Dell XPS Laptop mit einem Wert von ca 3.500€ gestohlen. Kann man da was orten? ...

Off Topic
Namenskonzept Kundengeräte
bitnarratorVor 1 TagFrageOff Topic5 Kommentare

Hallo, ich möchte gerne einmal die Diskussion anstoßen, weil ich eine hier in diese Richtung noch nichts gefunden habe. Es geht um die Bennenung ...

Netzwerkgrundlagen
Router für neues Heimnetzwerk - was will man 2021 haben?
billy01Vor 1 TagFrageNetzwerkgrundlagen7 Kommentare

Guten Abend zusammen, nachdem sich bei mir viel getan hat, stehe ich nun vor einem Umzug und dem Neuaufbau meines Heimnetzwerkes. Also weg von ...

Windows Server
Kein Internetzugriff bei einem Domänenclient
KerberoVor 1 TagFrageWindows Server15 Kommentare

Hallo community, ich habe ein ganz komisches Verhalten eines Clients bei mir. Ich habe eine kleine Domäne (6 Clients und ein Windows Server 2016 ...

LAN, WAN, Wireless
2x Fritzbox 7590 mit separatem DSL über WAN verbinden
gelöst FailixVor 21 StundenFrageLAN, WAN, Wireless19 Kommentare

Liebes Administrator Forum, Ich bin schon länger passiver Lese und habe mich jetzt entschlossen mit einer Frage den ersten Post hier zu schreiben. Über ...

Off Topic
Wie sieht eine korrekte IT-Organisation aus?
imebroVor 4 StundenFrageOff Topic17 Kommentare

Hallo, da unser IT-Verantwortlicher ja vor einem Jahr gehen musste, stelle ich mir die Frage, wie denn eine korrekte IT-Organisation überhaupt aussehen muss. Zur ...

LAN, WAN, Wireless
Cat 7 Patchkabel mit nur 11MBits im Download
gelöst RickHHVor 19 StundenFrageLAN, WAN, Wireless7 Kommentare

Moin zusammen, ich habe mir soeben ein paar Patchkabel (aus einem Cat 7 Kabel) fertig gemacht. Die Belegung ist: 1 weiß/grün 2 grün 3 weiß/orange 4 blau 5 weiß/blau ...

DNS
Network Scanner zeigt falschen Hostname an
gelöst vafk18Vor 21 StundenFrageDNS10 Kommentare

Ich habe in meinem Netzwerk 3 Fritzboxen im Betrieb. Die Fritzboxen haben in den Einstellungen als Namen "fb7270", "fb7369" und "fb7412". Jede Fritzbox hat ...