WSUS GPO RegKeys fehlen plötzlich bei einigen Clients

[phatair 39]

Hallo zusammen,

 

wir haben aktuell folgendes sporadisches Problem.

Auf einigen Windows 10 22H2 (10.0.19045.3448) Clients fehlen plötzlich die WSUS GPO Einträge bzw. der komplette Schlüssel in der Registry -> "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"

Damit greifen die Clients auf Windows Update zu und es wird z.B. auch das Windows 11 Update beworben.

Im WSUS stehen die Clients dann auch "Client hat sich seit x Tagen nicht mehr gemeldet" drin.

 

Prüft man per gpresult /r  die GPOs auf dem Client, ist die GPO aber noch zugewiesen.

Ebenso zeigt gpresult /h <pfad> auf dem Client an, dass die WSUS GPO übernommen wurde

Prüft man aber eben den Regpfad, fehlt der komplette WindowsUpdate Ordner/Schlüssel.

 

Führt man ein gpupdate /force durch, wird der Regestry Eintrag wieder gesetzt und alles funktioniert wie es soll. Wie man ja aber bei Gruppenrichtlininen.de gelernt hat, soll man force nur im Ausnahmefall nutzen :) 

Ich verstehe nicht, warum plötzlich bei einigen Clients dieser Eintrag nicht mehr per GPO gesetzt wird bzw. verschwindet.

 

Hat hier jemand eine Idee?

Vielen Dank.

Grüße,

Steffen

 

bearbeitet 4. Oktober 2023 von phatair

[NorbertFe 2.061]

vor 9 Minuten schrieb phatair:

soll man force nur im Ausnahmefall nutzen :) 

Das ist ja jetzt so ein Ausnahmefall, ansonsten würden die ja nicht verschwinden. Heißt, deine GPOs funktionieren korrekt und du musst jetzt den Grund finden, der den entsprechenden Registry-Bereich leert.

 

Bye

Norbert

[zahni 554]

Vielleicht hat der lokale Anwender zu viele Rechte?

[phatair 39]

vor 3 Minuten schrieb zahni:

Vielleicht hat der lokale Anwender zu viele Rechte?

Die Lösung wäre zumindest nachvollziehbar :) Aber nein, bei uns hat kein User lokale Adminrechte.

 

vor 25 Minuten schrieb NorbertFe:

Das ist ja jetzt so ein Ausnahmefall, ansonsten würden die ja nicht verschwinden. Heißt, deine GPOs funktionieren korrekt und du musst jetzt den Grund finden, der den entsprechenden Registry-Bereich leert.

 

Bye

Norbert

Ich habe gerade mal im Eventlog nachgeschaut. An dem Tag, seit dem sie sich am WSUS nicht mehr gemeldet haben, wurde microsoft update health tools installiert.

Das ist bei 2 Clients identisch, bei denen wir heute festgestellt haben, dass die GPO Einträge fehlen.

 

Nun muss ich mal schauen woher dieses komische MS Tool kommt. Das ist nichts was wir verteilen.

Vielleicht ist das ein Ansatz.

[Sunny61 807]

Über den WSUS wird das Tool nicht zur Verfügung gestellt, kommt nur via MU/WU. Da ist wohl irgendwas faul bei euch.

https://support.microsoft.com/de-de/topic/kb4023057-aktualisieren-von-integritätstools-windows-update-service-komponenten-fccad0ca-dc10-2e46-9ed1-7e392450fb3a

[phatair 39]

Guten Morgen,

 

bei dem Punkt mit dem MS Update Health Tool hatte ich einen Denkfehler.

Das Tool wurde installiert, da der Client davor seine Verbindung zum WSUS verloren hatte. Das Tool war also nicht der Grund für das Problem sondern eher das Resultat.

Ich habe nun mal geprüft auf wievielen Clients dieses Tool installiert wurde. Es ist auf 10 von 200 Clients vorhanden. Es betrifft (aktuell) also nur eine kleine Anzahl von Clients.

 

Hier habe ich auch einen identisches Problem bei MS gefunden

https://learn.microsoft.com/en-us/answers/questions/1145329/windows-update-and-wsus-registry-configuration-ran

 

Ich prüfe nun, ob es an unserem neuen ZCM Agent liegen könnte. Der bietet auch ein Patch Management, welches wir aber nur für Third Party Software nutzen und nicht für MS Updates,

 

Ich werde nun erstmal auf den betroffenen Clients die Software wieder deinstallieren.

Ebenso werde ich über ZCM ein Bundle laufen lassen, welches prüft ob der RegKey vorhanden ist. Wenn nein, wird ein gpupdate /force ausgeführt.

 

