In Windows 10 Anniversary Update schafft es Microsoft, dass kaum noch jemand bezüglich des Downloads von Updates durchblickt, speziell, wenn es um die Verteilung per WSUS geht. Hier ein paar Hinweise und Fragen.
Vorausschicken muss ich, dass ich selbst keinen Windows Server mit WSUS aufgesetzt habe (irgendwo sollte noch eine VM mit so was schlummern, habe ich aber seit 4 Jahren nicht mehr gebootet). Aber beim Thema Windows Update-Verteilung per WSUS, und speziell im Zusammenhang mit Windows 10 Anniversary Update, schafft es Microsoft, dass kaum noch jemand bezüglich des Downloads von Updates wird über verschiedene Kanäle an mich herangetragen.
Ich erinnere an die Diskussion in den Kommentaren zum Artikel Windows 10: Kumulative Updates KB3176492, KB3176493 und KB3176495 wo die Frage aufkam, wo ein Windows 10 Version 1607-Client nun die Updates wirklich her bekommt – auch wenn er angeblich über WSUS aktualisiert wird. Oder es werden Probleme mit dem Laden von Updates angesprochen.
Nun hat sich ein Blog-Leser bei mir per E-Mail gemeldet und einige seiner Erfahrungen zusammen getragen. Ich stelle es einfach mal zur Diskussion hier im Blog ein. Die in […] stehenden Texte sind Einfügungen von mir. Vielleicht ergeben sich ja neue Insights aus Sicht anderer Administratoren, die mit WSUS und Windows 10 Anniversary Update testen. Ihr könnt ja entsprechende Kommentare und Ergänzungen hinterlassen.
Hallo,
ob überhaupt noch jemand durchsteigt, wie das mit dem Download von Patches und deren Verteilung per Peer2Peer aussieht?
Unter Einstellungen, Updates gibt es [in der Windows 10 Einstellungen-App] die Möglichkeit, die Übermittlung von Updates auszuschalten. IMHO betrifft das wirklich nur die Übermittlung an andere. Der Download läuft weiterhin über eine Art Peer2Peer und das legt zuverlässig eine Firewall in der Firma lahm, wenn diese kein Quality of Service bietet. Ob unsere das bietet werde ich mal bei Gelegenheit klären.
Um den Download über p2p abzuschalten, gibt es wohl [im Gruppenrichtlinien-Editor] gpedit.msc [unter]
Computerkonfiguration, Administrative Vorlagen, Windows Komponenten, Übermittlungsoptimierung, Downloadmodus
[Richtlinien. Eine ] gibt die Downloadmethode an, die die Übermittlungsoptimierung für Downloads von Windows-Updates, Apps und App-Updates verwenden kann. Die folgende Liste enthält die unterstützten Werte:
0 = Nur HTTP, kein Peering.
1 = HTTP kombiniert mit Peering hinter derselben NAT.
2 = HTTP kombiniert mit Peering über eine private Gruppe.
Das Peering erfolgt standardmäßig auf Geräten am selben Active Directory-Standort (falls vorhanden) oder in derselben Domäne. Bei Auswahl dieser Option [2] ist das Peering NAT-übergreifend. Um eine benutzerdefinierte Gruppe zu erstellen, verwenden Sie die Gruppen-ID in Kombination with Modus 2.
3 = HTTP kombiniert mit Internetpeering.
99 = Einfacher Downloadmodus ohne Peering.
Downloads der Übermittlungsoptimierung verwenden nur HTTP. Es wird nicht versucht, Kontakt mit den Clouddiensten der Übermittlungsoptimierung aufzunehmen.
100 = Umgehungsmodus.
Die Übermittlungsoptimierung wird nicht und stattdessen BITS verwendet.
[Der] Umgehungsmodus (100) ist nötig, um wieder auf BITS umzusteigen. Dafür gibt es dann eine eigene Richtlinie, um dessen Bandbreite einzuschränken.
So, nun will damit aber das Update von KB3176934 nicht klappen. Musste ich per Hand einspielen. Siehe auch folgende Links:
https://blogs.technet.microsoft.com/mniehaus/2016/08/08/using-wsus-with-windows-10-1607/
„The PC talks to WSUS to determine what updates are needed. For each needed update, the PC checks with the Delivery Optimization service (on the internet) to find any applicable peer PCs that already have the needed content.
If peers are available,, the PC will try to get the content from the peers.“
Schön, vielleicht erklärt das, warum in der Firma keine Frage nach Freigabe der Updates mehr passiert. Das abzuschalten geht aber nur, wenn ich dort die ADMX-Dateien von Windows 10 nutze. Mit lokaler Richtlinie und abgeschalteten „Delivery Optimization service“ holt er sich die Updates dennoch nicht vom WSUS.
Vielleicht ein Bug?
Jetzt habe ich das Problem auch für mich schön zusammengefasst und kann das ablegen und hoffe das es sich löst.
Danke für die gesammelten Infos zu Windows, speziell Version 10. Brauche nicht immer jede Info in voller Länge, zu wissen da war was und es dann Tage (Wochen?) später abrufen zu können ist echt spitze.
Erst gestern 2 Maschinen endlich von th2 auf 1607 updaten können weil z.B. immer wieder der Hinweis kam: der Virenscanner ist der Übeltäter. Deaktivieren während des Downloads hatte gelangt, bei 2 anderen mehr oder weniger gleichen Kisten war das nicht nötig gewesen.
Danke, bitte weiter so.
Ein treuer Leser
Vieles findet sich auch im Wiki zu Windows 10 verlinkt – nur als Tipp für Mitleser – vereinfacht die Suche (sind mittlerweile über 7.000 Beiträge hier im Blog).
Zumindest seit heute habe ich eine Fehlermeldung weniger.
Vorweg: Zugriff des Rechners ins Internet über Firmenfirewall verboten. Nur ein Ping geht durch.
Windows 10 1607 erhält seine Updates über WSUS (Windows Server 2008 R2) und die Konfiguration über GPOs. Die Gruppenrichlinie sind die für Windows 7 Pro/Windows Server 2008 R2.
So, rufe ich nun in Windows 10 1607 Windows Update auf (Einstellungen, Windows Update, Erweiterte Optionen) und aktiviere „Featureupdates zurückstellen“ und Klicke auf „Nach Updates suchen“ kom0t es nach einiger Zeit zu folgender Fehlermeldung: „Wir konnten keine Verbindung mit dem Updatedienst herstellen“.
nämlich
So, nun würge ich auch diese Möglichkeit ab:
gpedit
Computerkonfiguration, Administrative Vorlagen, Windows-Komponenten, Windows-Update
Keine Verbindung mit Windows Update-Internetadressen herstellen = Aktiviert
gpupdate /force
Da die GPO in meinem AD diese Richtlinie nicht kennt, sollte die lokale Richtlinie übernommen werden. Der Rest wie Standort des WSUS u.s.w. stammt vom AD.
Wieder auf „Nach Updates suchen“ geklickt. Fehlermeldung: „Beim Installieren von Updates sind Probleme aufgetreten. (0x8024500c).
Jetzt unter Einstellungen, Windows Update, Erweitere Optionen:
Featureupdates zurückstellen nicht angeklickt.
Und nun kommt nach Klick auf „Nach Updates suchen“ die Meldung „Ihr Gerät ist auf den neusten Stand“.
Ob nun nach Installation eines bestimmten Updates (KB3189866) dann auch nächsten Monat der WSUS die neuen Updates als erforderlich anzeigt, ich diese genehmigen kann und dann der Rechner diese herunterlädt sehe ich nächsten Monat. Oder wenn Microsoft vorher ein Update herausbringt das über den WSUS läuft.
Und wer weiß, was sonst noch da reinspielt. Ich habe jedenfalls auch lokale Richtlinien für BITS und Übermittlungsoptimierung (Downloadmodus Umgehen aktiviert) und bei beiden die Bandbreite reduziert, ist jetzt mit deaktivierter Firewall aber nicht mehr akut.
Den Fehler „0x8024500c“ konnte ich bei mir beheben, in dem ich in den GPO-Einstellugnen die Option „Signierte Updates von Nicht-MS Quellen“ abgeschaltet habe. :-(
Hallo,
den Fehler 0x8024500c bekam ich, nachdem ich den SoftwareDistribution-Ordner gelöscht hatte, um meinen lokalen Windows Update-Cache mitsamt DB aufzuräumen. Während der Prüfung der vielen tausend Updates auf dem WSUS kam die Meldung. Beim erneuten Klick eine Stunde später war der Rechner wieder „auf dem neuesten Stand“.
Eine weitere Merkwürdigkeit habe ich offenbar durch die Aktivierung der Option „Einfach“ in der GPO der Übermittlungsoptimierung beseitigen können.
Obwohl heute Morgen der aktuelle Schwung von MS Office 2016-Updates noch gar nicht auf dem WSUS freigegeben war, bekam mein Rechner (Windows 10 1607) sie bereits zum Download angeboten. Nach der Aktivierung der „einfachen“ Übermittlungsoptimierung und aufräumen des SoftwareDistribution-Ordners war Ruhe. Erst, nachdem ich die Updates im WSUS freigab, wurden sie mir später wieder angekündigt.
Ich nochmal.
Meine obige Aussage muss ich wieder revidieren. Alles ist ganz anders. :-)
Ich habe mich heute noch einmal mit dem Updateverhalten von 1607 auseinandersetzen dürfen, da mir wieder ein Update angeboten wurde, das ich im WSUS noch nicht einmal synchronisiert hatte. Natürlich sind die Rechner per GPO für den Bezug ihrer Updates vom WSUS konfiguriert. Also – eigentlich.
Das Problem ist, dass ich in der GPO, die ich erstmalig mit den Policy-Templates für 1511 bearbeitete, den dato noch verfügbaren Schalter „Upgrades und Updates zurückstellen“ setzte, um die Windows-Rechner in den Updatekreis „WUfB“ zu bringen. Nach Upgrade der Policytemplates auf die 1611er kann man diese Einstellung gar nicht mehr sehen bzw. ändern, sondern nur noch eine neue ,namentlich „Beim Empfang von Funktionsupdates auswählen…“ im Unterordner „Windows-Updates zurückstellen“.
Beide Varianten sorgen dafür, dass bei gleichzeitig aktiver GPO-Einstellung „Keine Verbindung mit Windows Update-Internetadressen herstellen“ der Fehler 0x8024500c auftritt, da die beiden Schalter zum Zurückstellen von Funktionsupdates offenbar den WSUS umgehen und gleichzeitig im Internet nach Updates suchen wollen, dies jedoch nicht dürfen.
Der letzte Satz ist meine Schlussfolgerung, der Rest ist getestet und reproduzierbar bei mir.
Ich kann Deine Schlussfolgerung hiermit bestätigen, ich hatte heute mal Zeit dem Updateverhalten von Win 10 / 1607 in Verbindung mit einem WSUS 6.3.9600.17477 (2012R2) nachzuschnüffeln.
Um den Win 10 Clients die Suche am WSUS vorbei abzugewöhnen müssen die Richtlinien „Windows-Komponenten/Übermittlungsoptimierung\Downloadmodus: Umgehen“ und „Keine Verbindungen mit Windows Update-Internetadressen herstellen“ aktiviert werden.
In Verbindung mit der Zurückstellung von Feature- und Qualitätsupdates spuckten die Clients den Fehler „0x8024500c“. Nachdem ich die beiden Richtlinien zur Rückstellung entfernt habe flutscht es.
Prinzipiell finde ich den neu eröffneten Updatepfad von Microsoft eine nette Idee für kleinere Organisationen, die ein AD betreiben aber keien WSUS. Es wäre halt nett gewesen, wenn Redmond etwas offensivere Informationspolitik betrieben hätte.
Ich hoffe jetzt einfach mal, dass der WSUS die kommenden Jahre wieder gewohnt unauffällig vor sich hin läuft – so viel Aufmerksamkeit ist das arme Serverchen gar nicht gewohnt. ;)
Hi,
also was ist dann hier der richtige Weg?
Updates zurückstellen aktivieren oder nicht?
Hi,
wenn du verhindern willst, dass sich Clients neben WSUS auch direkt von Microsoft Update ihre Updates holen, solltest du die GPOs „Updates zurückstellen“ nicht aktivieren.
Stattdessen gibst du die Adresse zum WSUS-Server an und zusätzlich noch die Einstellung “Keine Verbindungen mit Windows Update-Internetadressen herstellen”. Den „Umgehungsmodus“ aus dem Beitrag oben solltest du ebenfalls aktivieren.
Damit hast du dann WSUS only und nix anderes.
Einziger Haken: Bei der Feature-Installation von .NET-Komponenten möchte Windows offenbar direkten Internet-Kontakt mit den MS-Servern. Ist die Verbindung zu den Windows Update-Servern aber deaktiviert, zeigt der Rechner beim Versuch der Installation eine Fehlermeldung. Aber wenn man’s weiß, kann man es temporär deaktivieren…alles Gefrickel.