55
Hat Win10 Probleme mit dem Zeitdienst?
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.
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 298453
Url: https://administrator.de/contentid/298453
Ausgedruckt am: 21.11.2024 um 16:11 Uhr
55 Kommentare
Neuester Kommentar
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?
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?
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.
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.
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.
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.
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.
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
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
Huch, mein Feedback fast vergessen....
Schnödes "aus Domäne, in Domäne" hat geholfen. Alle geschilderten Probleme hatten sich damit erledigt.
Schnödes "aus Domäne, in Domäne" hat geholfen. Alle geschilderten Probleme hatten sich damit erledigt.
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.
Bei uns kam dieses Zurückstellen ja auch manchmal tagelang nicht vor und dann wieder.
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.
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.
Wünsche viel Glück, dass es so bleibt, habe aber Zweifel 
Sachen gibt's :
Windows 10 Pro x64
aktuellster Updatestand
:Windows 10 Pro x64
aktuellster Updatestand
Zeitzone zufällig auf GMT ? käme hin mit den zwei Stunden zur CEST
Oder was soll uns der Screenshot sagen?
käme hin mit den zwei Stunden zur CESTOder was soll uns der Screenshot sagen?
Nö passt alles. War jetzt schon ein paar Mal auf unterschiedlichen Systemen mit Skylake.
Aber Datum passte?
Jop.
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.
-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.
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
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
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
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
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).
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).
Die Info habe ich schon vorsorglich an die entsprechenden Stellen weitergeleitet 
, also mal abwarten.
, also mal abwarten.
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.
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.
1
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.
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.
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.
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.
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
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)
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
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)
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:net time /set /y
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
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 ). 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.
Gruß MTG
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
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
). 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
.Gruß MTG
Net time funktioniert ohne den Dienst, ein oder zwei Mal täglich sollte reichen für 5 Sekunden Toleranz.
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
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
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é
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é
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
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
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é
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é
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é
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
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
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...
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...
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é
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é
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.
Nein - wir haben leider keinen Support-Vertrag...
André
André
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é
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é
Interessant. Hast Du Links für uns, die das Vorgehen untermauern?
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"
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.
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.
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é
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é
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
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
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
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
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
Heute auch mal einige Clients mit Batch Dateien versorgt .
Mal schauen ob das temporär hilft.
Gruss Michael
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
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
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
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
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
Zitat von @pelzfrucht:
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 ...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.
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!
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
Werde berichten. Danke!
Gruß
Stefan
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 Und das Problem kannte ich schon. @DerWoWusste hat es angeschnitten.Trotzdem Danke für den Hinweis
Das ist hier aber nicht das Thema des Threads, bitte diskutiere das an einem anderen Ort, Merci!
War ja nur ne kurze Frage. Sorry 
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.
@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
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
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 auf Win10 1611 Redstone aktualisiert.
?
danke, habs ausgebessert, auch wenn noch kein Schnee liegt, obwohl wir heute morgen mit 5 Grad mitten im Sommer nicht weit davon entfernt sind.
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.
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.
