Windows Update Scanquellen: WSUS-Lücken je Updateklasse prüfen

Was ein fehlender WSUS-Marker über Windows Update Scanquellen aussagt

Windows Update Scanquellen bestimmen, wo ein Client nach Updates sucht. Ein erfasster WUServer-Wert beantwortet eine engere Frage: Hat das Audit in einer GPO eine nicht leere WSUS-Serverzeichenfolge gefunden? Diese Zeichenfolge belegt weder, welche Updateklassen den Server nutzen, noch ob die Richtlinie einen bestimmten Computer erreicht oder dessen letzter Scan erfolgreich war.

Beginnen Sie die Prüfung eines WSUS-Befunds mit der vorgesehenen Updatestrategie. Eine Organisation kann Clients zentral verwalten und zugleich Windows Update als Quelle wählen. Umgekehrt kann eine WSUS-URL in einer Richtlinie vorhanden sein, während eine betroffene Clientgruppe eine andere Quelle nutzt oder ihre Scans nicht abschließen kann. Behandeln Sie Richtlinienkonfiguration, erfolgreiche Scans und die Konformität installierter Patches als drei getrennte Nachweisbereiche.

Diese Anleitung behandelt das von Microsoft dokumentierte Verhalten von Windows-10/11-Clients. Die Richtlinie zur Scanquelle gilt für Windows 10 ab Version 2004 mit den dokumentierten Wartungsvoraussetzungen sowie für Windows 11. Erfassen Sie Edition, Version, Build und Verwaltungsmethode, bevor Sie sie anwenden. Übertragen Sie die folgende Tabelle zum Clientverhalten nicht auf jede Windows-Server-Version; bewerten Sie Server anhand ihrer jeweils unterstützten Richtlinien und des vorgesehenen Bereitstellungsmodells. Microsofts Anleitung zu Scanquellen definiert diesen Clientumfang.

Funktionsweise: Vier Updateklassen mit unterschiedlichen Standardwerten

Microsoft erlaubt die getrennte Auswahl zwischen WSUS und Windows Update für Funktionsupdates, Qualitätsupdates, Treiber- und Firmwareupdates sowie Updates für andere Microsoft-Produkte. Bei einer Migration kann daher eine Klasse vor den anderen umgestellt werden. Ein Auditnachweis braucht eine Quelle für jede Klasse statt einer einzigen Bezeichnung wie „cloudverwaltet“ oder „nutzt WSUS“.

Die folgende Übersicht fasst das dokumentierte standardmäßige Scanverhalten der unterstützten Windows-Clients zusammen. Lesen Sie sie zusammen mit dem tatsächlichen Richtlinienergebnis für jede Clientgruppe:

Microsoft nennt außerdem eine Migrationsfalle: Do not allow update deferral policies to cause scans against Windows Update, die ältere Dual-Scan-Richtlinie, wird unter Windows 11 nicht unterstützt und unter Windows 10 durch die Richtlinie zur Scanquelle ersetzt. Werden unter Windows 10 beide konfiguriert, verhindert dies Updates von Windows Update. Inventarisieren Sie diese ältere Richtlinie, bevor Sie die neueren Quelleinstellungen ändern. Diese Unterschiede stammen aus der Referenz zum Scanverhalten von Windows Update und WSUS.

Die Quellenauswahl ist außerdem von Berichterstattung und Inhaltsbereitstellung zu unterscheiden. Specify intranet Microsoft update service location hat ein Feld für den Erkennungs-/Downloadserver und eines für den Statistikserver. Beide können auf denselben Server zeigen, erfüllen aber unterschiedliche Zwecke. Ein optionaler alternativer Downloadserver ändert, wo Dateien heruntergeladen werden. Er ersetzt nicht die Festlegung der vorgesehenen Scanquelle. Microsofts zusätzliche Windows-Update-Einstellungen beschreiben diese Felder und Downloadoptionen.

Ein HTTPS-Endpunkt benötigt eine eigene Transportprüfung. Nutzen Sie dafür unsere Prüfungen für WSUS-TLS und Client-URLs. Hier geht es darum, welche Quelle jede Updateklasse nutzen soll und ob der Client dort tatsächlich erfolgreich gescannt hat.

Erkennung: Angewendete Richtlinien mit Clientnachweisen abgleichen

Schritt 1: Clientgruppen und Richtlinienverantwortliche ermitteln

Unterteilen Sie den Bestand nach Betriebssystembuild, Verwaltungsmethode und relevantem Richtlinienumfang. Berücksichtigen Sie entfernte Clients und jede Gruppe, die eine lokale Updatequelle beibehalten muss. Fragen Sie für jede Gruppe, wer für Funktions-, Qualitäts-, Treiber-/Firmware- und sonstige Produktupdates verantwortlich ist, welche Klassen WSUS oder Windows Update nutzen sollen und welche Netzwerkeinschränkungen gelten.

Erfassen Sie das Ergebnis der angewendeten GPOs auf einem repräsentativen Zielsystem in jedem Geltungsbereich und erweitern Sie die Prüfung anschließend auf die betroffenen Computer. Microsofts Befehlsreferenz zu gpresult dokumentiert den Computerbereich und die ausführliche Ausgabe:

