Jump to content

Akcent

Members
  • Content Count

    41
  • Joined

  • Last visited

Community Reputation

10 Neutral

About Akcent

  • Rank
    Newbie
  1. ja auch diese 2.GPO und die kommt auch an auf den PCs die ich mir eben mal angeschaut habe das gleiche Fehlerbild beim Resync. Uhrzeiten bei allen unterschiedlich 1 PC passt 1 PC 8 geht min vor 1 PC 4 geht min vor
  2. Wir haben nur einen DC Habe ich gemacht und auch wie tesso vorgeschlagen hat den Client neu gestartet und ein neues Sync angestoßen. Ergebnis: C:\>w32tm /resync Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet. Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren. Dieser Client geht 5min vor
  3. Hi Norbert. da sieht das so aus: Ich befürchte, daß hier der Haken noch raus muß.
  4. Hallo, zufällig ist uns aufgefallen, daß die Clients in unserem Netzwerk unterschiedliche Zeiten haben. Wir haben einen DC (als Hyper-V VM) und 10 phy. Windows 10 Clients (1909) Die GPO wurde überprüft und gemäß einer Empfehlung von @NorbertFe überprüft / gesetzt. Diese greifen auch, aber die Clients haben unterschiedliche Zeiten (Delta 2 - 5 Min) Überprüft man auf den Clients per w32tm /query /source bekommt man nicht den DC (PDC Emulator) als Quelle zurück sondern Local CMOS Clock Hat dazu ggf. jemand ein Idee warum die Clients nicht alle die gleiche Uhrzeit haben? Gruß, Herry
  5. hatte doch geschrieben, daß ich gpupdate bereits gemacht und nun auch gpresult funktioniert Den Link zu den GPO's hatte ich doch schon 1:1 übernommen :-( oh .... Danke @tesso
  6. WOW .... da war in der Tat das WMI defekt. Habe zuerst mit diesen Befehlen geprüft winmgmt /verifyrepository winmgmt /salvagerepository Beide gaben alles OK zurück. Dann habe ich den WMI Deinst beendet und das Reposity Verzeichnis umbenannt Danach mit Winmgmt /resetrepository zurück gesetzt. PC neu gestartet und gpupdate /force und gpresult /h c:\temp\r.html Und nun kam kein Fehler und der Bericht wird auch erzeigt. Auch über die Gruppenrichtlinienverwaltung kann nun ein Bericht erzeugt werden und hier sieht man auch das die GPO für die Zeiteintsellung angewendet wurde. Klasse und Danke Norbert. Das Problem mit der unterschiedlichen Zeit habe ich aber immer noch (auch nach Restart des Zeit-Dienstes) w32tm /query /status Sprungindikator: 3(nicht synchronisiert) Stratum: 0 (nicht angegeben) Präzision: -23 (119.209ns pro Tick) Stammverzögerung: 0.0000000s Stammabweichung: 0.0000000s Referenz-ID: 0x00000000 (nicht angegeben) Letzte erfolgr. Synchronisierungszeit: nicht angegeben Quelle: Local CMOS Clock Abrufintervall: 10 (1024s)
  7. gpresult als Admin (cmd als Admin ausführen) durchgeführt. WMI haben wir noch nie was gemacht und sehen auch normal aus Der Fehler ist auf mehreren Clients und alle Clients sind physikalisch. Nur der DC ist virtualisiert.
  8. Uhrzeiten sind immer noch 5min unterschiedlich. gpresult /h rr.html liefert: FEHLER: Zugriff verweigert. GP Result über die GPO Verwaltung bringt "Unbekannter Fehler"
  9. leider keine Änderung. Kurze Info noch. Alle Server und Clients werden per Server-Eye gemanaged und gepatched. Alle haben die aktuellen WIndows-Patches. Durch Server-Eye ist das Problem auch festgestellt worden.
  10. So, habe Deinen Link über Gruppenrichtlinien.de abgearbeitet. Auf dem PDC Emulator steht im Eventlog: "Der Zeitdienst synchronisiert die Systemzeit mit folgender Zeitquelle: pool.ntp.org (ntp.m|0x0|0.0.0.0:123->144.76.76.107:123)." Auf den Clients habe ich gpupdate /force angewendet und dann auch da mal den Zeit-Dienst neu gestartet. Da steht: Der Zeitanbieter 'VMICTimeProvider' hat angegeben, dass die aktuelle Hardware- und Betriebssystemumgebung nicht unterstützt wird und beendet wurde. Dieses Verhalten wird für VMICTimeProvider in Nicht-HyperV-Gastumgebungen erwartet. Dies kann auch das vom aktuellen Anbieter erwartete Verhalten in der aktuellen Betriebsumgebung sein. Die Clients sind aber keine VM's w32tm /query /source auf den Clients ergibt immer noch "Local CMOS Clock" w32tm /query /status ergibt: Sprungindikator: 3(nicht synchronisiert) Stratum: 0 (nicht angegeben) Präzision: -23 (119.209ns pro Tick) Stammverzögerung: 0.0000000s Stammabweichung: 0.0000000s Referenz-ID: 0x00000000 (nicht angegeben) Letzte erfolgr. Synchronisierungszeit: nicht angegeben Quelle: Local CMOS Clock Abrufintervall: 10 (1024s) Die GPO wurde erfolgreich in die Registry übernommen.
  11. schaue ich mir an. Habe eben mal auf dem Server geschaut. Da sieht es so aus.
  12. mache ich später, muß kurz mal weg. Aber dennoch müssten doch alle PCs und der DC die gleiche Zeit haben. Oder?
  13. jetzt wird es interessant. Danke Norbert. Da stimmen die Werte mit der GPO überein. Komischer weise haben 6 Clients unterschiedliche Zeiten. PC1 = 9:37 PC2 = 9:44
×
×
  • Create New...