[English]Im heutigen Blog-Beitrag fasse ich mal zwei Sachen zusammen, auf die mich Blog-Leser Markus K. per Mail aufmerksam gemacht hat. Möglicherweise gibt es Änderungen bei Treiber-Updates über WSUS, zumindest gibt es Unklarheiten. Einmal tauchen bei ihm auf Dell-Systemen plötzlich Kennwortabfragen an Clients auf, wenn eine Firmware eingespielt werden soll. Es gibt aber weitere Merkwürdigkeiten, wie fehlendes Nachladen von Treibern nach einer Aktivierung. Und dann gibt es den Verdacht, dass Windows 10 die Updates direkt am WSUS vorbei, von den Microsoft Update-Servern, bezieht, egal, was der Administrator da so an Gruppenrichtlinien eingestellt hat.
Unklarheiten bei Treiber-Updates über WSUS
Markus verwaltet Treiber- und Firmware-Updates in seiner Umgebung über WSUS. Wer mehrere Hundert bis Tausend Windows-Clients zentral (z.B. per WSUS) mit Firmware-Update versorgen möchte, kann dort keine plötzlich auftauchenden BIOS-Abfragen von Passwörtern gebrauchen. Genau das ist Markus aber in seiner Umgebung passiert. Auch sollten Treiber nach einer Windows 10-Installation eigentlich automatisch nachinstalliert werden. In einer Mail an mich schilderte er vor einigen Tagen einige Merkwürdigkeiten, die ihn dort plagen:
Ich muss leider den Blog-Artikel Windows 10: Änderungen und Unklarheiten bei Treiber-Updates über WSUS hochkochen. Kurz und knapp, hier ist einiges im Argen!
- z.B. das 5 MB große HP Inc. – Firmware – 2.53.0.0 update endet in einen Passwort-Prompt am Rechner, was bei ein paar tausend Stück wohl eher unpraktikabel ist (ich geh [nicht] mal schnell zum Rechner). Betroffen davon scheinen vor allem HP- und Dell-Systeme zu sein, da wir bei Lenovo so ein Verhalten noch nicht beobachten konnten
- bis vor einer gewissen Zeit hat Windows nach Aktivierung auch sämtliche Treiber nachgeladen, das passiert nicht mehr! (wurde wohl darauf wegen der optionalen Updates schlicht vergessen)
- zumindest unter [Windows 10] 20H2 tut sich bei „usoclient.exe StartScan“ in der GUI und wohl Systemweit nichts mehr.
Ich möchte nur schnell das Bild skizzieren: Wenn eine Universität in Hörsälen und PC-Räumen still steht, weil man nach einem Treiberupdate nach dem BIOS Passwort gefragt wird. Gut durchdacht schaut anders aus. Mag sein, dass das für „Home“ super ist, aber im Unternehmen? Derzeit ist mir nicht bekannt, dass man das Verhalten steuern kann, aber ich lerne gerne dazu.
In einer ergänzenden Mail schrieb er dann, dass das Ausliefern der Rechner ohne BIOS-Passwort in seinem Umfeld keine Option sei. Er stellt fest, dass ein Firmware-Update für die genannten Dell- und HP-Systeme an diesem Verhalten schuld sei, denn bei Lenovo scheint das Ausrollen von Firmware-Updates zu klappen, während die Administratoren bei Dell/HP zum Rechner pilgern dürfen. Dazu schrieb er:
Wir können das derzeit nur für ein paar Modelle „workarounden“ indem wir Proaktiv das BIOS aktualisieren. Dieser Weg ist jedoch keine Dauerlösung, da ja neue Updates sicher kommen werden. Auf der anderen Seite braucht man sich dann in solchen Fällen garantiert nicht ums „Printernightmare“ kümmern…
Anscheinend haben Dell und HP aber nachgebessert. Beim Schreiben dieses Texts kam dann eine dritte Mail:
Mit aktuelleren Bios-Versionen bleibt man nicht mehr mit Passwort-Abfrage (prompt) hängen. Hier wurde anscheinend nachgebessert und das Problem behoben. Ist halt ein schwacher Trost, wenn bereits hunderte Rechner nicht mehr booten können. [Die] Firmware scheint auch erst mit Windows 10 Version 20H2 ausgeliefert zu werden (über Windows 10 Version 2004 kann ich nichts sagen).
Zieht Windows 10 Updates am WSUS vorbei?
Im Rahmen der jüngsten Updates ist Markus in seiner Umgebung im einige Probleme gelaufen, weil seine Windows 10 Version 20H2 Clients plötzlich Updates gezogen haben, obwohl diese nicht im WSUS dafür freigegeben wurden. Hier seine Geschichte dazu – vielleicht hat jemand das auch beobachtet. Markus schreibt in einer ersten E-Mail.
ich bin gerade etwas wortlos, deshalb einfach einen Screenshot vom WSUS wo KB5004945 ohne approve auf Rechnern landet:
Windows 10 Updates ohne WSUS Approval, Zum Vergrößern klicken
In einer Folge-Mail kam neben der Bemerkung, dass erste Berichte über Druckprobleme nach den PrintNightmare-Updates eintreffen, dann die Präzisierung bezüglich der Windows 10 Version 20H2- Clients.
Habe sogar nochmal kontrolliert ob auch „Do not allow update deferral policies to cause scans against Windows Update. “ gesetzt ist und ja, es ist gesetzt. Sogar der Zugriff nach Updates zu manuell zu suchen ist deaktiviert:
Ich habe die Vermutung, dass bei einem Upgrade von 1909 auf 20H2 das letzte dynamische Update vom 21.06 (KB5003716) nachgeladen wird.
So könnten die Clients auf einen Stand gekommen sein, den man gar nicht freigegeben hat. Sollte dem so sein, wäre das doch wieder einmal ein klassischer Fall von „nicht mitgedacht, schlecht gemacht“.
Später vermutete Markus, dass der Fehler bei ihm liegt und schrieb:
Der Fehler war wohl wirklich meiner, da mir anscheinend KB5003716 durchgerutscht ist. Nach Freigabe haben alle 1909 sich dieses DU besorgt und sind somit auf Stand 21. Juni gelandet. Fazit alles am besten doppelt kontrollieren und vorsichtig sein. Sorry für den falschen Alarm.
War aber wohl doch kein falscher Alarm, denn eine weitere Mail besagt folgendes:
Leider doch nicht selber schuld gewesen! Die Clients dürften wohl direkt bei Microsoft das aktuellste DU (dynamic update) abholen.
Zu was man das Zeug dann am WSUS hat frag ich mich. Wie auch immer finde ich es unschön, wenn über DUs Cients mit einem nicht freigegebenen CU daherkommen. Zumindest weiß ich jetzt um den Umstand und den Fakt, dass Microsoft doch auf WSUS pfeift.
Ich habe es einfach hier mal unredigiert eingestellt. Frage: Gibt es von anderen Admins ähnliche Erfahrungen/Beobachtungen?
Wie ich den Markus gut verstehen kann .. ich bin auch leidgeprüfter WSUS Admin und hab ehrlich gesagt kein Bock mehr. Das frustriert und man kämpft gegen Windmühlen.
Es ist total unbegreiflich, was sich M$ da liefert. Deren Patchmanagement ist komplett aus dem Ruder gelaufen. Man erinnere sich noch an die Channels und und und ..
Wenn man wenigstens zwischen Treiber und Firmware unterscheiden würde, wäre schon vieles besser.
Normalerweise sollte sich das ganze Zeug via GPOs steuern lassen und gut ists, aber nein auch hier nichts zu finden.
Man wird wohl den Spruch aus der Juristerei wie folgt ausdehnen müssen:
„Vor Gericht, auf hoher See und als Microsoft Kunde ist man in Gottes Hand!“
Weise geschrieben ^^
WSUS wurde damals „heiß“ zugekauft und seitdem nur Flickschusterei betrieben .. eine Trennung war mal gewollt, wird aber anders kommen .. alles über den Store!
Ich hab im KMU Bereich den ich hauptsächlich betreue schon lange aufgegeben mit WSUS – das ganze ist viel zu komplex & kompliziert geworden.
Mit den vorhandenen Bandbreiten ist zumindest der Download kein Problem mehr – interessieren würde mich ob der sogenannte „Branch Cache“ überhaupt funktioniert und verwendet wird. (Updates im Windows Netzwerk zwischen den einzelnen Clients verteilen)
Das ganze rennt im Netz via DeliveryOptimization gesetzt via GPO.
Funktioniert sehr gut.
80% von ppers im Netz und der Rest vom WSUS
War bei uns auch so, bis wir uns zu einem Drittanbieter-Tool für die Windowsupdates durchgerungen haben (Nein ich bekommen kein Geld dafür = Aagon CAWUM).
Läuft sehr stabil und zuverlässig.
Ich hatte mal Aagon ACMP Os Deployment/Inventory/Asset im Einsatz ..
1A Tool (Ich bekomme auch kein Geld dafür ^^)
Ich könnte mir vorstellen das es bei Lenovo Rechner nicht auftaucht weil diese gar keine BIOS Updates auf dem Wege machen.
Zumindeste habe ich in meiner kleinen Umgebung beobachtet, das neu installierte Rechner, bei Updates von MS direkt gezogen, diverse Treiber etc updaten.
Wenn MS Update nichts mehr findet, installiere ich die „gute“ alte Lenovo System Update Software und er findet genau ein Paket, das BIOS Update.
Mag aber auch an mir liegen, werde wohl zu alt um das alles noch zu verstehen
Habe erst anfang dieser Woche bei meinem E5 ein BIOS Update eingespielt bekommen
Interessant, vielleicht gibt es unterschiede nach Serien oder so.
Generell wäre es ja schöner, eine Software weniger.
Hallo.
Ich tippe auf falsch konfigurierte Update GPOs. Wenn man einige Sachen eingestellt bzw. nicht eingestellt hat macht win10 einen Fallback auf WUfB und zieht bei MS..
Wir hatten so ein Thema hier schonmal im Blog, ging aber um Updates generell und nicht Treiber, aber es ist ziemlich ähnlich…
@Markus poste mal deine Win Update GPOs, ich wette da ist ein Fehler…
Schau mal vor allem nach „DoNotConnectToWindowsUpdateInternetLocations“
Hier in der Umgebung zieht kein Client irgendwas von MS ;-)
Da ich Markus K. und sein Umfeld aus vielen Kontakten kenne, dürfte er das DualScan-Thema auf dem Radar haben – er liest hier ja mit. Falls wirklich was in den GPOs übersehen wurde, werden wir es mitbekommen. Danke für den Hinweis.
DoNotConnectToWindowsUpdateInternetLocations kann ich nicht empfehlen, da hier Features die man nachinstallieren möchte nicht mehr bekommt, weil man diese nur mehr direkt von MS beziehen kann.
Dual Scan ist deaktiviert und auch der Zugriff für User um manuell zu MS zu gehen!
Bisher war alles unter bester Kontrolle.
Am besten ein 1909 auf 20H2 upgraden und nur das 2021-06 dazu approved haben => client landet trotzdem auf 2021-07
Es kann natürlich sein, dass mit „DoNotConnectToWindowsUpdateInternetLocations“ gar nix von MS, somit auch keine Dynamischen Updates nachgeladen werden. Würde wohl in einen client enden der direkt nach dem upgrade auf 20H2 völlig ungepatcht ist.
Das stimmt, aber Features Nachinstallierbar machen heißt, dann ist der Draht zu den MS Server eben auch da. Imho muss die DoNotConnectToWindowsUpdateInternetLocations geschaltet sein und dann hat man alles so wie man will. Ansonsten gibt’s den Fallback. Entweder oder… Entweder du bleibst bei deiner lokalen Umgebung oder die lässt die MS Server mit ran.
Ein zwischending wie z.b. einige Kategorien lokal und einige von MS läuft nicht..
Du kannst dir aber noch ExcludeWUDriversInQualityUpdate anschauen, wobei dann Treiber generell von WindowsUpdate raus sind
Bei derart unmengen an Hardware Modellen ist unsererseits nicht daran zu denken, dass wir diese manuell einbinden können/wollen. Dazu eben das FoD Drama.
Ich muss allerdings sagen, dass wir bis 1909 keinerlei Probleme hatten und diese erst mit 20H2 schlagend wurden, wobei diese gravierenden Probleme erst seit Änderung des driver delivery model schlagend wurden.
Wir haben leider keine „gute“ Option und wenn dann auch noch die Spielregeln plötzlich geändert werden ist das werder nett noch schön, zumal es keinerlei vernünftige Werkzeuge (könnte Microsoft sicher alles via GPO leicht umsetzen) gibt.
Dafür gibts die Feature-On-Demand-DVDs – aber nur aus dem VLSC.
Das ist richtig aber für jedes Verfügbare FoD ein Softwarepaket zu schnüren und das einmal im Jahr?
Ich glaube nicht das das Praxisnahe ist. Auf einer Universität kann man nicht einfach Feature Zensur betreiben, wie das vielleicht in einem privaten Unternehmen machbar ist.
Dass BIOS-Updates das BIOS-Passwort verlangen ist ja üblich – bei den Hersteller-Tools (z. B. Dell, Fujitsu) kann man das Passwort als Parameter verschlüsselt oder im Klartext angeben. So lässt sich dann per Dell Command Update auch ein BIOS-Update automatisieren – Hilfe im Administratorhandbuch und im „Reference Guide“.
Stimmt natürlich. Nur für genau eben dieses Szenario scheinen die Hersteller einen neuen Switch eingebaut zu haben der das BIOS Upgrade ohne Passwort via OS erlaubt!
Krux an der Geschichte, zu altes BIOS kennt das noch nicht und man landet im Passwort prompt.
Ich Orte hier eine Unzulänglichkeit der Hersteller die von Voraussetzungen ausgehen, welche nicht erfüllt sind, ohne diese jedoch vorher zu überprüfen.
Ich würde mich für Hardware nicht unbedingt auf MS bzw. den WSUS verlassen, weil der Hersteller das erstmal an MS (und den Update-Katalog) weitergeben müssen, und danach erst im WSUS aufschlägt (wenn überhaupt). Dann müllst du dir damit noch die Datenbank zu (10 GB Limit nicht vergessen).
Dann doch lieber mit den Hersteller-Tools entweder über Internet nach Updates suchen (Bandbreite beachten) oder ein lokales Repository einrichten (frickel da grad ein bisschen mit Dell rum, bei Fujitsu kostet das nochmal extra).
Treiber am WSUS wird es bei uns nie geben!
Die holen wir direkt bei WindowsUpdate, was auch gut klappt(e).
Bis auf die BIOS updates die installiert werden, obwohl es dem Hersteller bekannt sein sollte, dass das erst ab einer gewissen Version auch klappt… Ist halt so eine Sache, wenn man das nicht abfrägt und einfach mal macht.
Wir nutzen bei uns in der Firma WSUS via Microsoft Configuration Manager (liegt nicht in meiner Verwaltung, aber ich könnte jetzt nicht sagen, dass da schon mal was unbeabsichtigt durchgerauscht ist [habe da ein Auge drauf wegen der Verantwortlichkeit im Rahmen von Windows 10]). Aber das auch nur für Security-Updates.
Für Treiber und BIOS erstellen wir Softwarepakete zur Verteilung via ConfigMgr. Wir haben hauptsächlich Fujitsu-PCs und -Notebooks und ein paar Dell- und Surface-Tablets im Einsatz.
DELL: Das Dell-Update kann die Bitlocker-Verschlüsselung eigenständig regeln, ich muss aber da zwingend das BIOS-Passwort als Option hinter der EXE mitgeben.
FUJITSU: Hier muss leider manuell die Bitlocker-Verschlüsselung angehalten und fortgesetzt werden, dafür kann hier auf das BIOS-Passwort verzichtet werden. **ABER: Ich nutze auch privat einen Fujitsu-PC, dieser verlangt beim BIOS-Update über Windows Update auch das BIOS-Passwort (was „super“ ist, weil ich eine Bluetooth-Tastatur nutze, die dann nicht funktioniert und ich erst eine USB-Kabel-Tastatur suchen muss)! Mal schauen, ob sich das zukünftig regelt.**
SURFACE: Auch da bauen wir Pakete, weil unsere Windows-Server noch zu alt sind, um diese Surface-Updates verwalten zu können (da gibt es wohl besondere Anforderungen an die Server-Version), aber das MSI regelt glücklicherweise sowohl Bitlocker als auch Passwort eigenständig.
Hallo Günter Born, dass Updates am WSUS vorbei gehen kann ich definitiv bestätigen. Wir haben einen Teil der Clients über WSUS auf 20H2 gebracht und hatten nie kb5000802 (März Printer Problem) freigegeben. Auch haben die Clients kb5000802 nicht selbst aus dem Internet geladen (per GPO nicht erlaubt). Wir stellten mit Release von kb5000802 fest, dass alle auf 20H2 aktualisierten Clients auch sofort kb5000802 hatten. Wir mussten dann per Script das Update wieder deinstallieren.