gpresult /scope computer /v

Prüfen Sie die tatsächlichen Einstellungen und die daran beteiligten GPOs. Eine im Domäneninventar sichtbare Richtlinie kann für diesen Computer irrelevant sein. Erfassen Sie bei MDM-verwalteten oder gemeinsam verwalteten Clients zusätzlich die zugewiesenen und wirksamen Verwaltungsrichtlinien aus dem vorhandenen Verwaltungssystem. Die GPO-Ausgabe allein belegt das CSP-Ergebnis nicht. Klären Sie Abweichungen mit den zuständigen Verwaltungsverantwortlichen; nehmen Sie nicht an, dass die bloße Existenz einer Richtlinie verrät, welche Verwaltungsinstanz Vorrang hat.

Schritt 2: WSUS und klassenspezifische Quelleinstellungen prüfen

Die Quellrichtlinie heißt Specify source service for specific classes of Windows Updates und befindet sich unter:

Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service.

Für CSP-verwaltete Clients führt Microsoft vier Richtlinien auf:

Die Konfigurationsanleitung zu Scanquellen verlangt, bei Verwendung von CSPs alle vier zu konfigurieren. Die Update-CSP-Referenz dokumentiert für diese Quelleinstellungen 0 für Windows Update und 1 für WSUS. Sie warnt außerdem, dass die Richtlinien wirkungslos bleiben, wenn Update/UpdateServiceUrl nicht korrekt auf WSUS verweist. Prüfen Sie Anwendbarkeit und Voraussetzungen, bevor Sie einen konfigurierten Wert interpretieren.

Auf einem Zielsystem liest der folgende Befehl den Windows-Update-Richtlinienzweig rekursiv mit der von Microsoft dokumentierten Syntax von reg query:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

Die Referenz zu Windows-Update-Einstellungen dokumentiert WUServer und WUStatusServer unter diesem Zweig sowie UseWUServer unter dessen Unterschlüssel AU. Prüfen Sie den konfigurierten Updateendpunkt, Statistikendpunkt und die Einstellung zur WSUS-Nutzung gemeinsam. Das sind Beobachtungen der lokalen Konfiguration, keine Ergebnisse erfolgreicher Verbindungen. Fehlende Ausgabe muss mit dem Richtlinienumfang und der Verwaltungsmethode abgeglichen werden.

Microsoft empfiehlt, Scanquellen über GPO oder CSP statt durch direkte Registry-Schreibzugriffe zu konfigurieren. Die Anleitung zu Scanquellen warnt ausdrücklich, dass eine Änderung über die Registry zusätzlich UseUpdateClassPolicySource benötigt, damit sich die Quelle ändert. Nutzen Sie für Korrekturen den unterstützten Richtlinienprozess; fügen Sie keine Zeichenfolge nur deshalb hinzu, um einen Detektor zufriedenzustellen.

Schritt 3: Einen erfolgreichen Scan und ein getrenntes Patchinventar erfassen

Auf dem Windows-Client dokumentiert Microsofts Referenz zu Get-WindowsUpdateLog die Umwandlung von Windows-Update-ETL-Traces in ein lesbares Protokoll:

Get-WindowsUpdateLog

Dies wandelt Diagnosetraces um; es startet keinen Scan und bestätigt keine Updateinstallation. Nutzen Sie aufbewahrte Clientdiagnosen und Scanaufzeichnungen der vorhandenen Verwaltungsplattform, um den tatsächlich kontaktierten Dienst, den Scanabschluss, Zeitstempel und Fehler zu untersuchen. Fügen Sie Geräteidentität und Nachweiszeitraum bei. Wenn die verfügbaren Aufzeichnungen eine Klasse oder Quelle nicht belegen können, markieren Sie diesen Teil der Matrix als unbekannt, statt ihn aus einer URL abzuleiten.

Vergleichen Sie anschließend das Inventar installierter Updates mit der für die Organisation geltenden Patchbaseline. Erfassen Sie Aktualität des Inventars, Anwendbarkeit, Installationsergebnisse und ausstehende Arbeiten getrennt. Ein erfolgreicher Scan kann Updates finden, die noch nicht installiert sind. Ein eingetragener Statistikendpunkt oder eine kürzlich erfolgte Meldung beim Verwaltungssystem ersetzt diesen Installationsnachweis nicht.

Behebung: Nachgewiesene Quellenabweichungen korrigieren (Remediation)

Schritt 1: Die Matrix aus Quelle, Klasse und Clientgruppe erstellen

Erstellen Sie für jede Clientgruppe eine Kopie dieser Vorlage. Die Zellen enthalten zu erhebende Nachweise, keine beispielhaften Ergebnisse aus einer Umgebung:

Halten Sie vorgesehene und wirksame Quelle getrennt. Wenn eine verwaltete Clientgruppe absichtlich Windows Update nutzt, dokumentieren Sie diese Entscheidung, die maßgeblichen Richtlinien, den Verantwortlichen und die Scan-/Installationsnachweise. WSUS zu installieren, damit ein Auditmarker verschwindet, würde diese betrieblichen Fragen nicht beantworten.

