29
WSUS Status eines Updates ändern
Guten Morgen allerseits,
im Rahmen von Meltdown und Spectre wurde von Microsoft ja das Update KB4056892 rausgegeben. Dieses wurde vom WSUS auch brav herunter geladen und zur Installation freigegeben.
Doch da die Änderungen des Registry-Keys durch TrendMicro, bzw. mich direkt erst nach der Veröffentlichung durchgeführt wurde, steht das Update nun im Status "Nicht erforderlich".
Im Moment installiere ich das Update manuell an jedem Client, doch an manche komme ich nicht heran, da diese in Dauerbenutzung sind.
Wie ändere ich den Status im WSUS, so dass die Updates installiert werden?
Die Lösung mit dem Startskript per GPO verteilt habe ich auch gefunden, jedoch würde ich eine WSUS Verteilung eleganter finden.
Das Problem tritt nur bei den Bestandsrechnern auf. Frisch installierte Systeme ziehen das Update sofort.
Gruß
Looser
im Rahmen von Meltdown und Spectre wurde von Microsoft ja das Update KB4056892 rausgegeben. Dieses wurde vom WSUS auch brav herunter geladen und zur Installation freigegeben.
Doch da die Änderungen des Registry-Keys durch TrendMicro, bzw. mich direkt erst nach der Veröffentlichung durchgeführt wurde, steht das Update nun im Status "Nicht erforderlich".
Im Moment installiere ich das Update manuell an jedem Client, doch an manche komme ich nicht heran, da diese in Dauerbenutzung sind.
Wie ändere ich den Status im WSUS, so dass die Updates installiert werden?
Die Lösung mit dem Startskript per GPO verteilt habe ich auch gefunden, jedoch würde ich eine WSUS Verteilung eleganter finden.
Das Problem tritt nur bei den Bestandsrechnern auf. Frisch installierte Systeme ziehen das Update sofort.
Gruß
Looser
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 362060
Url: https://administrator.de/contentid/362060
Printed on: April 18, 2024 at 15:04 o'clock
29 Comments
Latest comment
Hi.
Du musst nur warten, bis der Client erneut detektiert - am WSUS musst du überhaupt nichts tun.
Du musst nur warten, bis der Client erneut detektiert - am WSUS musst du überhaupt nichts tun.
Da passiert aber seit Tagen nichts...... Die Änderungen sind schließlich schon 2 Wochen her...
Dann musst Du wohl am Client mal manuell prüfen, was da los ist.
->zieht er noch defender updates (zur Not mal Defender anschalten)?
->sind die Registrykeys wirklich gesetzt worden?
Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"
Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”
Data="0x00000000”
->zieht er noch defender updates (zur Not mal Defender anschalten)?
->sind die Registrykeys wirklich gesetzt worden?
Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"
Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”
Data="0x00000000”
Der Registry Key wird erfolgreich per GPO erzwungen.
Der WSUS lädt keine Defender Updates (weil in den Produkten nicht angewählt).
Defender ist ebenfalls per GPO abgeschaltet, weil TrendMicro im Einsatz.
Der WSUS lädt keine Defender Updates (weil in den Produkten nicht angewählt).
Defender ist ebenfalls per GPO abgeschaltet, weil TrendMicro im Einsatz.
Wenn Du den Defender nicht anschalten magst zum Test, dann gehe so vor:
Dann erneut detektieren.
Nicht selten spinnen Clients ja und dieser Updatecacheordner ist korrupt. Der Befehl löscht ihn.
net stop wuauserv & rd c:\Windows\SoftwareDistribution /s /q & net start wuauservNicht selten spinnen Clients ja und dieser Updatecacheordner ist korrupt. Der Befehl löscht ihn.
Probiere ich gleich aus.....Danke.
Nach dem Löschen kann eine Neudetection bis zu 10 Minuten dauern - nicht wundern.
So. Hab ich getestet und hat leider nicht zum gewünschten Ergebnis geführt.
Ich habe außerdem noch festgestellt, dass sich die Clients mit der falschen Windows-Versionsnummer beim WSUS melden.
Installiert ist 16299.192, angezeigt wird aber 16299.98.
Ich bin kurz davor den WSUS nochmal neu aufzusetzen.....
Ich habe außerdem noch festgestellt, dass sich die Clients mit der falschen Windows-Versionsnummer beim WSUS melden.
Installiert ist 16299.192, angezeigt wird aber 16299.98.
Ich bin kurz davor den WSUS nochmal neu aufzusetzen.....
Dafür setzt man den doch nicht neu auf. Nimm bitte mal wuinstall in der Testversion zur Hand und teste damit.
Das Tool gibt zurück, dass alles installiert wurde (was auch stimmt; Update ist per Hand installiert). Fehlerhafte Version bleibt.
dass sich die Clients mit der falschen Windows-Versionsnummer beim WSUS melden.
Installiert ist 16299.192, angezeigt wird aber 16299.98.Den Fehler habe ich auch auf WSUS 2012R2! Ist mir nicht aufgefallen, da Spalte ausgeblendet. Das hat aber nichts mit den Januarupdates zu tun - mein eigener Bürorechner hatte den Patch sofort bekommen, ohne Probleme und trotzdem weiterhin im WSUS auf .98
...Microsoft halt.
Ok. Vielleicht liegt da der Hund begraben.
laut wsus.de ist die angezeigte Versionsnummer nicht die des OS, sondern die des WU-Agents. Von daher wäre die Welt zumindest an dieser Stelle in Ordnung.
Bzgl. der nicht installierten Updates habe ich mir jetzt mit einer manuellen Installation beholfen.
Mal sehen, ob jetzt die nächsten monatlichen Updates automatisch gezogen werden. Dann wäre da wieder alles im Lot. Ansonsten muss ich da nochmal ran. Daher jetzt hier erstmal zu.
Bzgl. der nicht installierten Updates habe ich mir jetzt mit einer manuellen Installation beholfen.
Mal sehen, ob jetzt die nächsten monatlichen Updates automatisch gezogen werden. Dann wäre da wieder alles im Lot. Ansonsten muss ich da nochmal ran. Daher jetzt hier erstmal zu.
laut wsus.de ist die angezeigte Versionsnummer nicht die des OS, sondern die des WU-Agents
Gut zu wissen. Habe ich geprüft (Dateiversion von c:\windows\system32\wuauclt.exe) - stimmt.
So. Ich habe heute nochmal den WSUS geprüft. Es werden manche erforderliche Updates nicht gezogen, andere wichtige Updates nicht verteilt.
Bei 2 neu hinzugefügten Clients funktioniert es hingegen. Von daher gehe ich von einer defekten WSUS DB aus.
Ich werde den WSUS in den nächsten Tagen mal neu aufsetzen und dann nochmal prüfen.
Bei 2 neu hinzugefügten Clients funktioniert es hingegen. Von daher gehe ich von einer defekten WSUS DB aus.
Ich werde den WSUS in den nächsten Tagen mal neu aufsetzen und dann nochmal prüfen.
Von daher gehe ich von einer defekten WSUS DB aus
Das würde ich nicht tun. Gut, deine Entscheidung.
Alternativen?
Wenn die Updates an anderen Rechnern vom WSUS bezogen werden können, dann ist mit dessen Datenbank nichts defekt. Die DB interessiert sich nicht die Bohne dafür, welcher Client das ist. Was sagt wuinstall denn mittlerweile? Findet der auch nichts? Dann repariere den Client per inplace-Upgrade und detektiere dann neu.
Liste zunächst mal die Updates, welche nicht detektiert werden.
Liste zunächst mal die Updates, welche nicht detektiert werden.
WUInstall hat auf einem 2016 Server ein Update installiert, welches der WSUS nichtmal angeboten hat (KB4057142).
Auf einem Client (1709) hat er ebenfalls ein Update installiert, welches nicht auf dem WSUS liegt (KB4058258) - hier nur über die Funktion "Online nach Updates suchen".
Andere Updates, die der WSUS bereit hält (KB40744608) werden den Clients nicht angeboten, obwohl diese zum OS passen.
Irgendwie ist seit Dezember da der Wurm drin.....
Auf einem Client (1709) hat er ebenfalls ein Update installiert, welches nicht auf dem WSUS liegt (KB4058258) - hier nur über die Funktion "Online nach Updates suchen".
Andere Updates, die der WSUS bereit hält (KB40744608) werden den Clients nicht angeboten, obwohl diese zum OS passen.
Irgendwie ist seit Dezember da der Wurm drin.....
Also das 4074608 Update ist von gestern, das weißt Du schon? Ist es überhaupt schon bewilligt? (Geht hier).
"Auf einem Client (1709) hat er ebenfalls ein Update installiert, welches nicht auf dem WSUS liegt (KB4058258) - hier nur über die Funktion "Online nach Updates suchen"." - was ist daran bemerkenswert?
"Auf einem Client (1709) hat er ebenfalls ein Update installiert, welches nicht auf dem WSUS liegt (KB4058258) - hier nur über die Funktion "Online nach Updates suchen"." - was ist daran bemerkenswert?
Zitat von @DerWoWusste:
Also das 4074608 Update ist von gestern, das weißt Du schon? Ist es überhaupt schon bewilligt? (Geht hier).
Also das 4074608 Update ist von gestern, das weißt Du schon? Ist es überhaupt schon bewilligt? (Geht hier).
Das ist zur Installation freigegeben. Das er das nicht installiert, liegt an der GPO, soviel habe ich schon rausgefunden (Installationstag).
"Auf einem Client (1709) hat er ebenfalls ein Update installiert, welches nicht auf dem WSUS liegt (KB4058258) - hier nur über die Funktion "Online nach Updates suchen"." - was ist daran bemerkenswert?
Ich kann Dir grad nicht folgen.....ich seh den Wald vor lauter Bäumen nicht mehr.....
Ich kann Dir nicht folgen, ebenso.
Wenn Du ein Update hast, was laut Deinen Worten "nicht auf dem WSUS liegt (KB4058258)", wie soll er es dann vom WSUS holen (du wirst mir zustimmen)? Wenn man nun aber online sucht, klar, da findet er es - deswegen wundere ich mich, warum du das überhaupt schreibst.
Wenn Du ein Update hast, was laut Deinen Worten "nicht auf dem WSUS liegt (KB4058258)", wie soll er es dann vom WSUS holen (du wirst mir zustimmen)? Wenn man nun aber online sucht, klar, da findet er es - deswegen wundere ich mich, warum du das überhaupt schreibst.
Genau so verhält es sich......da frage ich mich nur: Warum zieht der WSUS das Update nicht von den MS Servern, wo andere gezogen werden?
Mir scheint, dass es irgendwann im Dezember einen Knoten gegeben hat, der nicht mehr nachzuvollziehen ist.
Ich habe in der Zwischenzeit einen Client mit einem In-Place-Upgrade versorgt und erneut suchen lassen. Das Ergebnis ist wie erwartet, nämlich dass er die erforderlichen Updates "2018-01...." nicht angeboten bekommt.
Hier scheint es einen Unterschied zwischen PCs, die schon länger in der Domain sind und frisch hinzugefügten PCs zu geben. Daher meine Vermutung mit der DB.
Mir scheint, dass es irgendwann im Dezember einen Knoten gegeben hat, der nicht mehr nachzuvollziehen ist.
Ich habe in der Zwischenzeit einen Client mit einem In-Place-Upgrade versorgt und erneut suchen lassen. Das Ergebnis ist wie erwartet, nämlich dass er die erforderlichen Updates "2018-01...." nicht angeboten bekommt.
Hier scheint es einen Unterschied zwischen PCs, die schon länger in der Domain sind und frisch hinzugefügten PCs zu geben. Daher meine Vermutung mit der DB.
Das Ergebnis ist wie erwartet, nämlich dass er die erforderlichen Updates "2018-01...." nicht angeboten bekommt.
Auf welche Build ist er denn nach Deinem inplaceupgrade (Ausgabe von winver)?Warum zieht der WSUS das Update nicht
Weil Deine gewählten Kategorien es nicht anfordern? Was hast Du alles ausgewählt?
In den Kategorien sind nur die Feature-Updates und die Treiber nicht angehakt.
Das Inplace-Upgrade hat die Version mit der Endung .15, d.h. er müßte jede Menge Updates finden.
Das Inplace-Upgrade hat die Version mit der Endung .15, d.h. er müßte jede Menge Updates finden.
Dann ist es seltsam, da gebe ich Dir Recht.
Ich warte jetzt noch mal ein paar Tage ab, ob sich was ändert.
Dann kann ich den WSUS immer noch neu aufsetzen.
Dann kann ich den WSUS immer noch neu aufsetzen.
So. Ich habe den WSUS restlos vom Server entfernt und anschließend neu aufgesetzt. Bei der Konfiguration ist dann aufgefallen, dass der ESET-AV scheinbar dazwischengrätscht. Da der aber schon vor dem "Problem" drauf war, muss dass mit einem Update des AV passiert sein.
Den deinstalliert und stattdessen den Defender als Minimal-Schutz aktiviert.
Damit funktionierte dann die Konfig ohne weitere Zwischenfälle.
Derzeit lädt der WSUS noch aus dem Netz. Ich hoffe, das Problem ist damit dann endgültig abgestellt.
Gruß
Looser
Den deinstalliert und stattdessen den Defender als Minimal-Schutz aktiviert.
Damit funktionierte dann die Konfig ohne weitere Zwischenfälle.
Derzeit lädt der WSUS noch aus dem Netz. Ich hoffe, das Problem ist damit dann endgültig abgestellt.
Gruß
Looser
Die Neuinstallation des WSUS hat nicht den gewünschten Effekt gebracht.
Nach viel Recherche habe ich im WSUS-Forum den entscheidenden Denkanstoß bekommen:
1. ADMX-Templates (aktuelle) neu installiert
2. GPO für die Clients neu angelegt:
- Automatische Updates konfigurieren = 4
- Internen Pfad für den Microsoft Updatedienst angeben (3x)
- Keine Verbindungen mit Windows Update-Internetadressen herstellen Aktiviert
Seit dem laden die Clients auch die letzten Updates.
Gruß
Looser
Nach viel Recherche habe ich im WSUS-Forum den entscheidenden Denkanstoß bekommen:
1. ADMX-Templates (aktuelle) neu installiert
2. GPO für die Clients neu angelegt:
- Automatische Updates konfigurieren = 4
- Internen Pfad für den Microsoft Updatedienst angeben (3x)
- Keine Verbindungen mit Windows Update-Internetadressen herstellen Aktiviert
Seit dem laden die Clients auch die letzten Updates.
Gruß
Looser
