Heute noch ein Artikel mit diversen Informationen rund um den UsoClient, der unter Windows 10 für die Updates (durch die Hintertür) zuständig ist.
Anzeige
Das Thema wurde bereits mehrfach von Blog-Lesern angesprochen (siehe), aber ich bin noch nicht dazu gekommen, da was aufzubereiten. Bei der Suche in den Kommentaren hier im Blog nach usoclient hat mir ebenfalls einige Treffer geliefert.
Was ist der USOClient?
Zu diesem Teil gibt es m.W. von Microsoft nicht wirklich viel. Ich hatte vor einiger Zeit in meinem Blog-Beitrag Windows 10 Zuverlässigkeitsupdate KB4023057 (8.2.2018) ein paar Informationen, die ich im Internet zusammen geklaubt habe, gepostet.
Der Begriff USO steht für Update (Session) Orchestrator. Dazu gibt es aber wenig, außer Hinweise im Internet (hier (entfernt), hier, hier) dass ein usoclient.exe beim Systemstart kurz in einem Fenster der Eingabeaufforderung auftaucht. Hier (gelöscht) gibt es sogar einen Screenshot des Fensters und hier einen Screenshot der Aufgabenplanung mit dem Update Orchestrator-Task zum Start des usoclient.exe. Die beste Erklärung, die ich bisher gefunden habe, stammt von MawshiKid in diesem Microsoft Answers-Thread.
First, USO stands for Update Session Orchestrator and it's the mechanism which replaced the Windows Update Agent. As a part of the Windows Update service, usoclient.exe main role is basically a command to run tasks to either scan for updates, install or resume updates.
Das mit dem Namen USO hatte ich oben ja schon erklärt. Der USOClient ist Teil von Windows Update und ersetzt in Windows 10 mehr und mehr den Windows Update Agent. Die Aufgabe der usoclient.exe ist es, nach Updates zu suchen, diese herunterzuladen, zu installieren und auch eine Update-Installation wieder aufzunehmen. Das Programm findet sich in
Anzeige
C:/Windows/System32/
In der Aufgabenplanung gibt es einen Task, der den USOClient aufruft, um bestimmte Aufgaben auszuführen.
(Zum Vergrößern klicken)
Hier finden sich noch ein paar Infos von MawshiKid – und hier werden auch einige Infos gegeben. Der Kollege von deskmodder.de hatte mir vor längerer Zeit in einer Mail zum Problem 'Windows Update auch in Windows 10 Home zu deaktivieren' folgendes geschrieben.
Mit der Fall Creators Update (Windows 10 1709) hat Microsoft [in Windows 10 Home] … jegliches deaktivieren des Dienstes von Windows Update verhindert. Da es nicht über die Einstellungen und Dienste geht, muss man eben an die Rechte der Dateien etwas ändern.
Früher war die wuauclt /detectnow dafür zuständig, dass Windows Updates abgerufen wurden. Heute ist es die UsoClient.exe, die in C:\Windows\System32\ zu finden ist. Wer es einmal ausprobieren möchte: Windows-Taste + R drücken und UsoClient.exe startscan eingeben und Enter drücken. Schon sucht Windows nach neuen Updates.
Die Windows Updates werden über die Aufgabenplanung gesteuert. Unter Aufgabenplanungsbibliothek -> Microsoft -> Windows -> Update Orchestrator findet ihr den Eintrag Schedule Scan. Genau dieser ist dafür Verantwortlich, dass automatisch nach Updates über die UsoClient.exe gesucht wird.
Hat man alles ausgeführt, wie wir es in unserem Windows 10 Wiki beschrieben haben, dann haben die Aufgaben keinen Zugriff mehr und es erscheint eine „Zugriff Verweigert" Meldung in der Aufgabenplanung. Wer sich jetzt wegen seinem Defender sorgen macht, muss es nicht. Denn der wird separat mit Signaturupdates versorgt. Will man manuell nach Updates suchen, dann kann man das auch weiterhin. Ein Klick auf Updates Suchen in den Einstellungen und es wird alles heruntergeladen, was zur Verfügung steht. Oder natürlich man lädt sich die kumulativen Updates manuell herunter.
Der Betreiber von deskmodder.de, moinmoin, hatte mir den Link auf seinen Artikel Windows 10 1709 Updates auf manuell setzen auch in der Home Version beigefügt, wo die obigen Ausführungen mit weiteren Hinweisen zu finden sind.
Problem mit Gruppenrichtlinien
Aus einer weiteren Quelle ging mir noch ein Text zu, der auf ein Problem mit Updates unter Windows 10 in Verbindung mit Gruppenrichtlinien hinweist. Wer Windows 10 in Verbindung mit Gruppenrichtlinien verwendet, der hat ggf. das Problem, dass die manuelle Suche bzw. die Installation von Updates eingeschränkt ist.
Dies liegt an einer bestimmten Kombination von Richtlinien, ohnedass dies explizit gewünscht ist (es gibt nämlich dafür eine gesonderte Richtlinie die bei der Quelle aber nicht aktiviert ist), aber das soll hier nicht Thema sein.
Auf jeden Fall können Windows Updates nicht manuell gesucht oder die Installation angestoßen werden. Sieht dann aus wie in folgendem Screenshots.
In obigem Screenshot ist in der Update-Seite von Windows 10 die Suche nach Updates gesperrt. Wird ein Update gefunden, ist die Installation dieses Updates gesperrt (die Schaltfläche ist ausgegraut, siehe folgender Screenshot).
Ein erfahrender Windows Admin hat früher über die Command Line via wuauclt.exe einen Scan bzw. die Installation angestoßen. In Windows 10 hat der Befehl aber keine Auswirkungen mehr.
Die Quelle schrieb mir: Nach einiger Suche bin ich im Internet jedoch u.A. auf diese Webseite gestoßen, die eine Reihe von Befehlen als Ersatz für wuauclt.exe zeigt ([GB]das ist genau die von mir bereits oben verlinkte Webseite). Konkret funktioniert bei mir der usoclient in Verbindung mit folgenden Optionen:
StartScan
StartDownload
StartInstall
RestartDevice
Dabei muss auf meinem Windows 10 (1709) Build nicht unbedingt der Zusatz „.exe" verwendet werden, noch muss in den Ordner „C:\Windows\System32" gewechselt werden. Einfach „usoclient option" ist ausreichend.
Netter Nebeneffect: [Bei] usoclient startscan meldet den Status nahezu unmittelbar an einen WSUS, sofern einer vorhanden ist. Vielleicht hilft es ja jemand.
Die Quelle schrieb noch: Und falls sich jemand wundert warum hier FileZilla via Windows Update installiert wird, kann ich dazu gerne auch noch etwas schreiben… [GB]Aber das ist ein andere Baustelle, zu der die Quelle gerne einen Kommentar hinterlassen darf. Ansonsten mein Dank an die Beteiligten für die Hinweise.
Anzeige
Wahrscheinlich verwendet er WPP (Windows Package Publisher). Haben wir auch hier im Einsatz. Darum wird er sich vermutlich auch um diese Befehler kümmern. WPP kann Updates anstoßen bei Clients per Befehl. Allerdings funktioniert dies nicht mehr mit Windows 10. Aber vielen Dank für den Tipp hier, habe selbst nach sowas gesucht!
Eines muss ich aber doch an Windows 10 loben. Er meldet sich sehr schnell beim WSUS und ich bin doch etwas flexibler mit Updates manuell anstoßen (am Client selbst) wie Windows 7
Genau genommen heißt es WSUS Package Publisher.
Richtig mit Windows 10 kann man via WPP die Updates nicht mehr anstoßen, deswegen muss man auf den Client ausweichen. Und dort kommt man mit wuauclt.exe nicht mehr weit.
Und ja, das gute an dem USOClient ist, dass er unmittelbar nach StartScan den Status meldet. Das war mit wuauclt.exe doch etwas kompliziert, bzw. nicht so zuverlässig.
"Eines muss ich aber doch an Windows 10 loben. Er meldet sich sehr schnell beim WSUS und ich bin doch etwas flexibler mit Updates manuell anstoßen (am Client selbst) wie Windows 7" – ist wahrscheinlich Absicht.
Windows 10 first! … haben die gesagt…
Herr Born, danke für die Aufklärung, wie immer sehr informativ.
Nein. Bei Windows 7 oder früher wurden mit wuauclt.exe die Meldungen an den WSUS gesammelt und dann reported um die Last zu reduzieren. Es gab nie die (zuverlässige) Möglichkeit einen Report auszulösen (selbst mit der Option /reportnow nicht), was tw. unschön war.
Mit dem USOClient ist dies deutlich besser.
Das kann ich so nicht bestätigen.
Bei Windows 7 wurde bei uns der Report (wuauclt /reportnow) innert sekunden am WSUS gemeldet.
Bei Windows 10 kann ich diesen "Report" leider nicht mehr generieren und es dauert meist über 45min bis der Report erstellt wird.
Woran liegt das?
Das ist so nicht richtig. Ja – wuauclt /reportnow meldet seine infos sehr schnell an den Server ABER NUR wenn es meint, dass es etwas zu melden gibt – und das tut es NUR wenn seit dem letzten Report ein Update gefunden und/oder installiert bzw für unnötig befunden wurde.
Dass man updates gesucht, aber keine gefunden hat wird NICHT gemeldet – dann bleibt auf dem Server die info stehen, dass nichts passiert sei.
Ja zugegeben, der USOClient ist schon praktisch und schnell, aber ich verstehe einfach nicht warum Microsoft hierzu keine Doku oder Erklärung schreibt.
Siehe:
https://social.technet.microsoft.com/Forums/en-US/7619f7fa-ffc1-433b-a885-12e26f9762bf/usoclientexe-usage?forum=win10itprogeneral
Zitat:
"Hi,
This command isn't meant to be called outside of the internal OS. Nobody outside the OS should be trying to run the usoclient directly.
Thanks for your understanding. "
P.s.: Am Ende des Forenbeitrag verlink noch jemand auf einen anderen Artikel der genau das Gegenteil behauptet.
Aber ich vertraue einfach darauf das Microsoft ganz genau weiß was im Konzern so läuft.
In dem Sinne Bork Bork Bork!
upgradefunnel hab ich vergessen, egal..
hier mal einige remotebefehle aus einer brandaktuellen remediationxxx.etl
gefangen von einem notebook mit 1709.192
absolut passend zur fortsetzung der blogserie über rempl (kb4023057)
warum webtechniken, http, ftp u.s.w. verwendet werden dürfte klar sein,
diese updates (es sind immer 3 an der zahl wenn aktiv) sollen ja "ungehindert"
den "upzudatenden nutzer" treffen, und jeder gegenwehr widerstehen.
hoffe es hilft dem ein oder anderen zu verstehen, was "upgradefunnel" bedeutet.
DATETIMESYNCPLUGIN.MAXIMUMRUNCOUNTvalue:90
NOISYHAMMERPLUGIN.MAXIMUMRUNCOUNT
DEVICEDRIVERREMOVALPLUGIN.ENABLEREMOVAL
BOOT.OVERRIDEDEFAULTFORCEDREBOOTDAYS
CHANGEPOWERPROFILEPLUGIN.ENABLEvalue:1
CHANGEPOWERPROFILEPLUGIN.MAXIMUMRUNCOUNT
REBOOTFORCEDPLUGIN.MAXIMUMRUNCOUNTvalue:90
SHELL.WSAUTOUPDATEENABLEDvalue:1
SHELL.SIHBASEDSCANENABLEDvalue:1
STACKDATARESETPLUGIN.ENABLEDELETEUSOSTOREFOLDER
STACKDATARESETPLUGIN.ENABLEDELETEDOJOBSREGISTRYTREE
SHELL.USOSCANENABLEDvalue:1
lol
"Dies liegt an einer bestimmten Kombination von Richtlinien, ohnedass dies explizit gewünscht ist (es gibt nämlich dafür eine gesonderte Richtlinie die bei der Quelle aber nicht aktiviert ist), aber das soll hier nicht Thema sein."
Kennt jemand diese Quelle oder die Einstellungen, die das verursachen?
Ich spüle es nochmals hoch – leider ist mir die Quelle entfallen (Mails lösche ich aus Aufwands- und DSGVO-Gründen, sobald ich die nicht mehr brauche). Gerade hat mich eine weitere Anfrage diesbezüglich erreicht. Hier der Text:
Da stehe ich auf dem Schlauch, da ich die Quelle und die Details nicht mehr kenne.
Falls der damalige Tipp-Geber das hier liest, ggf. nochmals Mail mit Details schicken. Ansonsten gibt es folgende Beiträge, die ggf. weiter helfen, um das GPO-Problem einzukreisen:
https://blogs.technet.microsoft.com/swisspfe/2018/04/13/win10-updates-store-gpos-dualscandisabled-sup-wsus/
https://www.askvg.com/tip-disable-check-for-updates-button-in-windows-10/
https://www.tenforums.com/tutorials/65013-enable-disable-check-windows-updates-windows-10-a.html
Ggf. mal den Registrierungseintrag unter
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
inspizieren, um zu sehen, was da gesetzt ist. Falls es eine Lösung gibt – wäre ein Feedback hilfreich – ich mache dann einen Beitrag draus.
Interessant….
In einer nagelneuen W2019 Domäne mit W2019 Terminalserver bin ich genau auf das hier geschilderte Problem gestossen. Alles GPO verwaltet nur ohne WSUS. Ich konnte folgende GPO Einstellung identifizieren, die dieses Verhalten bei mir verurscht hat:
Computerkonfiguration\Administrative Vorklagen\Windows-Komponenten\Windows Update\ "Anzeigeoptionen für Updatebenachrichtungen"
Nachdem ich diesen Schalter wieder auf "Nicht konfiguriert" gestetzt habe, läuft alles wieder nach Plan. (Entwerder noch ein Reboot oder ein gpupdate /force der betroffenen Maschinen)