Jump to content

Akcent

Members
  • Content Count

    41
  • Joined

  • Last visited

Everything posted by Akcent

  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
  14. sorry Norbert. Die Einstellungen vom Client habe ich aus den Schlüsseln unter Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Parameters Unter Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders ist nichts konfiguriert.
  15. Sorry, dachte das wäre klar ... Die Reg-Einstellungen sind aus der Registry des Clients. Der andere ist die GPO Einstellung. w32tm ... = auch vom Client
  16. weil ich dachte das fehlte ja am Client kommt das mit local CMOS clock
  17. local CMOS clock habe ich erst danach gemacht.
  18. Hallo, mir ist heute aufgefallen, daß die Zeiten an verschiedenen Clients unterschiedlich sind, obwohl wir eine GPO haben die so eingestellt ist, daß die Clients sich die Zeit vom DC holen sollen. Bei der weiteren Untersuchung kommt mir der Verdacht, daß die GPO gar nicht verarbeitet werden. gpupdate /force läuft zwar fehlerfrei durch, aber bei einem gpresult /h / c:\temp\result.html kommt "Zugriff verweigert". Auch wenn die CMD als Admin gestartet ist Über die Gruppenrichtlinienverwaltung bekommen ich beim Assistenten für die Ergebnisse "Unbekannter Fehler" Stehe gerade etwas auf dem Schlauch, warum die GPO's nicht geladen / angewendet werden. Das ganze betrifft nur die Windows 10 (1909) Clients. Bei den Server ist alles ok. Die Mitglieds-Server sind in der gleichen OU wie die PC's. Gruß, Herry Beim Sicherheitsfilter ist das hier eingestellt
  19. Hallo, wir haben eine Windows 2008 Dom. WLAN läuft über CISCO Controller mit 802.1x Die CA haben wir 2-stufig aufgebaut. 1x Root CA 1x CA-Server für die Anfragen Seit ca. 2 Jahren ist der Root-CA immer Offline (wurde uns damals so empfohlen) und nur hin und wieder einmal eingeschaltet. Seit ein paar Tagen, bekommen aber die Clients keine Zertifikate mehr, wenn der Root-CA Offline ist. Kennt dazu jemand evtl den Grund? Auf dem CA-Server in der Ereignisanzeige lese ich folgenden Eintrag: Die Anforderung 11474 konnte aufgrund eines Fehlers nicht ausgeführt werden: Privater Schlüssel kann nicht archiviert werden. Die Zertifizierungsstelle ist nicht für die Schlüsselarchivierung konfiguriert. 0x8009400a (-2146877430). Die Anforderung bezog sich auf Domäne\ACS-Server (ein CISCO Radius Server). Weitere Informationen: Fehler beim Archivieren des privaten Schlüssels Viele Grüße, Herry
  20. habe heute mal eine Rücksicherung gemacht. Fehler mit dem o.g. Screenshot ist weg. die o.g. Befehle durchgeführ, aber der 23.08.213 steht immer noch da
  21. ja genau habe das Verzeichnis gelöscht und bekomme nun diesen Fehler
  22. Das Ereignis-Log ist sauber und die Updates laufen. Glaube aber nicht, daß die automatische Synchr. läuft. Als letzte Sync. Datum steht immer noch der 23.08.2013 da drin. Screenshot SQL:
×
×
  • Create New...