Windows-Updates ohne GUI prüfen, installieren und bestätigen

Ziel

Betriebssystem-Updates auf einem Windows-Server-Host ohne Desktop prüfen, installieren und bestätigen und vorab wissen, ob der Host bereits auf einen Neustart wartet.

Voraussetzungen

Administratorrechte; entweder direkter Zugriff auf Windows Update oder ein konfigurierter WSUS-Server. Dieser Artikel behandelt WSUS als primären Weg für verwaltetes Patching; Patch-Management-Tools von Drittanbietern gibt es, sie werden hier aber nicht behandelt.

Schritte

1. Unter Server Core legt die Update-Seite von sconfig die Richtlinie direkt fest: Automatic prüft und installiert täglich nach Zeitplan, Download only (laut Dokumentation die Standardeinstellung) lädt Updates herunter und benachrichtigt, ohne sie zu installieren, und Manual macht beides nicht automatisch.
2. In verwalteten Umgebungen werden Updates normalerweise über Windows Server Update Services (WSUS) freigegeben und verteilt, statt dass jeder Server direkt auf Windows Update zugreift. Die WSUS-Richtlinie (Genehmigungsgruppen, Fristen und Zuordnung der Clients) wird in der Regel über eine Gruppenrichtlinie festgelegt, die die Clients auf den WSUS-Server verweist.
3. Vor der Installation prüfen, ob der Host nach einer früheren Aktion bereits auf einen Neustart wartet, damit keine weiteren Änderungen auf einen inkonsistenten Zustand gesetzt werden. Ein konkretes, prüfbares Beispiel: reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations – existiert dieser Wert, sind bereits Dateien für eine Umbenennung beim nächsten Start vorgemerkt. Allgemeiner meldet die Windows-eigene Ressource Microsoft.Windows/RebootPending einen ausstehenden Neustart aus mehreren Gründen, darunter "Windows Updates requiring restart", "Component-Based Servicing operations", "Pending file rename operations", "Computer rename pending" und "Domain join operations pending". Jeden dieser Gründe als Signal werten, ein Wartungsfenster einzuplanen, statt sofort weitere Änderungen zu installieren.
4. Nach der Installation der Updates nicht allein auf Get-HotFix verlassen, um zu bestätigen, was installiert ist: Das Cmdlet fragt die WMI-Klasse Win32_QuickFixEngineering ab, die laut Microsofts eigener Klassendokumentation "nur die Updates zurückgibt, die von Component Based Servicing (CBS) bereitgestellt werden ... Updates, die von Microsoft Windows Installer (MSI) oder der Windows-Update-Website bereitgestellt werden, ... werden nicht zurückgegeben." Für ein vollständiges Bild mit dem Windows-Update-Verlauf oder dem WSUS-Reporting gegenprüfen.
5. Den Neustart in einem kontrollierten Wartungsfenster durchführen, nicht sofort: Restart-Computer -Force (nicht interaktiv; es gibt keine Bestätigungsabfrage, die unterdrückt werden müsste).

Erwartetes Ergebnis

Die Prüfung auf einen ausstehenden Neustart aus Schritt 3 liefert vor der Wartung kein Ergebnis; falls doch, liefert sie einen konkreten Anhaltspunkt. Nach Installation und Neustart zeigen sowohl Get-HotFix als auch der WSUS-/Windows-Update-Verlauf die neu eingespielten Updates.

Grenzen und Prüfbasis

Da Get-HotFix nur CBS-Updates erfasst, beweist ein leeres oder kurzes Ergebnis nicht, dass ein Host ungepatcht ist: Ein kumulatives Update, das ausserhalb von CBS bereitgestellt wurde, würde dort nicht erscheinen. Nichts hiervon erfordert ein ausdrückliches "Rückgängigmachen": Eine Update-Installation lässt sich nur über den Windows-eigenen Deinstallationsweg (Get-HotFix plus wusa /uninstall /kb:<number>, sofern anwendbar) oder über einen Wiederherstellungspunkt zurücknehmen, nicht durch Zurücksetzen einer Konfigurationseinstellung. Die Änderung des Update-Modus in sconfig und die Registry-Prüfung wirken beide sofort und erfordern für sich keinen Neustart; nur die zu installierenden Updates können einen verlangen.