[English]Es gibt hier im Blog gelegentlich die Rückmeldung von Administratoren, die die Verteilung von Updates an Windows-Clients per WSUS steuern, und sich beklagen, dass die Clients überraschend Updates am WSUS vorbei gezogen und installiert haben. Ursache kann eine empfohlenen Gruppenrichtlinie aus den Microsoft Baseline-Vorlagen sein. Hier einige Informationen zu diesem Sachverhalt, auf den mich ein Leserkommentar gebracht hat.
Anzeige
Updates am WSUS vorbei gezogen
In vielen Firmen wird die die Verteilung von Updates an Windows-Clients per WSUS verwaltet. Administratoren richten die Windows-Clients so ein, dass diese den Windows Server Update Services (WSUS) auf einem zentralen Server nach anstehenden Updates abfragen. Gleichzeitig geben die Administratoren die Updates frei, die für die Clients vorgesehen sind.
In der Theorie soll das eine Kontrolle ermöglichen, welche Updates in der Organisation auf die Clients verteilt werden. Insbesondere problematische Updates lassen sich so blockieren und von der Verteilung samt Installation zurückstellen oder ausnehmen. In der Praxis kommt es aber immer wieder vor, dass Administratoren feststellen, dass die Client sich die Updates am WSUS vorbei gezogen und installiert haben. Hier ein entsprechender Kommentar von Leser Patchie aus meinem Blog, der zum März 2022-Patchday eingegangen ist.
Hallo,
für die KB Verteilung wird bei uns WSUS verwendet.
Heute haben wir mit Entsetzen festgestellt, dass diese KB an allen Regeln vorbei automatisch deployed wurde. Weiß Jemand Rat?
Es ist nicht der einzige Kommentar dieser Art, der hier im Blog diesbezüglich hinterlassen wurde. Das bedeutet, dass die Administratoren in solchen Umgebungen keine Kontrolle mehr haben, welche Updates von den Clients installiert werden.
Ursache #1: Dual Scan ist aktiv
Meine erste Vermutung in diesem Zusammenhang war, dass die Option Dual Scan vielleicht auf den Windows-Clients aktiviert ist. Ich hatte beispielsweise im Beitrag Windows 10 Oktober Update (Version 1809): (Upgrade-) FAQ auf diese Problematik hingewiesen.
Anzeige
Microsoft hat in diesem Support-Beitrag auch das Thema Update/DisableDualScan für Windows 10/11 (ab Pro) behandelt. Zudem gibt es diesen Microsoft-Beitrag aus 2017 zum Thema. Es gibt unter Windows-Komponenten – Windows Update eine Richtlinie, über die Dual Scan deaktiviert werden kann. Der englische Name der Richtlinie lautet Do not allow update deferral policies to cause scans against Windows Update. Die deutschsprachige Entsprechung müsste "Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird" lauten. Blog-Leser John Ripper hat bereits 2017 in diesem Kommentar auf das Thema hingewiesen.
Andy hat in diesem Blog-Beitrag einige Hinweise auf Probleme im Zusammenhang mit WSUS veröffentlicht. Und Microsoft hat ebenfalls 2017 einen weiteren Beitrag zum Thema veröffentlicht – auf Technet wird hier die Problematik mit dem Ziehen von Updates bei WSUS/SCCM diskutiert.
Ursache #2: Richtlinien-Konflikt
Der oben erwähnte Blog-Leser Patchie schrieb dann aber, dass Dual Scan auf seinen Clients deaktiviert war. Es muss also etwas anderes sein, was Probleme macht. In diesem Kontext hat Blog-Leserin Verena in diesem Kommentar auf einen weiteren Punkt aufmerksam gemacht hat (danke für den Hinweis).
Hi,
ich kann sagen was es bei uns war, die Richtline "Configure registry policy processing" war bei uns aktiv und hat das verursacht. Die ist in der empfohlenen Microsoft Baseline enthalten, sodass wir sie auch implementiert hatten. MS empfiehlt aber mittlerweile diese auf "not configured" zu setzen.
Jedes Mal, wenn die Policys neu geschrieben werden, sind die Keys kurze Zeit nicht vorhanden. Wenn in dieser Zeit ein Scan vom Update kommt, lädt der Client am Wsus vorbei, auch wenn die Policys dann schon wieder aktiv sind.
Wir haben sehr lange gebraucht um herauszufinden warum unsere Clients manchmal am WSUS vorbei gepatcht haben.
Nachteil wenn die Policy auf not configured steht: Wenn ein administrativer Benutzer in der Policy rumfummelt, wird das nicht mehr automatisch überschrieben.
Vielleicht hilft dieser Hinweis von Verena ja dem einen oder anderen Betroffenen weiter.
Anzeige
ggf Ursache 3:
Clients wurde es nicht verboten (per GPO) manuell extern
"Check online for update ftom Microsoft Update"
zu clicken und User tun dies auch.
Es geht noch viel einfacher an WSUS vorbei:
Indem man in der GUI nicht unterbindet nach Updates bei Microsoft zu suchen.
Das benötigt dann genau einen User klick und vorbei ist es mit WSUS.
Kann ich nicht bestätigen, mit DisableDualScan und WSUS gab es das nie mit Updates und CumulativeUpdates. Nur bei Featureupdates lief das Spiel vielleicht mal so, bis letzten Sommer TargetReleaseVersion und TargetReleaseVersionInfo eingeführt wurden, die bis zum Erreichen des Supportendes respektiert werden.
Meiner Erfahrung nach passiert es auch recht oft, dass Admins GPOs unter "Windows Update für Unternehmen" aktivieren, diese hebeln dann die WSUS-GPOs komplett aus und es wird direkt bei Microsoft nach Updates gesucht.
der irrsinn liegt aber nicht am admin, sondern am OS hersteller. eine Windows build auf 21h2 Windows 10 einzufrieren ist eben nur im Windows Update für Unternehmen möglich. Zudem haben wir gelernt, dass zig GPO settings überhaupt erst gar nicht in Windows implementiert sind.
Das ist aber die GPO, die die Ausnahme dieser Regel ist; generell kannst du aber auch die Win11 Update Blocker Regkeys nutzen.
Anders: wenn du sowieso den WSUS im Einsatz hast, brauchst du das nicht, da du dann sowieso dort das Featureupdate freigeben müsstest.
@Maximilian
Nein, das ist eine Fehlinterpretation, aber der Sachverhalt ist trotzdem nicht schön:
Wer A) für Clients via GPO eingestellt hatte, FeatureUpdates bis zu 365 Tage zurückzuhalten B) aber DisableDualScan nicht kannte und C) die FeatureUpdates bewusst NICHT via WSUS anbot, dessen Clients holten sich die Dinger nach Ablauf der Rückhaltezeit am WSUS vorbei.
Und noch besser: Wer korrekt unterstützend DisableDualScan anknipste, wurde durch die Blockade anderer vielleicht gewünschter Downloads (die man nicht via WSUS anbieten kann) bestraft – ich weiss nicht mehr was es war, vielleicht das FeatureOnDemand .Net…
Nein, das ist genau so auch von Microsoft dokumentiert.
Wenn man GPOs in diesem Unterordner aktiviert, dann ziehen diese, wenn man nicht DisableDualScan verwendet (was man nicht zwingend muss), sie umgehen somit IMMER den WSUS.
Nur: man muss diese nicht setzen, da man diese Optionen ja über den WSUS steuert. Somit muss man auch kein Dualscan deaktivieren, dann kann man bei Bedarf immer noch manuell über das GUI Updaten. Dann ist aber damit auch ein Update auf Win11 möglich, es sei denn, ma setzt die Blocker-Regkeys.
https://docs.microsoft.com/en-us/windows/deployment/update/wufb-wsus
Solche "Fehlfunktionen" ermöglichen ein Gedankenspiel einer Zukunftsprognose:
Lokale Benutzter und/oder auch Admins mit Macht über Verteilung von Updates kommen in zukünftigen Szenarien mit Windows 365 usw. nicht mehr vor.
Der Plan von Microsoft scheint zu sein, weltweit sozusagen "Thin Clients" zu betreiben, vernagelt über Microsoft Account und TPM, mit OS-Komponenten und allen Daten in der Cloud.
Und zwar für alle Installationen von einfacher Schüler-/Schullizenz, Privatnutzer bis hin in die Corporate Welt.
Natürlich Cloud Daten beliebig einsehbar für interessierte Dienste, Account und OS beliebig abschaltbar je nach "unfreundlicher Staat", beliebig unterwanderbar durch zentral erzwungen ausgerollte aber je nach Ziel auch mal ganz selektive Updates mit "speziellen Features". Das dürfte der Traum sein, an dem sie derzeit arbeiten.
You'll own nothing. And you'll be happy.
"Das dürfte der Traum sein, an dem sie derzeit arbeiten."
Dieser "Traum" dürfte wohl schon sehr bald Realität werden. Jeder, der aufmerksamer Verfolger der Entwicklungen in der digitalen Welt ist, sieht schon längst wie die Weichen der Zukunft gestellt werden/sind und wohin uns der digitale Zug bringen wird. Ist aber leider nur eine kleine Minderheit, die sich mal überhaupt ansatzweise darüber (weitergehende) Gedanken macht. Die breite Masse interessiert es nicht die Bohne, sondern im Gegenteil, die machen voller Freude mit und finden das alles richtig cool und klasse … (Mit-/Voraus)denken, (Eigen)verantwortung übernehmen, selbstständig sein/agieren/handeln, sind leider für immer weniger (vor allem auch jüngere) Menschen gangbare Optionen. Beim geringsten "Aua" und "Wehweh" wird immer schneller und lauter nach dem "starken, beschützenden" Staat und diversen Institutionen gerufen. Der fruchtbare Boden für deine oben ausgeführten Gedankenspiele und Prognosen dürfte somit bereitet sein. Leider! Vielleicht (hoffentlich …) liegen wir auch daneben? Fällt mir allerdings immer schwerer dies zu glauben …
"Configure registry policy processing" aktivieren und JEDESMAL die Übernahme der CSE erzwingen ist der größte Quatsch und Blödsinn, den man sich einreden kann. Gegen diese Windmühle kämpfe ich seit Jahren.
Eine Übernahme der registry.pol aus Sicherheitsgründen muss nur erfolgen, wenn die Einstellungen lokal geändert wurden. Das kann nur ein Account mit administrativen Rechten. Wenn ich administrative Rechte habe, dann ändere ich den Wert JEDESMAL per Task und EventID Trigger, wenn die GPO angewendet wird.
Das ist pure Security by obscurity.
Wir haben derzeit dass Problem, dass trotz deaktiviertem Dualscan und Angabe der Zielversion (Windows 10 21h2) viele Clients Win 11 herunterladen. Auf den Clients sind alle GPO Werte korrekt in der Registry gesetzt. Mir ist dieser Zustand echt schleierhaft. Am Ende frage ich mich mal wieder, warum MS es den Admins so schwer macht. Allein die Bezeichnungen innerhalb der GPOs sind schwer zu verstehen bzw. missdeutig.