Schritt 2: Die zuständige Richtlinie in einem Pilotbereich ändern

Korrigieren Sie nur die Abweichung, die durch die Vorlage belegt ist. Prüfen Sie bei Clients, die WSUS nutzen sollen, die Intranetdienstkonfiguration und Klassenauswahl über den zuständigen GPO- oder CSP-Prozess. Setzen Sie bei einer geplanten Umstellung mit gemischten Quellen jede Klasse auf ihre genehmigte Quelle und konfigurieren Sie alle vier CSP-Einstellungen, wenn dies die Bereitstellungsmethode ist.

Gleichen Sie vor dem Pilot die alten Dual-Scan-Steuerungen ab. Prüfen Sie auch Do not connect to any Windows Update Internet locations, wo diese Richtlinie gilt: Microsoft warnt, dass diese Einstellung die Funktion öffentlicher Dienste einschließlich Windows-Update-Clientrichtlinien und Delivery Optimization verhindern kann. Eine Entscheidung für eine Cloudquelle erfordert damit vereinbare Netzwerk- und Richtlinieneinschränkungen. Folgen Sie dem dokumentierten Verhalten der Windows-Update-Einstellungen, statt Einschränkungen pauschal aufzuheben, ohne ihren Zweck zu prüfen.

Halten Sie Erkennungsserver, Berichtsziel und optionalen Downloadserver im Einklang mit dem genehmigten Entwurf. Bewahren Sie die bisherige Konfiguration für ein Rollback auf und vereinbaren Sie mit dem Updateverantwortlichen einen Nachweiszeitraum für den Pilot. Configuration Manager oder eine andere vorhandene Verwaltung benötigt eine eigene Prüfung der Clientkonfiguration; dieses Verfahren ersetzt den entsprechenden Verwaltungsprozess nicht.

Schritt 3: Vor der Ausweitung dieselben Messungen wiederholen

Führen Sie nach Anwendung der Richtlinie die GPO- und Registry-Leseabfragen erneut aus, erfassen Sie bei Bedarf aktuelle MDM-Nachweise und beobachten Sie erfolgreiche Scans gegen den vorgesehenen Dienst. Untersuchen Sie fehlgeschlagene Scans, unbeabsichtigte Quellen oder fehlende Nachweise, bevor Sie die Änderung ausweiten. Prüfen Sie die Installationskonformität nach dem Bereitstellungszeitraum unabhängig davon.

Fügen Sie diese Nachweise dem wiederkehrenden AD-Auditprozess und dem Prüfturnus nach Änderungen bei. Prüfen Sie die Matrix nach Änderungen am Richtlinienumfang, an der Verwaltungsverantwortung oder am Netzwerkzugang erneut. Ein späterer Prüfer sollte die absichtliche Nutzung von Windows Update von einer verlorenen Richtlinie oder einer unvollständigen Erfassung unterscheiden können.

Wie EtcSec dies erkennt

Die geprüfte etc-collector-Implementierung von PA038_WSUS_NOT_CONFIGURED untersucht die erfassten GPOPolicies. Eine nicht leere WUServer-Zeichenfolge in irgendeiner GPO setzt den Zähler auf 0. Gibt es keine Richtlinien oder fehlt jeder verfügbare Wert beziehungsweise ist er leer, liefert sie einen Befund mit Schweregrad Low und Zähler 1. Dieser Zähler beschreibt nicht die Anzahl unverwalteter oder ungepatchter Clients.

Der geprüfte Parser für Registry.pol ordnet eine nicht leere Zeichenfolge namens WUServer zu, wenn der Registry-Schlüssel windowsupdate enthält. Die SMB-Erfassungsroutine ignoriert an diesen Aufrufstellen fehlgeschlagene Dateilesezugriffe und behält dennoch das GPO-Richtlinienobjekt bei. Eine fehlende oder unlesbare Richtliniendatei kann daher die erwarteten Daten fehlen lassen, ohne dass hier ein gesondertes Lesefehlerergebnis vorliegt.

Diese Prüfung ermittelt nicht die Anwendung der GPO pro Zielsystem, Verknüpfungen, Filterung oder Vorrang. Sie validiert weder URL noch Protokoll, untersucht weder UseWUServer noch WUStatusServer, erfasst keine CSP-Quelleinstellungen, unterscheidet keine Updateklassen, testet keine Verbindung, bestätigt keinen erfolgreichen Scan und inventarisiert keine installierten Patches. Ein positiver Marker in einer sachfremden GPO kann die Prüfung erfüllen, während die untersuchte Clientgruppe ungeklärt bleibt.

Nutzen Sie den Befund, um die oben beschriebene Prüfung für die jeweilige Clientgruppe einzuleiten. Halten Sie absichtliche Entscheidungen für Cloudquellen und Unbekanntes bei der Erfassung im Auditnachweis fest. Schließen Sie das betriebliche Problem erst ab, wenn vorgesehene Quelle, wirksame Clientrichtlinien, erfolgreiche Scans und das getrennte Installationsinventar abgeglichen wurden.