Werotex 10 Geschrieben 20. März 2019 Melden Teilen Geschrieben 20. März 2019 Hallo, ich habe seit gestern ein Problem mit "ganz wilden" Uhrzeiten an einigen Clients mit Windows XP (ja ich weiß). Nutzt an dieser Stelle nicht darüber zu "streiten", mein Problem bleibt ja. Nur kurz dazu: Wir sind sonst bei allem wirklich ganz ordentlich aufgestellt, aber von einigen wenigen XP-Rechnern die Produktionsmaschinen steuern, will man sich aktuell noch nicht trennen. Diese befinden sich zumindest in einem separaten Netzwerkbereich. Fakt. Aktuell synchronisieren sie offensichtlich die Uhrzeit nicht mehr nach der Anmeldung im Netzwerk mit dem DC mit Windows Server 2016. Die Uhrzeit am Server passt. Windows-Rechner ab Windows 7 haben das Problem anscheinend nicht. Wenn ich als Domainadmin am Client angemeldet den Befehl net time durchführe, bekomme ich die richtige Uhrzeit vom DC geliefert. Mit dem Zusatz /set /yes auch am Client eingestellt (das habe ich gestern per "Turnschuh-Administration" erledigt, heute gleiches Problem). Ich habe zuvor am Montag (18.3.) am DC Server 2016 die neuesten Updates eingespielt von letzter Woche (KW 11 2019 ?)! Naheliegende Vermutung: Daran wird's wohl liegen. Jetzt habe ich die auch alle schon wieder deinstalliert! Aber an der Situation ändert das leider nichts, womit ich erstmal am Ende meines Lateins wäre ... Ich hatte gleich am Mittwoch glaube ich letzter Woche an meinen beiden anderen DC's (ebenfalls Windows Server 2016) die Updates eingespielt und keinerlei Probleme gehabt - allerdings melden sich da auch keine XP-Clients an, die sind im Netz nur mit dem einen DC. Gruß Björn Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 20. März 2019 Melden Teilen Geschrieben 20. März 2019 Was steht denn unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters am Client? Zitieren Link zu diesem Kommentar
Werotex 10 Geschrieben 20. März 2019 Autor Melden Teilen Geschrieben 20. März 2019 Hallo, da sieht es so aus. Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 20. März 2019 Melden Teilen Geschrieben 20. März 2019 Dann geht es auch nicht. Bei Domain-Member-Computern gehört bei Type "NT5DS" rein, was auch Standard ist. Es sei denn, jemand hat hier per GPO oder anders etwas am Standard vorbei konfiguriert. Wie gesagt: Man braucht es normalerweise nicht, kann es aber damit reparieren: https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ Zitieren Link zu diesem Kommentar
Werotex 10 Geschrieben 21. März 2019 Autor Melden Teilen Geschrieben 21. März 2019 Hallo, also die Client-Einstellungen sind diesbezüglich recht "bunt" habe ich festgestellt. Wie gesagt habe ich das Problem auf KEINEM Win7 Client. Dennoch gibt es auch hier (mindestens) einen Rechner, der bei "Type" -NoSync- drin stehen hat. Er synct dennoch, Dann habe ich auch mindestens einen XP-Rechner, der hat das (jetzt?) drin stehen und er synct wohl auch, obwohl der zuvor auch Probleme hatte. @Zahni: Du hast Recht. Bei uns ist eigentlich das Meiste immer nur "Standard" und so steht es auch in unserer "Default Domain Policy". Nichtsdestotrotz habe ich (mindestens) einen XP-Client, der auch nach einem ERFOLGREICHEN GP-Update das ganze NICHT in die Registry schreiben will. Habe das auch nochmal doppelt gemoppelt mit einer neuen Policy für die betreffende OU versucht - zog er dennoch nicht. Dann habe ich die Einstellungen an einem anderen Client händisch exportiert und an diesem Client importiert. Steht dort jetzt also drin mit dem NT5DS - interessiert ihn dennoch nicht. Heute morgen habe ich ihn mal (erfolgreich) aus der Domäne raus und wieder mit einem anderen Rechnernamen rein - brachte auch nichts. Vielleicht ist das auch einfach der "Härtefall" den ich mir da rausgepickt habe zum Testen, Muss jetzt mal von "Rechner zu Rechner" schauen. Aktuell heute morgen 11 XP Problemfälle. Ich verstehe auch nicht, wie überhaupt die Clients auf diese Uhrzeiten kommen. Wenn sie nicht syncen, müssten sie sich doch aber die Uhrzeit merken über die "Hardware-Uhr" (Puffer) nach einmaligem manuellem net time /set /yes Befehl!? Die haben aber meistens die Uhrzeit vom ca. shutdown des Vortags oder aber auch was ganz wildes. Wobei ich das ganz wilde noch besser "verstehe" (dann anscheinend kein Hardware Puffer) als die Variante mit dem Vortag ... Aktuell überlege ich den unschönen Weg über eine Batch-Datei mit dem net time Befehl im Autostart, damit es mal irgendwie "gelöst" ist ... Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 21. März 2019 Melden Teilen Geschrieben 21. März 2019 (bearbeitet) net time /set /yes ist seit Windows 2000 nicht mehr valide. Seit Windows 2000 und dem AD wird w32time zur Zeitsynchronisierung verwendet. Wen der Dienst falsch konfiguriert ist, geht es nicht, Alles Andere kann ich nicht beurteilen. Wenn die Uhr im ausgeschalteten Zustand nicht mehr weiterläut oder die Zeit vergisst, ist die Batterie leer oder defekt. Austauschen oder neue Hardware kaufen. Es kann auch sein, dass eine der Anwendungen dort meint W32Time umkonfigurieren zu müssen. Oder die User haben zu viele Rechte oder es ist Malware drauf, oder, oder, oder... bearbeitet 21. März 2019 von zahni Zitieren Link zu diesem Kommentar
Werotex 10 Geschrieben 5. April 2019 Autor Melden Teilen Geschrieben 5. April 2019 (bearbeitet) Sooo, natürlich hatte ich das Problem doch mit allen Clients der Domäne, was in der letzten Zeit dann öfters zu Fehlermeldungen unseres Servermonitorings (von Server 2008 R2 - 2016 alles dabei) geführt hat - zumeist nachts natürlich - wenn es da dann einen größeren "Offset" gab ... und natürlich war zwischenzeitlich auch ausgerechnet der Win 7 Client meines Chefs "quer", während es insgesamt eigentlich auf Client-Seite eher ruhig blieb. Also dem Thema endlich nochmal richtig Zeit gewidmet, nachdem ich z.B. sowas hier gesehen habe (siehe Bildanhänge), Also nach dem Link zu "Gruppenrichtlinien" vorgegangen, über den man auch immer wieder stolpert, wenn man nach solchen Problemen googelt. Und siehe da, zumindest MEIN Client kann aktuell schon mal wieder seine Uhrzeit syncen! Rest muss ich jetzt gucken. Danke zahni soweit schon mal !!! Jetzt hätte ich noch die Frage ob das passt, wenn ich den Befehl w32tm /monitor an meinem Client eingebe und unter der RefID nur beim entsprechend jetzt neu konfigurierten PDC / Zeitserver etwas steht, NICHT aber bei den beiden anderen (da steht weiterhin noch "nicht angegeben / nicht synchronisiert") - siehe 3tes Bild !!?? Das mit dem "local" ist dabei übrigens "korrekt" - ich hole die Uhrzeit vom Zeitserver einer anderen Domäne mit Vertrauensstellung / einem anderen Netz, also "interne" IP auch in dem Fall, kein Hostname (im Internet) ... das war schon immer so, weil die Uhrzeiten auch mit denen zusammenpassne müssen ... bearbeitet 5. April 2019 von Werotex Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 5. April 2019 Melden Teilen Geschrieben 5. April 2019 (bearbeitet) Das "mit der anderen Domäne" verstehe ich nicht. Was steht denn jetzt in der Registry? Wenn Du die Zeit "woanders" holen möchtest, musst Du den PDC-Emulator (und nur den) mit dem externen NTP-Server synchronisieren. Nochmal: wenn man eine Domäne installiert, muss gegenüber dem "Default" nichts geändert oder umkonfiguriert werden. Ausnahme: Der DC mit der FSMO-Rolle PDC-Emulator. Der holt sich die Zeit von einem externen NTP-Server oder wird sonstwie synchronisiert. Wenn es verbastelt ist, hier lesen: https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo/ Der resync sieht so aus: w32tm /resync Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet. Der Befehl wurde erfolgreich ausgeführt. Danach einen Blick in das Eventlog werfen. bearbeitet 5. April 2019 von zahni Zitieren Link zu diesem Kommentar
daabm 1.184 Geschrieben 5. April 2019 Melden Teilen Geschrieben 5. April 2019 www.gruppenrichtlinien.de - Mark hat nen guten Artikel, wie man das per GPO dauerhaft und zuverlässig regelt... Zitieren Link zu diesem Kommentar
NorbertFe 1.799 Geschrieben 5. April 2019 Melden Teilen Geschrieben 5. April 2019 Du meinst den link über deinem posting? ;) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.