10
WSUS wird von Clients ignoriert
Moin zusammen,
ich stehe hier derzeit vor einem kleinen Problem. Offenbar ignorieren unsere Windows 10 Clients den WSUS-Server seit einigen Wochen. Aufgefallen ist dies zuerst vor etwa 4 bis 8 Wochen und ich komme dem Grund nicht auf die Schliche. Erstmal die Fakten, was uns dazu veranlasst dies zu vermuten:
Gestern haben sich einige Clients gemeldet, da sie Updates installieren wollen:
Dieses Update ist für den entsprechenden Rechner im WSUS jedoch nicht freigegeben. Dies zeigt die Auswertung des WSUS-Protokolls
Wir haben einige Clients im Netzwerk, die Windows 10 betreiben, aber nicht in der Domäne sind (warum spiel keine Rolle). Diese Clients laden die Updates sofort runter und installieren, unabhängig vom WSUS. Das sich die Windows 10 Clients die Updates von dort holen:
Mir ist bewusst, dass ich den WSUS umgehen kann, wenn dieser keine Updates anzeigt und manuell Online nach Updates suchen kann. Dies ist auf diesem Rechner aber nicht geschehen. Bei einem Anwender würde ich der Aussage prinzipiell erstmal misstrauen, aber es sind Test und Admin-Rechner betroffen, bei denen definitiv nicht manuell nach Updates gesucht wurde. Der Download wurde nicht vom User initiiert und geschah im Hintergrund. Dies zeigt auch die Downloadstatistik der entsprechenden Rechner:
Da die WSUS-Konfiguration im ganzen nicht auf ansehnliche Screenshots passt, hier einmal kurz abgetippt, welche GPOs aktiviert sind und in dem Bereich meiner Meinung nach relevant sind. Nicht relevant ist unter anderem die Option "Erneut zum Neustart für geplante Installation auffordern". Wenn rückfragen zu einer bestimmten Einstellung sind, kurz nachfragen:
Bei der Fehlersuche habe ich keinen Protokolleintrag ausfindig machen können, die auf ein Verbindungsproblem zum WSUS-Server hindeutet. Auch der Eintrag unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate entspricht dem erwarteten Einstellungen der oben beschriebenen GPO.
Also.. jemand einen Tipp, wie ich die Clients wieder dazu bekomme ausschließlich den WSUS zu nutzen? In Anbetracht der Katastrophen, die MS in den letzten Updates verbockt hat, wollen wir die Updates nicht blind und gutgläubig installiert bekommen.
Gruß
Doskias
Nachtrag, weil Vergessen: GPRESULT zeigt, dass die von der GPO erwarteten Einträge angewendet werden und es keine weitere GPO gibt, die die erwarteten Werte überschreibt.
ich stehe hier derzeit vor einem kleinen Problem. Offenbar ignorieren unsere Windows 10 Clients den WSUS-Server seit einigen Wochen. Aufgefallen ist dies zuerst vor etwa 4 bis 8 Wochen und ich komme dem Grund nicht auf die Schliche. Erstmal die Fakten, was uns dazu veranlasst dies zu vermuten:
Gestern haben sich einige Clients gemeldet, da sie Updates installieren wollen:
Dieses Update ist für den entsprechenden Rechner im WSUS jedoch nicht freigegeben. Dies zeigt die Auswertung des WSUS-Protokolls
Wir haben einige Clients im Netzwerk, die Windows 10 betreiben, aber nicht in der Domäne sind (warum spiel keine Rolle). Diese Clients laden die Updates sofort runter und installieren, unabhängig vom WSUS. Das sich die Windows 10 Clients die Updates von dort holen:
Mir ist bewusst, dass ich den WSUS umgehen kann, wenn dieser keine Updates anzeigt und manuell Online nach Updates suchen kann. Dies ist auf diesem Rechner aber nicht geschehen. Bei einem Anwender würde ich der Aussage prinzipiell erstmal misstrauen, aber es sind Test und Admin-Rechner betroffen, bei denen definitiv nicht manuell nach Updates gesucht wurde. Der Download wurde nicht vom User initiiert und geschah im Hintergrund. Dies zeigt auch die Downloadstatistik der entsprechenden Rechner:
Da die WSUS-Konfiguration im ganzen nicht auf ansehnliche Screenshots passt, hier einmal kurz abgetippt, welche GPOs aktiviert sind und in dem Bereich meiner Meinung nach relevant sind. Nicht relevant ist unter anderem die Option "Erneut zum Neustart für geplante Installation auffordern". Wenn rückfragen zu einer bestimmten Einstellung sind, kurz nachfragen:
- Übermittlungsoptimierung: Downloadmodus Einfach (99)
- automatische Updates: autom. herunterladen und installieren, täglich um 10:00 Uhr
- Clientseitige Zuordnung aktiviert
- Interner Pfad für den Microsoft Updatedienst angeben: Interner Updatedienst ist angegeben mit http://name:port. Der gleiche Server wird für die Statistik verwendet. Die Statistik funktioniert und wird gepflegt. Server und Port müssen also korrekt sein. Selbst wenn nicht dürfte die Konfiguration nicht auf das Internet zurückfallen, sondern einfach keine Updates finden.
- Suchhäufigkeit: stündlich
- Zielversion: Windows 10, 21H2
Bei der Fehlersuche habe ich keinen Protokolleintrag ausfindig machen können, die auf ein Verbindungsproblem zum WSUS-Server hindeutet. Auch der Eintrag unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate entspricht dem erwarteten Einstellungen der oben beschriebenen GPO.
Also.. jemand einen Tipp, wie ich die Clients wieder dazu bekomme ausschließlich den WSUS zu nutzen? In Anbetracht der Katastrophen, die MS in den letzten Updates verbockt hat, wollen wir die Updates nicht blind und gutgläubig installiert bekommen.
Gruß
Doskias
Nachtrag, weil Vergessen: GPRESULT zeigt, dass die von der GPO erwarteten Einträge angewendet werden und es keine weitere GPO gibt, die die erwarteten Werte überschreibt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2545744004
Url: https://administrator.de/forum/wsus-wird-von-clients-ignoriert-2545744004.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
10 Kommentare
Neuester Kommentar
Hi,
lass die mal ein Windows-Update Log auf dem Client erstellen und schau dir das mal an.
Wahrscheinlich werden hier bei dir etliche Fehler aufgezeigt die dir weiter helfen können.
Wann haben sich die Clients laut WSUS das letzte mal gemeldet bzw. einen Statusbericht erzeugt?
Gruß
lass die mal ein Windows-Update Log auf dem Client erstellen und schau dir das mal an.
Wahrscheinlich werden hier bei dir etliche Fehler aufgezeigt die dir weiter helfen können.
- PowerShell als Administrator öffnen.
- Den Befehl Get-WindowsUpdateLog eingeben und starten.
- Auf dem Desktop wird nun die WindowsUpdate.log angelegt
Wann haben sich die Clients laut WSUS das letzte mal gemeldet bzw. einen Statusbericht erzeugt?
Gruß
Ich fang mal hinten an:
Hab den Befehl ausgeführt und erspare euch jetzt 25.000 Zeilen Protokolle. Ich weiß nicht genau wonach ich an der Stelle in dem Protokoll suchen soll, aber ich folgendes gefunden:
Ist in meinen Augen unkritisch. Dann hab ich allerdings folgdendes gefunde:
So wie ich es verstehe holt er sich an der Stelle einen Token vom MS-Server. Aber kurz vorher finde ich auch:
Also so wie ich das Protokoll lese findet er ja den WSUS-Server? Hast du vielleicht noch irgendeinen Tipp, nach welcher spezifischen ID ich Ausschau halten könnte/sollte?
Gruß
Doskias
Wann haben sich die Clients laut WSUS das letzte mal gemeldet bzw. einen Statusbericht erzeugt?
Da brauch ich mir glücklicherweise keinen Kopf mehr drum machen. Ich habe ein Skript geschrieben, welches im Monitoring Alarm gibt, wenn ein Online-Rechner sich länger als 48 Stunden nicht am WSUS gemeldet hat. Sprich: Ich lese die WSUS-Logs aus, ermittle den Last-Report-Timestamp und prüfe dann ob der Rechner online ist. Ist er online und der Timestamp ist älter als 48 Stunden, dann gibt es eine Warnung. Passiert selten, derzeit nicht der fall. habe dennoch einmal händisch nachgeschaut, mit dem Ergebnis, dass 8 Rechner sich länger als 36 Stunden nicht am WSUS gemeldet habe. habe die Rechner mal verglichen und kann diese mit den Abwesenden Kollegen als korrekt bestätigen. Also Statusberichte sind alle von heute bei den Kollegen die heute da sind.lass die mal ein Windows-Update Log auf dem Client erstellen und schau dir das mal an.
Wahrscheinlich werden hier bei dir etliche Fehler aufgezeigt die dir weiter helfen können.
Wahrscheinlich werden hier bei dir etliche Fehler aufgezeigt die dir weiter helfen können.
- PowerShell als Administrator öffnen.
- Den Befehl Get-WindowsUpdateLog eingeben und starten.
- Auf dem Desktop wird nun die WindowsUpdate.log angelegt
Hab den Befehl ausgeführt und erspare euch jetzt 25.000 Zeilen Protokolle. Ich weiß nicht genau wonach ich an der Stelle in dem Protokoll suchen soll, aber ich folgendes gefunden:
2022.04.20 08:27:03.3325901 8804 7752 ComApi *FAILED* [80246007] ISusInternal:: IsCommitRequired
2022.04.20 08:27:03.3327228 8804 7752 ComApi Reloading CUpdate B036CF72-8707-4601-B125-7DCDA82AC2D0.1 from datastore...
2022.04.20 08:27:03.3338459 8804 7752 ComApi Deserializing update from serialized BSTR.
2022.04.20 08:27:03.3338570 8804 7752 ComApi Byte length of the input buffer for deserialization: 2421
2022.04.20 08:27:03.3339045 8804 7752 ComApi Deserialized installable update Realtek Semiconductor Corp. - MEDIA - 6.0.9326.1, UpdateID = {B036CF72-8707-4601-B125-7DCDA82AC2D0.1}, CallbackInfo cookie length = 0
2022.04.20 08:27:03.3339224 8804 7752 ComApi Reload successful, UpdateID = B036CF72-8707-4601-B125-7DCDA82AC2D0.1, CallbackInfo cookie length = 0, Current deployment action = 4, New deployment action = 4
2022.04.20 08:27:03.3348405 8804 7752 ComApi Deserializing update from serialized BSTR.
2022.04.20 08:27:03.3348507 8804 7752 ComApi Byte length of the input buffer for deserialization: 2207
2022.04.20 08:27:03.3348973 8804 7752 ComApi Deserialized installable update Realtek - SoftwareComponent - 11.0.6000.269, UpdateID = {614F5F82-79C1-4490-8CE5-F3395590ED4A.1}, CallbackInfo cookie length = 0
2022.04.20 08:27:03.3353882 8804 7752 ComApi *FAILED* [80246007] ISusInternal:: IsCommitRequiredIst in meinen Augen unkritisch. Dann hab ich allerdings folgdendes gefunde:
2022.04.20 08:11:57.6841004 12768 14328 Misc GetUserTickets: No user tickets found. Returning WU_E_NO_USERTOKEN.
2022.04.20 08:11:57.6881763 12768 14328 Misc *FAILED* [80070057] Method failed [AuthTicketHelper::AddTickets:1236]
2022.04.20 08:11:57.6881786 12768 14328 Misc *FAILED* [80092004] Method failed to get auth token. [CUpdateEndpointProvider::GenerateSecurityTokenWithAuthTickets:1674]
2022.04.20 08:11:57.6882446 12768 14328 Misc Acquired new token from Server
2022.04.20 08:11:57.6883048 12768 14328 Misc Got service 8B24B027-1DEE-BABB-9A95-3517DFB9C552 plugin Client/Server auth token of type 0x00000001
2022.04.20 08:11:57.6898382 12768 14328 WebServices Proxy Behavior set to 2 for service url https://fe3cr.delivery.mp.microsoft.com/ClientWebService/client.asmxSo wie ich es verstehe holt er sich an der Stelle einen Token vom MS-Server. Aber kurz vorher finde ich auch:
2022.04.20 08:11:51.2860850 12768 10440 Agent Blocking Windows content for WUfB
2022.04.20 08:11:51.4324970 12768 10440 Misc Got WSUS Client/Server URL: http://Mein-Server:8530/ClientWebService/client.asmx
2022.04.20 08:11:51.4345647 12768 10440 WebServices Proxy Behavior set to 1 for service url http://Mein-Server:8530/ClientWebService/client.asmx
2022.04.20 08:11:51.9176762 12768 10440 ProtocolTalker ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://lo-sec02.lo.local:8530/ClientWebService/client.asmx
2022.04.20 08:11:51.9191908 12768 10440 ProtocolTalker OK to reuse existing configuration
2022.04.20 08:11:51.9191934 12768 10440 ProtocolTalker Existing cookie is valid, just use it
2022.04.20 08:11:51.9191957 12768 10440 ProtocolTalker PTInfo: Server requested registrationAlso so wie ich das Protokoll lese findet er ja den WSUS-Server? Hast du vielleicht noch irgendeinen Tipp, nach welcher spezifischen ID ich Ausschau halten könnte/sollte?
Gruß
Doskias
Im Log kann ich dir leider keine genaue ID nennen. Muss man immer individuell lesen und verstehen
Was sagt das Eventlog eines betroffenen Clients?
Ereignisanzeige ->Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> WindowsUpdateClient
Kommen hier Fehler oder findet er updates? z.B. "Es wurden 1 Updates gefunden."
Was sagt das Eventlog eines betroffenen Clients?
Ereignisanzeige ->Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> WindowsUpdateClient
Kommen hier Fehler oder findet er updates? z.B. "Es wurden 1 Updates gefunden."
Moin,
schmeiß exemplarisch mal den Client aus dem WSUS raus und lass ihn sich anschließend neu am WSUS registrieren.
Ich hatte das auch mal eine Weile, allerdings bei Servern.
IMHO ist nicht der WSUS-Client das Problem, sondernd er WSUS selbst.
schmeiß exemplarisch mal den Client aus dem WSUS raus und lass ihn sich anschließend neu am WSUS registrieren.
Ich hatte das auch mal eine Weile, allerdings bei Servern.
IMHO ist nicht der WSUS-Client das Problem, sondernd er WSUS selbst.
1Zitat von @TheToxic:
Im Log kann ich dir leider keine genaue ID nennen. Muss man immer individuell lesen und verstehen
Schade Im Log kann ich dir leider keine genaue ID nennen. Muss man immer individuell lesen und verstehen
Was sagt das Eventlog eines betroffenen Clients?
Ereignisanzeige ->Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> WindowsUpdateClient
Wie ich Eingangs schon sagte finden sich dort keine Fehler. Zumindest kürzlich nicht. ich habe allerdings am 10.03 in einem Zeitraum von 40 Minuten 18 Update-Fehlermeldungen. Kann natürlich Zufall sein, aber etwa Anfang März sind die Probleme zum ersten mal aufgefallen. Allerdings nicht an diesem Client.Ereignisanzeige ->Anwendungs- und Dienstprotokolle -> Microsoft -> Windows -> WindowsUpdateClient
Kommen hier Fehler oder findet er updates? z.B. "Es wurden 1 Updates gefunden."
Ansonsten finde ich (für heute) nur Einträge mit 0 Updates, bzw. mit 7 Updates. Wobei heute keines installiert wurde und auch keins ausstehend ist. Auf dem WSUS würden derzeit 6 Updates für diesen Client ausstehen... Passt alles nicht so recht.Zitat von @em-pie:
schmeiß exemplarisch mal den Client aus dem WSUS raus und lass ihn sich anschließend neu am WSUS registrieren.
Werde ich mal machen.schmeiß exemplarisch mal den Client aus dem WSUS raus und lass ihn sich anschließend neu am WSUS registrieren.
Ich hatte das auch mal eine Weile, allerdings bei Servern.
Danke für den Hinweis. Hab es exemplarisch an einem Server jetzt überprüft und konnte es dort ebenfalls feststellen.IMHO ist nicht der WSUS-Client das Problem, sondernd er WSUS selbst.
Mal wieder Gruß und Dank soweit
Doskias
Nabend,
kannst du mal deine Konfigurierten Gruppenrichtlinien bzw. die Registry-Schlüssel zur Verfügung stellen?
Deine Konfiguration mischt, so wie ich das sehe, Windows Update for Business (WUfB) und Windows Server Update Services (WSUS). Nimm die Zielversion in den GPO Einstellungen raus. Danach hast du über den WSUS die volle Kontrolle.
Eventuell noch die Thematik des DualScann mal beachten:
https://www.windowspro.de/wolfgang-sommergut/dual-scan-windows-update-bu ...
Gruß
kannst du mal deine Konfigurierten Gruppenrichtlinien bzw. die Registry-Schlüssel zur Verfügung stellen?
Deine Konfiguration mischt, so wie ich das sehe, Windows Update for Business (WUfB) und Windows Server Update Services (WSUS). Nimm die Zielversion in den GPO Einstellungen raus. Danach hast du über den WSUS die volle Kontrolle.
Eventuell noch die Thematik des DualScann mal beachten:
https://www.windowspro.de/wolfgang-sommergut/dual-scan-windows-update-bu ...
Gruß
N'abend
https://www.windowspro.de/wolfgang-sommergut/update-windows-11-gruppenri ...
Die Info aus dem Link hat seit Oktober hervorragend funktioniert und tritt seit März vereinzelt auf und auch in den WSUS-Gruppen, wo sie nicht konfiguriert ist. Es kann also damit nicht wirklich was zu tun haben.
Dies habe ich vorhin an einem nicht betroffenen Client überprüft.
Ich habe mir auch @em-pie Vorschlag angeschaut und einige Clients aus dem WSUS entfernt. Ob das geholfen hat, kann ich erst beim nächsten veröffentlichten Update sagen. Beim nächsten Update via WSUS müsste ja der Wert vom Cache-Server von 0,00 % steigen und die 100% von Microsoft um genau diesen Wert reduziert werden. Da ist dann jetzt erstmal warten angesagt bzw. Ein PS-Skript entwickeln, welches mir alle Rechner nennt, die nicht zu 100% vom WSUS laden, da hier ja dann etwas nicht stimmt.
Gruß
Doskias
Bearbeitungsgrund: Nächtliche Rechtschreibkatastrophe korrigiert
Zitat von @CH3COOH:
Nabend,
kannst du mal deine Konfigurierten Gruppenrichtlinien bzw. die Registry-Schlüssel zur Verfügung stellen?
Welcher Wert fehlt dir? Wie ich oben geschrieben habe, sind Screenshots der GPO sehr unübersichtlich. Sag mir genau welche Einstellung du vermutest und ich liefere die Info. Hier allerdings 3 oder 4 Bilder der GPO Konfiguration zu posten, die überwiegend nichts damit zu tun hat (Thema Neustart, etc.) halte ich nicht für zielführend,Nabend,
kannst du mal deine Konfigurierten Gruppenrichtlinien bzw. die Registry-Schlüssel zur Verfügung stellen?
Deine Konfiguration mischt, so wie ich das sehe, Windows Update for Business (WUfB) und Windows Server Update Services (WSUS). Nimm die Zielversion in den GPO Einstellungen raus.
Das spielt nichts zur Sache, so wie ich es sehe. Wenn du schon Wolfgang Sommergut als Referenz nimmst, dann bitte auch andere Postings von ihm:https://www.windowspro.de/wolfgang-sommergut/update-windows-11-gruppenri ...
Die Info aus dem Link hat seit Oktober hervorragend funktioniert und tritt seit März vereinzelt auf und auch in den WSUS-Gruppen, wo sie nicht konfiguriert ist. Es kann also damit nicht wirklich was zu tun haben.
Eventuell noch die Thematik des DualScann mal beachten:
https://www.windowspro.de/wolfgang-sommergut/dual-scan-windows-update-bu ...
Irrelevant in meinen Augen. Das vierte Bild zeigt deutlich, dass der ganze durch die Updates verursachte Traffic im Hintergrund lief und nicht durch den User initiiert wurde, was wie beschrieben auch auf meinem Testrechnern nicht gemacht wurde, da ich da nicht drauf klicke. Hätte ein anderer User oder Kollege das Update manuell gestartet, dann wäre der Wert Traffic vom Benutzer initiiert nicht mehr N/A, sondern hätte einen Wert.https://www.windowspro.de/wolfgang-sommergut/dual-scan-windows-update-bu ...
Dies habe ich vorhin an einem nicht betroffenen Client überprüft.
Ich habe mir auch @em-pie Vorschlag angeschaut und einige Clients aus dem WSUS entfernt. Ob das geholfen hat, kann ich erst beim nächsten veröffentlichten Update sagen. Beim nächsten Update via WSUS müsste ja der Wert vom Cache-Server von 0,00 % steigen und die 100% von Microsoft um genau diesen Wert reduziert werden. Da ist dann jetzt erstmal warten angesagt bzw. Ein PS-Skript entwickeln, welches mir alle Rechner nennt, die nicht zu 100% vom WSUS laden, da hier ja dann etwas nicht stimmt.
Gruß
Doskias
Bearbeitungsgrund: Nächtliche Rechtschreibkatastrophe korrigiert
Nur zur Ergänzung - ich hatte kürzlich einen Beitrag zum Thema. Neben Dual Scan und WUfB können auch GPOs zum Konflikt führen. Beachtet auch die Nutzerkommentare - vielleicht hilfts.
Falle: Windows-Clients installieren Updates am WSUS vorbei
Falle: Windows-Clients installieren Updates am WSUS vorbei
Danke für die ganzen Tipps. Ich habe jetzt "erstmal" folgendes gemacht:
In dem Artikel bzw. Link wird noch empfohlen die Richtlinie Do not connect to any Windows Update Internet locations zu aktivieren. Hat damit jemand Erfahrung? Ich hatte die Richtlinie einmal aktiviert, bis ich festgestellt habe, dass die MS-Store Apps sich dann keine Updates mehr ziehen (steht ja auch in der Beschreibung) bzw. der Store nicht verfügbar ist. Das mag jetzt in erster Linie nicht sonderlich relevant erscheinen, hat aber bei uns dazu geführt, dass die Apps wie der Taschenrechner oder Ausscheiden und Skizzieren nicht mehr verwendet werden konnten, da diese halt aus dem Store stammen.
Ich glaube jetzt werde ich das erstmal so lassen und eine Zeitlang beobachten.
Gruß
Doskias
- Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird: aktiviert
- Zielversion des Funktionsupdates: deaktiviert
In dem Artikel bzw. Link wird noch empfohlen die Richtlinie Do not connect to any Windows Update Internet locations zu aktivieren. Hat damit jemand Erfahrung? Ich hatte die Richtlinie einmal aktiviert, bis ich festgestellt habe, dass die MS-Store Apps sich dann keine Updates mehr ziehen (steht ja auch in der Beschreibung) bzw. der Store nicht verfügbar ist. Das mag jetzt in erster Linie nicht sonderlich relevant erscheinen, hat aber bei uns dazu geführt, dass die Apps wie der Taschenrechner oder Ausscheiden und Skizzieren nicht mehr verwendet werden konnten, da diese halt aus dem Store stammen.
Ich glaube jetzt werde ich das erstmal so lassen und eine Zeitlang beobachten.
Gruß
Doskias
So... mit der letzten Konfigurationsänderung aus dem letzten Posts, wird der WSUS jetzt nicht mehr ignoriert. Es bleibt mir dabei allerdings ei Rätsel, wieso der Schlüssel Zielversion des Funktionsupdates der für das Verhalten verantwortlich ist, bis März fehlerfrei funktioniert hat und erst seit März dieses Verhalten an den Tag legt.
Gruß
Doskias
Gruß
Doskias
1
