Windows 10 und der USOClient

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

C:/Windows/System32/

In der Aufgabenplanung gibt es einen Task, der den USOClient aufruft, um bestimmte Aufgaben auszuführen.

USOClient in Aufgabenplanung
(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.


Anzeige

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.

Update-Suche gesperrt

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).

Update-Installation gesperrt

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.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows 10 abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

11 Antworten zu Windows 10 und der USOClient

  1. Stefan sagt:

    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

    • JohnRipper sagt:

      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.

  2. Al CiD sagt:

    "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.

    • JohnRipper sagt:

      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.

      • Remo sagt:

        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?

        • Viktor Engelmann sagt:

          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.

  3. Swedish Chef sagt:

    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!

  4. wufuc_MaD sagt:

    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

  5. LippeAdmin sagt:

    "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?

    • Günter Born sagt:

      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:

      Windows 10 Clients am WSUS erlauben unter Einstellungen\…\"Windows Update" keine manuelle Aktion mehr

      In Ihrem Blogbeitrag [siehe oben] beschreiben Sie genau das Problem, welches ich mit den von mir betreuten Windows 10 PC-Clients an einem WSUS – Server habe.

      Alle Clients erlauben keine manuelle Update-Suche und bei gefundenen Updates keine manuelle Installation mehr (Schaltflächen sind deaktiviert).

      Erschwerend kommt dazu, dass in unserer Umgebung offenbar nur der Befehl bzw. Parameter „usoclient.exe startscan" funktioniert, alle Anderen leider nicht.

      Sie schreiben dazu „ … Dies liegt an einer bestimmten Kombination von Richtlinien, ohne dass dies explizit gewünscht ist (es gibt nämlich dafür eine gesonderte Richtlinie die bei der Quelle aber nicht aktiviert ist), …".

      Auch bei uns sind bezüglich des Verhaltens der Clients zahlreiche Windows Update Einstellungen durch eine GPO vorgegeben, aber eben auch ohne die Intention, die manuellen Eingriffe zu unterbinden.

      Leider konnte ich bisher durch Probieren verschiedener abweichender Einstellungen, die „..Suchen" und „..Installieren" – Schaltflächen nicht wieder aktivieren. Das nur zur Vorrede.

      Daher meine Bitte; Könnten Sie vielleicht doch einen Hinweis auf die sich diesbezüglich negativ auswirkenden GPO – Parameter aus den Informationen Ihrer Quelle veröffentlichen?
      Oder kennen Sie irgendeinen Forenbeitrag, der diese Informationen bietet, den Sie vielleicht verlinken könnten?

      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.

  6. RalphAndreas sagt:

    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)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.