[English]Spannende Frage, die ich hier im Blog zur Diskussion stellen möchte. Es gibt eine Beobachtung, dass Windows 10 im Enterprise-Umfeld gewaltsam von Version 1709 auf 1909 aktualisiert wird, wenn bei WSUS für Enterprise-Clients einige Tage nicht erreichbar sei.
Anzeige
Blog-Leser Markus H. hat mich gestern mit der Frage konfrontiert und seine persönlichen Beobachtungen auf einem Test-Client dokumentiert. Dazu muss man sagen, dass Markus irgendwo, gelesen hatte, dass das Zwangsupgrade für Windows 10 Version 1709 angelaufen sei. Windows 10 Enterprise fällt ja am 14. April 2020 aus dem Support.
(Windows 10: End of Life-Daten)
Windows 10 V1709 Enterprise bekommt Upgrade
Markus beschreibt in seiner E-Mail eine sehr krude Beobachtung, die er auf seinem Test-Windows 10 Enterprise-Client, der auf Version 1709 lauft, gemacht hat:
Anzeige
W10 1709 / Forced install auf 1909 / für Enterprise User falls WSUS für einige Tage nicht erreichbar?
Erhalten Sie aktuell Meldungen, dass auch für Firmen bei WSUS der Updateprozess auf 1909 „geforced" wird?
Ich hatte einen Artikel dazu gelesen, dass dies nun von MS für Privat-Installationen aktiviert wurde.A) Heute Morgen wurde ich mit dem folgenden Hinweisfenster an dem Test-Client begrüßt:
(Funktionsupdate für Windows 10 V1709 Enterprise)
Markus erhielt also auf seiner Windows 10 V1709 Enterprise die Erinnerung, dass ein Funktionsupdate bereit steht. Aber die Update-Verteilung wird per WSUS verteilt. Hier der betreffende Screenshot des Windows Update-Fensters.
Man sieht das eingetroffene Funktionsupdate und dass Windows auf dessen Installation wartet. Windows Update wird aber über Konfigurationsrichtlinien verwaltet – die Update-Verteilung erfolgt per WSUS. Markus schreibt dazu:
Obwohl dies [das Funktionsupdate] explizit bei uns im WSUS deaktiviert wurde und auch (eigentlich von mir so nicht freigegeben wurde), was mich besonders für unser Patchmanagement als Verantwortlicher überrascht.
Der einzige Unterschied zu den sonstigen Clients ist, dass ich versuchte, den Client auf einen neuen WSUS-Server einer Außenstelle zu forcieren.
Microsoft als „Alternative URL" wurde von uns nicht über die WSUS-Parameter, bzw. der Registry des Clients angegeben.
Markus hat folgenden Screenshot der WSUS-Einstellungen mitgeschickt und schreibt dazu: Wie Sie sehen, sind auf dem WSUS keine Feature-Updates zum Download freigegeben.
Weiterhin wurden mir die beiden nachfolgend gezeigten Screenshots mit Registrierungseinstellungen zugeschickt. Als Update-Server ist WSUS vorgegeben.
Und hier der Eintrag aus der Registrierung, der Feature-Updates eigentlich explizit ausschließen soll.
Ich persönlich wäre jetzt davon ausgegangen, dass der Client mit Windows 10 Version 1709 Enterprise, trotz Supportende, weiterhin auf dieser Version bleibt. Ich hatte aber im Artikel Windows 10 Enterprise V1709 versucht Upgrade auf V1803 schon mal eine ähnliche Beobachtung vom Sommer 2019 dokumentiert. Markus schreibt zur aktuellen Situation:
Ist es möglich, dass sich der WSUS-Client, wenn er einige Zeit den WSUS-Server intern nicht erreicht, geforced auf die Microsoft-Updates wechselt und dort das 1909 zieht? Dies wäre eine Einstellung, die erst seit kurzem aktiv wäre.
Falls ja, hätte dies Auswirkungen auf unsere gesamtes Patchmanagement, da mehrere unserer Mitarbeiter/Clients auf Baustellen sind, wo einige Zeit kein WSUS-Server von dieser Lokation erreichbar ist.
Diesen Testclient habe ich vor ca. 8 Tagen auf den Downstream-Server via Regedit zugewiesen. Da der Client dort allerdings nicht erscheint, besteht evtl. eine neue Firewall-Regel zwischen den Lokationen.
Dass hier Microsoft einen gezwungenen Download von den MS Windows Update Servern erzwingt, scheint mir aktuell die einzige Erklärung.
Falls keiner von euch eine logische Erklärung für die obige Beobachtung hat, würde ich der Analyse von Markus beipflichten.
WSUS-Hinweise von Produktions-Clients
In einem ergänzenden Text gibt Markus noch bekannt, dass er auf seinen Windows 10-Clients, die produktiv genutzt werden und am WSUS zur Update-Verwaltung hängen, unterschiedliche Informationen kämen:
B) Zusätzlich erreichen uns nun von unseren Produktiven-Clients unterschiedliche Informationen zu den WSUS-Hinweisen bei der Suche nach Updates:
Beide nun folgenden Screenshots sind von Clients im gleichen Deployment-Ring (Produktiv)
Markus hat mir noch den Screenshot für einen zweiten Client geschickt und schreibt dazu:
Eine neue Warnung, obwohl hier der gleiche Patch-Stand von November zu dem o. g. Client besteht!
Wir hatten einige Probleme mit Updates mit unseren internen Anwendungen, welche wir seit 3 Tagen beheben konnten.
Markus hat mir noch die Windows-Update-Log-Datei geschickt, wo man sieht, wie sich sich der Client die Updates nach mehreren Verbindungsfehlern zum WSUS wohl zu Microsoft Windows Update wechselt und dort die Updates zieht. Die Datei ist sehr umfangreich, weshalb ich die hier nicht einstelle. Frage: Kann sich jemand einen Reim darauf machen oder das Verhalten bestätigen?
Anzeige
Wir benutzen hier zur Update-Verteilung die Kace System Management Appliance von Quest und sind damit soweit zufrieden. Updates erscheinen zwar 2-3 Tage später, da sie dediziert nochmal getestet und geprüft werden und erst dann in der Appliance erscheinen. Der Vorteil dabei ist, dass man den Windows-Update Mechanismus per GPO komplett deaktivieren kann und es dem Kace-Agent überlässt.
Holt der Client die Updates auch automatisch von MS, wenn Kace sich länger auf dem Client nicht mehr blicken lässt?
Nee ist komplett deaktiviert, siehe https://pasteboard.co/ISbXi9K.png
Was hat der Beitrag dann hier bei dem Artikel zu suchen? Das ist schade, dass Leute ihre Erfahrungsbereichte immer unter Nachrichten drunter kippen, womit sie garnichts zu suchen haben. Leute, die das Kommentarthema interessiert, würden sicher hier nicht danach suchen. Und ich weiß nicht, wie es euch so geht, da kommt ein hochinteressanter Artikel, und meistens dann noch hochinteressante Kommentare genau zu dem Thema, aber dazwischen dann ein langer Kommentar wo es um was ganz anderes geht, z.B. die Erkenntnis dass sich x64-Software nicht auf x32 Windows installieren lässt. Es gibt doch genug andere Foren, wo man über solche eigenen Themen in eigenen Rubriken diskutieren könnte. (Tipp: administrator.de, usw.)
Das ist schade, dass man heutzutage wirklich überall auf die selbsternannten Foren-Sheriffs trifft. Ich bitte vielmals um Entschuldigung und gelobe Besserung.
In Hochachtung …
Daniel S.: Im Abschnitt Diskussion hier im Blog wäre der Kommentar wirklich besser aufgehoben gewesen. Genau deshalb habe ich den ja eingerichtet. Nur als Hinweis. Ich kann Kommentare leider nicht einfach 'umhängen', ist ja kein Forum.
@Günter Born: Vielleicht unter jeden Artikel einen Link auf die Diskussionsseite setzen, und darum bitten, dort zu schreiben, wenn das Kommentarthema nicht zum Nachrichtenartikel passt. Ich finde, solche Offtopic-Sachen stören im Lese- und Themenfluss. In letzter Zeit passiert das auffällig oft, die Seite hier ist halt gut und spricht sich rum, und der Moderationsstil ist sehr offen. Das hat seine Vor- und Nachteile.
Verstehe ich zwar – aber das Rad, was ich drehen müsste, wird immer größer. Patches mit Patchday-Tag und Datum versehen etc. Ginge nur, wenn ich die Formularvorlage im PHP-Quellcode modifiziere, was wieder einen Rattenschwanz an Folgen nach sich zieht. Vielleicht fällt mir mal was ein.
Ergänzung: Mir ist was eingefallen – es gibt jetzt einen Hinweistext unter dem Kommentarfeld. Hoffe, er wird gelesen. Danke für die Anregung – hätte ich auch selbst drauf kommen können.
Wir heben unsere clients derzeit auf 1809.
Dass einer unserer ~5500 clients (auch wenn sie WSUS nicht erreichen… davon gibt es etliche) auf 1909 upgegradet hätte, der das nicht machen hätte sollen, ist mir bisher noch nichts aufgefallen.
~ 120 clients befinden sich auf 1709 und wir hätten diese gerne auf 1809, aber auch hier hat keiner der "unwilligen" clients 1909 bekommen.
Ich bin sehr restriktiv, was WSUS betrifft, vielleicht ist es irgend eine kleine Einstellung?
Gefühlt würde ich sagen: Im Beispiel sind Einstellungen getroffen worden, die nur für den "Windows Update for Business" Gültigkeit haben. Meine Erfahrung: Sobald eine WUfB-Regel implementiert wurde, wird auch der Dual-Stack wieder scharf geschaltet. Und dann geht es natürlich ohne Umwege wieder auf die öffentlichen Windows Update Server. Zumindest wenn kein Proxy nach draußen benötigt wird…
Weiterhin haben wir hier noch UpdateServiceUrlAlternate auf den gleichen WSUS gelenkt. DisableWindowsUpdateAccess 1 kann auch nicht schaden.
Also meiner Meinung nach passiert das nur wenn man die GPO "Keine Verbindungen mit Windows Update-Internetadressen herstellen" nicht aktiviert hat.
So ist zumindest meine Beobachtung.
Hallo
Es gibt ja noch mehrere Stellen in den GPO/Registry wo die Kommunikation von Windowsupdate mit Wsus bzw. online geregelt wird. Könnte das eventuell damit zusammenhängen? Habe das gestern bei einem Kunden aktiviert um das vergessene Dotnet3.5 unproblematisch bei etwa 120 VPN Rechnern nachzuholen. Dadurch zieht er auch updates direkt bei Microsoft.
Software\Microsoft\Windows\CurrentVersion\Policies\Servicing [RepairContentServerSource]
So weit ich weiß, sollte auch als alternativer Downloadserver der WSUS angegeben werden, auch wenn man nur einen WSUS-Server hat.
Das ist richtig.
Hallo Markus H.,
das liegt am tollen DualScan Feature. Du hast einige GPO scharf geschaltet, die eigentlich nur für eine Windos Update for Buisness Umgebung gelten (sehe ich an den Registry Werten). Dadurch fällt der Client automatisch zurück auf DualScan. Ich hatte genau dieses Verhalten in der Evaluierungsphase von Windows 10 bei uns. Als "Patch Management Verantwortlicher" wirst du doch sicherlich schonmal über DualScan gestolpert sein ;-)
Gruß
Exakt.
Admin-Fehler
Seh ich das falsch, oder fehlt in dem zweiten Registry-Screenshot nicht ein DWORD-Wert "UseWUServer = 1"?
Wenn ich diesen auf meinen Rechnern lösche (gerade getestet), ignorieren sie auch den eingetragenen WSUS und fangen an, Updates direkt von Microsoft zu ziehen.
Ja stimmt, auch der ist notwendig. Aber zusätzlich hat der Betroffene ja auch noch die GPOs für WUfB drin.
Ich denke hier ist einiges durcheinander in den dortigen GPOs.
Da sollte sich jemand mal grundlegend mit der Thematik befassen.
DualScan hat er allerdings im ersten Screenshot schon deaktiviert gehabt. Ich glaube dass tatsächlich das fehlende UseWuServer die Kernursache ist, weil ich das eben so nachstellen konnte. Dabei wird dieser Wert eigentlich automatisch gesetzt – wenn man den WSUS über den GPO-Editor einträgt. :)
Das deaktivieren von DualScan wird ignoriert (auch der RegKey), wenn man die falschen GPOs (WUfB) drin hat
mal bitte nachsehen unter:
Windows-Einstellungen
– Update und Sicherheit
– Windows Update
– rechts: Erweiterte Optionen
– Übermittlungsoptimierung
– rechts unten Aktivitätsmonitor
taucht hier unter Downloadstatistik neben "Von Microsoft" {sollte WSUS sein}
"Von PC's im lokalen Netzwerk"
auf ?
Es reicht wahrscheinlich ein Rechner mit dem Upgrade, bei dem "Downloads von anderen PC's zulassen" aus.
Guter Hinweis, wobei ich immer dachte, jeder halbwegs vernünftige Admin stellt die Übermittlungsoptimierung auf "0" ein
Die Frage ist, steht der 'wirklich' bei ALLEN auf aus ? (BYOD ?)
Bzw wird die GPO 'wirklich' beachtet ?
Ist die nicht irgendwo wieder umgefallen ?
Hallo,
in den dritten Eintrag UpdateServiceUrlAlternate die Adresse des eigenen WSUS eintragen. http://deinWSUS:8530
DisableDualScan = 1 setzen und Zugriff auf Windows Update Adressen verbieten. Mehr hab ich bei uns nicht gesetzt, und kein Client sieht Online nach Updates/Upgrades bei MSFT. Die Rückstellungsoptionen und U4B haben wir auch nicht gesetzt. Bisher wollte kein Client irgendein Upgrade. Wir upgraden via Baramundi, nur die Updates gehen über den WSUS.
Vielen Dank für die umfangreichen Informationen, Hinweisen, etc.
Die GPO wurde von einer bestehenden GPO übernommen.
Ich habe die GPOs komplett neu aufgebaut. Bisher hatten wir mit dem Dual-Scan keine Probleme, genauso wie mit dem leeren "alternative download url" Setting, welches hier angesprochen wurde.
Zum Glück war die Anpassung in einer Test-OU, um die WSUS-Verteilung an alle Locations zu optimieren.
Am Ende sind nun 3 Devices auf 1909.
Im Log wird erst nach mehrfachen Versuchen, den WSUS zu kontaktieren, auf die MS Internet Services selbstständig gewechselt.
Nochmals vielen Dank für Eure Erfahrungen und Hinweise!