Jump to content

GPOs ziehen auf den Clients nicht


Direkt zur Lösung Gelöst von tesso,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Gerade eben schrieb NorbertFe:

Vielleicht schaust du ja erstmal, was deine primäre Zeitquelle (der PDC Emulator) so ausspuckt? Wenn der nicht die korrekte Zeit verteilt, dann brauchst am Client nicht suchen, denn dann suchst du an der falschen Stelle.

mache ich später, muß kurz mal weg.
Aber dennoch müssten doch alle PCs und der DC die gleiche Zeit haben. Oder?

 

Link zu diesem Kommentar
vor einer Stunde schrieb NorbertFe:

Oder! Wie du siehst.

Was steht denn im Eventlog des PDC Emulators?

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.

 

 

bearbeitet von Akcent
Link zu diesem Kommentar
vor 34 Minuten schrieb NorbertFe:

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.

bearbeitet von Akcent
Link zu diesem Kommentar
vor 5 Minuten schrieb tesso:

Was ist denn der Stand?

 

GPOs kommen an oder nicht?

Funktioniert das Report der GPO remote und/oder (nur) lokal?

Zeitabgleich funktioniert oder nicht?

 

Uhrzeiten sind immer noch 5min unterschiedlich.
gpresult /h rr.html liefert:
FEHLER: Zugriff verweigert.

GP Result über die GPO Verwaltung bringt "Unbekannter Fehler"

 

Link zu diesem Kommentar

Geht es etwas ausführlicher?

gpresult als welcher NUtzer ausgeführt? mit "ausführen als admin"-Konsole oder nicht?

 

Ihr habt anscheinend etwas mit wmi verbogen. Vielleicht hilft reset von wmi auf einem Client.

 

Die Zeitunterschiede würde ich erstmal hinten anstellen. Löse erst einmal dein GPO Problem. Wenn das wieder funktioniert, dann das Zeitproblem.

Reden wir von physischen Clients oder VMs? Sind auch Server betroffen?

 

Link zu diesem Kommentar
vor 25 Minuten schrieb tesso:

Geht es etwas ausführlicher?

gpresult als welcher NUtzer ausgeführt? mit "ausführen als admin"-Konsole oder nicht?

 

Ihr habt anscheinend etwas mit wmi verbogen. Vielleicht hilft reset von wmi auf einem Client.

 

Die Zeitunterschiede würde ich erstmal hinten anstellen. Löse erst einmal dein GPO Problem. Wenn das wieder funktioniert, dann das Zeitproblem.

Reden wir von physischen Clients oder VMs? Sind auch Server betroffen?

 

gpresult als Admin (cmd als Admin ausführen) durchgeführt.

WMI haben wir noch nie was gemacht und sehen auch normal aus

 

26-03-_2020_16-20-14.jpg.b0b949d4fd2c510003516ae2b67531d6.jpg

 

Der Fehler ist auf mehreren Clients und alle Clients sind physikalisch. Nur der DC ist virtualisiert.

 

bearbeitet von Akcent
Link zu diesem Kommentar
vor einer Stunde schrieb tesso:

Dann versuche auf einem Client das windows Management zurückzusetzen.

Danach gpupdate und schaur was das gpresult sagt.

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)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...