Es besteht meiner Erfahrung nach große Unsicherheit, wie man Windows bei Verwendung von Advanced Patch Management (APM) oder PatchLink (PL) konfigurieren soll, damit es nicht auf die Idee kommt, auf den Microsoft Servern selbständig nach Updates zu suchen, diese herunterzuladen und – insbesondere unter Windows 10 – zu einem völlig willkürlichen Zeitpunkt zu installieren. 

Die empfohlenen Einstellungen waren auch schon das ein oder andere mal Thema im DSM Forum, beispielsweise in diesem oder diesem Thread.

Während man bei Windows 7 und Windows 8.1 noch einfach über Gruppenrichtlinien den ungewollten Zugriff auf die Microsoft Upate Server unterbinden kann, stellt sich die Sache bei Windows 10 – auch für Clients, die für die Verwendung eines internen WSUS-Servers konfiguriert sind – etwas anders dar...

Zunächst seien noch einmal die relevanten Gruppenrichtlinien dargestellt. Prinzipiell würde es ausreichen, die Richtlinie Automatische Updates konfigurieren im Pfad Computerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten zu deaktivieren.

Damit ergibt sich dann auf Clientseite bei Windows 7 Systemen folgendes Bild beim Aufruf der entsprechenden Seite der Systemsteuerung:

Allerdings können Anwender, auch wenn diese Richtlinie gesetzt ist, immer noch manuell nach Updates suchen und diese auch installieren. Ist das nicht gewünscht, so sollte eine zweite Richtlinie konfiguriert werden und zwar muss dann die Einstellung Zugriff auf alle Windows-Update Funktionen deaktivieren im Pfad Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > Internetkommunikationsverwaltung > Internetkommunikationseinstellungen aktiviert werden.

Dies führt dazu, dass beim Aufruf der Windows Update-Seite der Windows 7 Systemsteuerung der Zugriff komplett gesperrt ist:

Diese Einstellungen wurden und werden von uns auch im Rahmen des Patch Managements mit APM oder PatchLink empfohlen.

Die Frage ist nun, welche Einstellungen für Windows 10 konfiguriert werden müssen, um sich analog zu früheren Windows Versionen zu verhalten und nur Updates von internen Systemen wie WSUS oder eben von DSM über APM oder PatchLink zu beziehen? Windows 10 verfügt im Userinterface ja über kein Pendant zur vollständigen Deaktivierung von Upates – die Suche nach und die Installation von Updates kann durch keine Einstellung in der Einstellungen-App komplett unterbunden werden.

Grundsätzlich lässt sich feststellen, dass die oben genannten Gruppenrichtlinien-Einstellungen auch bei Windows 10 noch Wirkung zeigen und wie beschrieben konfiguriert werden sollten. Trotzdem wurde beobachtet, dass Windows 10 Systeme direkt auf Microsoft Update Ressourcen zugegriffen und Updates von dort herunterladen haben. Daher lag der Verdacht nahe, dass unter Windows 10 die Verbindung auf die Microsoft Update Server doch nicht komplett verhindert werden kann. Dem ist jedoch nicht so, der Zugriff auf Online-Ressourcen erfolgt aus einem anderen Grund.

Vor dem Hintergrund von "Windows as a Service" und "Windows Update for Business" wurden mit dem Aniversary Update, also Windows 10 Version 1607, ein neues Feature eingeführt, das sich "Dual Scan" nennt. Ist Dual-Scan aktiv, so greift ein Client nicht nur auf seinen konfigurierten WSUS-, SCCM- oder eben DSM-Server zu, sondern verbindet sich auch online mit Windows Update oder Microsoft Update Ressourcen und lädt von dort Update-Pakete!

Wie wird nun Dual-Scan aktiviert (oder deaktiviert) und was ist die Motivation, dass neben dem internen Zugriff auch noch gegen Online-Services gescannt wird?

Dual-Scan wird automatisch (!) aktiv, wenn eine der Richtlinien zum Zurückstellen von Updates gesetzt wird:

Ist mindestens eine dieser Richtlinien konfiguriert, so greift der Windows Update Client zwingend auf die Microsoft Update Server zu, scannt gegen die dort bekannten Patches und lädt und installiert diese auch bei Bedarf. Dies lässt sich nicht verhindern oder konfigurieren! Wenn Sie also einen internen WSUS, SCCM- oder DSM APM/PL-Server betreiben und ausschließlich darüber steuern möchten, welche Updates wann auf die verwalteten Systeme verteilt und installiert werden, dann dürfen Sie diese Richtlinien nicht konfigurieren!

Stellen Sie auf jeden Fall auch sicher, dass im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate keiner der Werte

• DeferFeatureUpdate
• DeferFeatureUpdatePeriodInDays
• DeferQualityUpdate
• DeferQualityUpdatePeriodInDays
• PauseFeatureUpdate
• PauseQualityUpdate
• DeferUpgrade
• ExcludeWUDriversInQualityUpdate

gesetzt ist. Es handelt sich um die Werte, die gegebenenfalls von den genannten Richtlinien gesetzt, aber manchmal auch im Rahmen des Client-Designs bereits im Rahmen des OS Configuration Packages konfiguriert werden.

Die Motivation für dieses Verhalten wird in zwei Blog-Artikeln auf der Microsoft-Seite beschrieben: im ersten (älteren) Artikel unter https://blogs.technet.microsoft.com/windowsserver/2017/01/09/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online/ wird im Abschnitt "Szenario 2" erklärt, dass die Richtlinien zum Zurückstellen von Qualitäts- und Feature-Updates nicht für verwaltete Umgebungen gedacht sind, sondern nur in Zusammenhang mit "Windows Update for Business" Sinn machen, wenn die Clientsysteme also ohnehin gegen die Microsoft Online Server scannen und die Updates von dort laden und installieren. Dort wird also auch explizit empfohlen, diese Einstellungen in Zusammenhang mit SCCM und WSUS (und in unserem Fall mit DSM) nicht zu konfigurieren.

Übrigens ist es wichtig, darauf hinzuweisen, dass die Einstellungen wirklich nicht konfiguriert sein dürfen – selbst wenn sie deaktiviert (aber deshalb eben konfiguriert) sind, kommt der Dual-Scan Mechanismus ins Spiel und die Clients kontaktieren die Microsoft Server.

Ein neuerer Blog-Artikel des WSUS Product Teams unter https://blogs.technet.microsoft.com/wsus/2017/05/05/demystifying-dual-scan/ erklärt darüber hinaus, dass die Idee dahinter ist, dass in einer "Cloud-first"-Welt ein modernes Management sich typischerweise auf Cloud-Services stützen würde und die Benutzung interner Ressourcen nur noch zur Unterstützung von "Legacy-Systemen und -Applikationen" verwendet werden sollte. Daher ist der Dual-Scan Mechanismus so angelegt, dass die Scan-Ergebnisse für Windows-Content dann von Windows Update übernommen werden und alle anderen Kategorien eben von den internen Systemen.

Schöne neue (Windows 10) Welt...