{"id":264273,"date":"2022-04-11T00:11:00","date_gmt":"2022-04-10T22:11:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=264273"},"modified":"2022-04-10T22:01:47","modified_gmt":"2022-04-10T20:01:47","slug":"falle-windows-clients-installieren-updates-am-wsus-vorbei","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/04\/11\/falle-windows-clients-installieren-updates-am-wsus-vorbei\/","title":{"rendered":"Falle: Windows-Clients installieren Updates am WSUS vorbei"},"content":{"rendered":"

\"Windows\"[English<\/a>]Es gibt hier im Blog gelegentlich die R\u00fcckmeldung von Administratoren, die die Verteilung von Updates an Windows-Clients per WSUS steuern, und sich beklagen, dass die Clients \u00fcberraschend 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.<\/p>\n

<\/p>\n

Updates am WSUS vorbei gezogen<\/h2>\n

\"\"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\u00fcr die Clients vorgesehen sind.<\/p>\n

In der Theorie soll das eine Kontrolle erm\u00f6glichen, welche Updates in der Organisation auf die Clients verteilt werden. Insbesondere problematische Updates lassen sich so blockieren und von der Verteilung samt Installation zur\u00fcckstellen 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<\/a> von Leser Patchie aus meinem Blog, der zum M\u00e4rz 2022-Patchday eingegangen ist.<\/p>\n

Hallo,
\nf\u00fcr die KB Verteilung wird bei uns WSUS verwendet.
\nHeute haben wir mit Entsetzen festgestellt, dass diese KB an allen Regeln vorbei automatisch deployed wurde. Wei\u00df Jemand Rat?<\/p><\/blockquote>\n

Es ist nicht der einzige Kommentar dieser Art, der hier im Blog diesbez\u00fcglich hinterlassen wurde. Das bedeutet, dass die Administratoren in solchen Umgebungen keine Kontrolle mehr haben, welche Updates von den Clients installiert werden.<\/p>\n

Ursache #1: Dual Scan ist aktiv<\/h2>\n

Meine erste Vermutung in diesem Zusammenhang war, dass die Option Dual Scan <\/em>vielleicht auf den Windows-Clients aktiviert ist. Ich hatte beispielsweise im Beitrag Windows 10 Oktober Update (Version 1809): (Upgrade-) FAQ<\/a> auf diese Problematik hingewiesen.<\/p>\n

Microsoft hat in diesem Support-Beitrag<\/a> auch das Thema Update\/DisableDualScan<\/em> f\u00fcr Windows 10\/11 (ab Pro) behandelt. Zudem gibt es diesen Microsoft-Beitrag<\/a> aus 2017 zum Thema. Es gibt unter Windows-Komponenten – Windows Update <\/em>eine Richtlinie, \u00fcber die Dual Scan deaktiviert werden kann. Der englische Name der Richtlinie lautet Do not allow update deferral policies to cause scans against Windows Update<\/em>. Die deutschsprachige Entsprechung m\u00fcsste \"Keine Richtlinien f\u00fcr Updater\u00fcckstellungen zulassen, durch die Windows Update \u00fcberpr\u00fcft wird\" lauten. Blog-Leser John Ripper hat bereits 2017 in diesem Kommentar<\/a> auf das Thema hingewiesen.<\/p>\n

Andy hat in diesem Blog-Beitrag<\/a> einige Hinweise auf Probleme im Zusammenhang mit WSUS ver\u00f6ffentlicht. Und Microsoft hat ebenfalls 2017 einen weiteren Beitrag<\/a> zum Thema ver\u00f6ffentlicht – auf Technet wird hier die Problematik<\/a> mit dem Ziehen von Updates bei WSUS\/SCCM diskutiert.<\/p><\/blockquote>\n

Ursache #2: Richtlinien-Konflikt<\/h2>\n

Der oben erw\u00e4hnte Blog-Leser Patchie schrieb<\/a> 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<\/a> auf einen weiteren Punkt aufmerksam gemacht hat (danke f\u00fcr den Hinweis).<\/p>\n

Hi,<\/p>\n

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.<\/p>\n

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\u00e4dt der Client am Wsus vorbei, auch wenn die Policys dann schon wieder aktiv sind.<\/p>\n

Wir haben sehr lange gebraucht um herauszufinden warum unsere Clients manchmal am WSUS vorbei gepatcht haben.<\/p>\n

Nachteil wenn die Policy auf not configured<\/em> steht: Wenn ein administrativer Benutzer in der Policy rumfummelt, wird das nicht mehr automatisch \u00fcberschrieben.<\/p><\/blockquote>\n

Vielleicht hilft dieser Hinweis von Verena ja dem einen oder anderen Betroffenen weiter.<\/p>\n","protected":false},"excerpt":{"rendered":"

[English]Es gibt hier im Blog gelegentlich die R\u00fcckmeldung von Administratoren, die die Verteilung von Updates an Windows-Clients per WSUS steuern, und sich beklagen, dass die Clients \u00fcberraschend Updates am WSUS vorbei gezogen und installiert haben. Ursache kann eine empfohlenen Gruppenrichtlinie … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,185,301],"tags":[4298,152,3288,881],"class_list":["post-264273","post","type-post","status-publish","format-standard","hentry","category-problemlosung","category-update","category-windows","tag-problemlosung","tag-updates","tag-windows-en","tag-wsus"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/264273","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=264273"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/264273\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=264273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=264273"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=264273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}