So ist zumindest aktuell mal sichergestellt, dass alle Clients welche die WSUS Verbindung verloren haben, auch wieder angebunden werden.

 

Falls ich den Grund für das Problem finde, werde ich den Beitrag hier aktualisieren. 

[Sunny61 807]

vor einer Stunde schrieb phatair:

Wenn nein, wird ein gpupdate /force ausgeführt.

Immer die 3rd Party Software. ;)

 

BTW: Es reicht ein gpupdate /target:computer ganz sicher aus. ;)

[NorbertFe 2.061]

vor 1 Minute schrieb Sunny61:

Es reicht ein gpupdate /target:computer ganz sicher aus. ;)

vermutlich nicht, denn wenn die Registrywerte gelöscht werden ist der Computer ja weiterhin der Meinung er hätte die GPOs bereits übernommen. Da fehlt in dem Fall also dann tatsächlich das /force.

[Sunny61 807]

Wenn ich die Werte manuell lösche und ein gpupdate /target:computer laufen lasse, werden die Werte wieder eingetragen.

[phatair 39]

Am 5.10.2023 um 10:10 schrieb Sunny61:

BTW: Es reicht ein gpupdate /target:computer ganz sicher aus. ;)

Es ist in der Tat so, man muss ein gpupdate /force machen. Ein gpupdate /target:computer reicht leider nicht (wie von NorbertFE schon vermutet).

 

Wir sind immer noch auf der Suche nach der Ursache. Aber der Support von ZenWorks meinte auch, dass es möglicherweise am Client liegen könnte.

bearbeitet 6. Oktober 2023 von phatair

[NorbertFe 2.061]

Immer wenn ich zenworks höre muss ich an diesen schlimmen netware Client von Anfang der 2000er denken. Der hat solche Fehler auch nachweislich verursacht. ;)

[phatair 39]

vor 36 Minuten schrieb NorbertFe:

Immer wenn ich zenworks höre muss ich an diesen schlimmen netware Client von Anfang der 2000er denken. Der hat solche Fehler auch nachweislich verursacht. ;)

Das war vor meiner Zeit

 

Aber als Client Management System funktioniert ZCM recht gut. Mal abgesehen von dem WSUS Problem, wenn das jetzt davon kommen sollte.

Aber wir setzen es schon seit gut 10 Jahren ein und bisher hat das immer sehr gut funktioniert.

 

Mal schauen was jetzt dabei rauskommt.

Schönes Wochenende zusammen.

[daabm 1.366]

Am 6.10.2023 um 12:16 schrieb phatair:

Es ist in der Tat so, man muss ein gpupdate /force machen. Ein gpupdate /target:computer reicht leider nicht (wie von NorbertFE schon vermutet).

 

Dann habt Ihr für Registry "auch ohne Änderungen übernehmen" nicht aktiviert: https://gpsearch.azurewebsites.net/#327

Wenn das nicht aktiviert ist, werden unveränderte GPO-Inhalte nur mit /force erneut verarbeitet.

[NorbertFe 2.061]

Natürlich. :)

[phatair 39]

vor 16 Stunden schrieb daabm:

 

Dann habt Ihr für Registry "auch ohne Änderungen übernehmen" nicht aktiviert: https://gpsearch.azurewebsites.net/#327

Wenn das nicht aktiviert ist, werden unveränderte GPO-Inhalte nur mit /force erneut verarbeitet.

Danke für den Hinweis.

Die Einstellung war mir noch gar nicht bekannt.

 

Eine Frage hätte ich aber dazu.

Ich kann in der Einstellung ja wählen, ob die bestehenden GPOs nur 

- bei User an und Abmeldung bzw. Computer Neustart angewendet werden

- oder auch während der Nutzung 

 

Diese Einstellung bezieht sich ja nur auf Registry Einträge.

Wie unterscheidet sie sich dann technisch von einem gpupdate /force? Wenn man gpupdate /force eigentlich nicht anwenden soll, da alle GPOs eben neu geschrieben werden. Das würde diese Einstellung dann ja regelmäßig machen.

 

Aber für mich klingt diese Einstellung sehr sinnig, da man damit sicherstellt, dass vorgeschriebenen Einstellungen auch immer aktiv sind.

 

Ich hätte nun die beiden Optionen in der Einstellung wie folgt konfiguriert

- Do not apply during periodic background processing -> nicht angehakt -> Änderungen oder neue GPOs sollen ja durchaus im Hintergrund verarbeitet werden

- Process even if the Group Policy objects have not changed -> angehakt -> Damit eben GPOs auch angewendet werden, wenn Sie nicht verändert wurden, um sicherzustellen, dass diese immer auf dem Client wirken

 

Oder habe ich hier was missverstanden?