doc_jochim

Also: Es gibt nur einen Server2003Standard-DC, der alle Rollen innehat und PDC, DHCP-Server, DNS-Server, WINS-Server usw. ist, sonst keine weiteren Server / DCs Der Rechner xp1 ist der o.g. DC Die Clients sind alle Win7pro64bit und sind so nach und nach jetzt auf Win10pro64bit umgestellt worden. Einer ist noch auf Win7. Und einen weitereren Client hatte ich wegen 'antiker' Hardware immer noch auf XP laufen. Aber der wird jetzt auch auf Win7 und dann mit Upgrade auf Win10 umgestellt werden können. Was macht eigentlich dieses wdigest? Oh je - immer mehr Löcher in meinem Wissen tun sich auf... :shock: André

Auf dem System laufen keine Programme, die eine Anbindung nach draußen brauchen. Keine Mails, keine Brieftauben. Für Updates wird zwischendurch mal eine LAN-Verbindung zur Fritz!Box erstellt und die Updates eingespielt. Das Logfile hatte ich doch erstellt und wie hier geschrieben dort zum Herunterladen bereitgestellt.Allerdings nicht 24h ohne Zeitsprung, da die Zeitsprünge mehrfach täglich auftraten. Mit meinem Batchfile habe ich auch die zugehörigen Zeitpunkte protokolliert und in einem Textfile abgespeichert (Allerdings stehen im Debugging-Log des Zeitdienstes die Uhrzeiten ohne Berücksichtigung der Zeitzone und sind im Verhältnis zu den abgespeicherten Zeitpunkten um 2h verschoben) Das komische ist ja, daß die Zeit / das Datum nicht auf einen im bestimmten Verhältnis zum Bios oder zu der Systemzeit stehenden Zeitpunkt verschoben wird, sondern immer auf den gleichen fixen Zeitpunkt gesetzt wird. Security Journaling? Bahnhof... :confused: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:disable /failure:enable? Das ist der Befehl, um das logging zu aktivieren? Die Daten stehen dann im Ereignisprotokoll? Und wie wird das wieder ausgeschaltet? Mit dem gleichen Befehl, nur disable statt enable? Ähhh... - wie? André

Die Frage lässt sich ganz einfach beantworten: Unser Netz ist eine kleine glückliche Insel ohne irgendeine Verbindung nach draußen. Kein Stecker, kein Kabel, kein WLAN. Also von außen kann hier niemand seine Zeit beziehen. Der DHCP-Server ist so konfiguriert, daß die Clients auch keinen Standard-Gateway zugewiesen bekommen. Das Feld ist leer. Wollen die Clients hier partout nach draußen und beschweren sich dann, wenn es nicht geht? Wird Win10 wild, wenn es eingesperrt wird? André

Hmmm... - kommen die Kerberos-Probleme denn nicht immer erst dann, wenn der Zeitsprung stattgefunden hat? Dann wäre es ja klar, daß hier eine Kommunikation wegen eines total falschen Zeitstempels nicht mehr möglich ist. Dann kann ich nämlich auch von anderen Clients aus bei den in die Vergangenheit gefallenen Clients nicht mehr auf die administrativen Freigaben der Laufwerke zugreifen. Immer kehren auch die folgende Zeilen wieder: Und danach gibt es im Debug-Logfile (wie heisst denn das Ding nun richtig?) immer den Zeitsprung. Und - wie man erkennen kann - immer auf das gleiche Datum und die gleiche Uhrzeit. Nur woher nimmt der Rechner denn dieses immer wiederkehrende Ziel? Sind die Kerberos-Probleme denn dann der Grund oder die Folge der Zeitsprünge? Warum vertraut der Client denn dem Server nicht? Ich habe am Server jetzt nochmal 'w32tm /config /reliable:yes' eingegeben. Mal sehen, ob die Fehler jetzt immer noch auftreten. André

Ich hatte oben doch bereits geschrieben, daß ich debug-logfiles erstellt habe und den link zu den files gepostet. Genau so wurde das debug-logging aktiviert. Am einfachsten ist es aber, wenn man sich eine kurze Batchdatei zum Einschalten des debug-loggings erstellt und eine zu Ausschalten: ON.bat: w32tm /debug /enable /file:C:\windows\temp\w32time.log /size:10000000 /entries:0-300 OFF.bat: w32tm /debug /disable Damit werden dann automatisch (als Administrator ausführen) die beschriebenen Reg-Einträge erstellt bzw. wieder aus der Registry herausgenommen. Aber ich selbst kann mit den logfiles nicht wirklich etwas anfangen. So doof ist das doch gar nicht. Aber es ist leider nicht so. Die Zeitzone ist die Gleiche. Außerdem würde dann sicher nur die Uhrzeit um ganze Stunden versetzt werden und nicht gleich das Datum einen großen Sprung machen, zusammen mit einer Uhrzeit, die nicht um ganze Stunden verschoben ist. André

Hallo, so'n shice...! Zu früh gefreut. 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 :confused: Warum nur? Ich hatte vor dem ersten Zurücksetzen des Zeitgeber-Dienstes an den betroffenen clients mal debug-log-files vom Zeitgeberdienst geschrieben. Die dazugehörigen Dateien habe ich mal hier hinterlegt. Für mich ist das nur Chinesisch, aber vielleicht kann jemand von Euch daraus etwas erkennen? André

Wenn wegen der ungeklärten Zeitsprünge des Systems auf das Installationsdatum des Win10-Updates der Windows Zeitgeber-Dienst unter msconfig deaktiviert wurde, wie soll man denn sonst das Datum stellen? Da ist der o.g. Befehl bei deaktiviertem w32time doch wenigstens ein vorübergehend funktionierender workaround gewesen. Warum ist das dann so unglaublich? Oder habe ich nur die Ironie nicht bemerkt? 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é

Hallo, Ihr seid nicht alleine mit dem Problem - bei mir ist es auch so und ich bin genauso ratlos... Ich habe einiges dazu bereits hier geschrieben und muss das ja hier nicht alles nochmal wiederholen. Vielleicht einfach mal unter diesem Link schauen - vielleicht kann ja auch jemand aus den von mir zum Download bereitgestellten Log-Dateien etwas erkennen, wes uns der Lösung näher bringt. André