GPO überschreibt lokale Richtlinie nicht

Hallo,


das Problem wurde schon ein paar Mal besprochen, aber irgendwie immer andersrum.

Ich habe das Problem, dass Rechner im Netz über den WSUS keine Updates ziehen.

Über GPO wird als 'interner Updatedienst' der "WSUSXX" defininiert.

Lokal steht auf vielen Rechner aber noch "WSUSYY", so hieß der Server früher.

Über RSOP.MSC wird mir WSUSXX als aktiv ausgegeben, Fakt ist aber, dass so lange in der lokalen Richtlinie "WSUSYY" drin steht, der Rechner keine Updates zieht.

Wieso übertrumpft die GPO die lokale Richtlinie nicht? Das dürfte doch gar nicht sein.

Irgendjemand eine Idee? Ich bin echt völlig überfragt,


Danke für jeden Tipp.

Klappts denn wenn du am Rechner die GPO manuell aktualisierst?
GPUPDATE /force

Was spuckt denn "gpresult /h gpo.html" auf dem Client aus? Wird die GPO überhaupt gezogen?
Hast du sie auch aktiviert (frage deshalb, weil es mir mal passiert war, dass die GPO deaktiviert war und ich mich gewundert hatte).

rsop oder gpresult sagen beiden "WSUSXX"

gpupdate force ändert nichts an der lokalen Richtlinie, da bleibt drin, was auch immer vorher eingetragen wurde (oder was schon drin stand).

die Richtlinie ist aktiv.


Ich finde es auch reichlich seltsam, aber wir hatten jetzt mehrere Rechner in Folge, bei denen WSUSYY lokal drin stand und nach der Änderung auf WSUSXX fand er (teilweise nach Monaten) das erste Mal wieder Updates.

Daneben haben wir auch das Phänomen, dass er teilweise etlichen Stunden Updates sucht, bis er welche findet. Alles sehr nervig.

Wenn ich das hier richtig verstehe, haben lokale Richtlinien eine hörere Priorität als GPOs. Musst also per Hand WSUSYY von den Clients entfernen.

Stundenlanges Suchen? Bei Windows 7 Clients oder auch Windows 10? Beim Zusammenspiel zwischen WSUS und Windows 10 hatte ich einige Probleme (und stand damit nicht allein auf weiter Flur), bei frisch installierten Windows 7 Clients liegt es wohl am veralteten Update-Client, der erst installiert werden muss (und die Suche dauert ewig).

Windows 7 ist es bei mir. Kann schon mal einen ganzen Tag dauern, bis mir Updates angezeigt werden, auch wenn ich aktiv danach suche.


"Die lokale Sicherheitsrichtlinie ist nur dann uneingeschränkt wirksam, wenn sich der Computer innerhalb einer Arbeitsgruppe befindet. Sobald der Rechner ein Domänenmitglied ist werden die lokalen Sicherheitsrichtlinien von denen der Domäne überstimmt (wie gerade beschrieben)."

Also im Grunde steht auf der Seite auch nicht anders, die Annahme am Anfang des Berichts bezieht sich auf was anderes.

Die wilde Inge schrieb:

Lokal steht auf vielen Rechner aber noch "WSUSYY", so hieß der Server früher.

Zum Vergrößern anklicken....

Wo steht der noch drin?

lokale Richtlinien, also gpedit.msc

Das ist irrelevant. Angewendet wird das, was GPRESULT ausspuckt, weil das lokale Policies und Domain Policies berücksichtigt. Was sagt denn das Windowsupdate.log?

liefere ich Montag nach.

So, ich bin jetzt schon mal eine ganze Ecke schlauer,

ein Blick in die windowsupdate.log hat mir einen 'altbekannten' Fehler offenbart,




Wenn bei uns Rechner ewig keine Updates ziehen wollten, dann habe ich den Update Dienst beendet und den Ordner: %systemroot%\system32\wbem\repository umgenannt, danach den Update Dienst wieder gestartet und kurz danach habe ich Updates bekommen.


Das Wochenende hat jetzt mehrere Unklarheiten beseitigt.

Zum einen greift die GP, ich der lokalen Richtlinie steht nämlich immer noch etwas 'falsches', ich habe das bewusst ausgetestet und den Rechner übers WE einfach laufen lassen.
Und aus der Log habe ich eben o.g. Code ausgelesen und das erste was ich dazu finde ist: Dienst beenden, Ordner umbennen.

D.h. ich hatte die Lösung eigentlich schon zur Hand.

Bei diesem speziellen Testrechner hat die Prozedur aber satte 4 Tage gedauert vom ersten Workaround bis zum tatsächlichen finden der Updates. Allerdings habe ich zwischendurch händisch Updates installiert, vielleicht wurde damit der 22h Counter unterbrochen zur autom. Suchen. Muss ich noch mal in die Log gucken nach wie vielen Stunden er dann tatsächlich etwas gefunden hat.

Mir stellt sich jetzt eher die Frage wie es zu dem Fehler gekommen ist.

Ich finde leider nirgends was es mit der PID oder dem Cookie auf sich hat. Wüsste gerne was den Fehler verursacht hat, als das Symptom zu beheben.