Zum Inhalt
Kaffeeundcode

Sektion 21: Windows Update for Business (WUfB): Rings & Deployment

Learning 18 Min. Lesezeit

Einleitung: Warum Windows Update for Business die Grundlage jedes modernen Patch-Managements ist

Bevor Windows Update for Business (WUfB) existierte, hatten IT-Abteilungen im Wesentlichen zwei Optionen: Windows Updates komplett der automatisierten Welt von Microsoft überlassen – ohne jede Kontrolle – oder einen WSUS-Server (oder gar SCCM) betreiben, um Updates manuell zu genehmigen. Beide Extreme sind für moderne Unternehmen unbefriedigend. Die erste Variante birgt das Risiko, dass ein fehlerhaftes Update ungefiltert die gesamte Belegschaft erreicht. Die zweite Variante produziert operativen Overhead: jemand muss jeden Patch prüfen, genehmigen und verteilen – und genau dieser manuelle Schritt ist in der Praxis der häufigste Grund, warum Unternehmen monatelang nicht patchen.

Windows Update for Business schließt diese Lücke. Es ist kein eigenständiges Produkt und kein Server, sondern ein Policy-Framework, das auf den klassischen Windows-Update-Mechanismus aufsetzt. Die Idee ist radikal einfach: Microsoft testet jedes Update vor der Veröffentlichung millionenfach intern und mit Insidern, Microsoft beobachtet die Telemetrie in den ersten Tagen nach dem Release und hält problematische Updates über so genannte Safeguard Holds automatisch zurück – und du steuerst als Administrator über Policies, wann deine Geräte welche Updates bekommen. Du entscheidest also nicht mehr ob ein Update installiert wird, sondern nur noch wie schnell es bei den verschiedenen Gruppen deiner Flotte ankommt.

In Kombination mit Intune wird WUfB zum Standard-Deployment-Mechanismus für Windows 10- und Windows 11-Geräte, die nicht über SCCM/MECM verwaltet werden. Die Update-Richtlinien werden als Gerätekonfigurationsprofile ausgerollt, brauchen keine Agenten und keine Server-Infrastruktur. In dieser Sektion gehen wir tief in die Materie: Wir klären die Update-Typen, die Logik der Deferral- und Deadline-Policies, den Aufbau eines sauberen Ring-Modells, die Umsetzung in Intune – inklusive der relevanten Registry-Schlüssel und PowerShell-Befehle für die Analyse – und ein vollständiges Troubleshooting-Kapitel für die typischen Fehlerbilder, die in der Praxis auftreten.

Grundkonzepte: Feature Updates, Quality Updates und der Update-Stack

Die zwei Update-Klassen

Windows unterscheidet zwei grundlegende Update-Klassen, und jedes WUfB-Steuerungs-Element muss getrennt für beide betrachtet werden:

  • Feature Updates (Versions-Upgrades, z. B. 23H2 → 24H2): Diese Updates bringen eine neue Betriebssystem-Version und damit neue Features, neue APIs, aber auch neue Risiken für Anwendungskompatibilität. Feature Updates sind groß (mehrere Gigabyte als vollständiges Paket), können aber über Enable-Features-on-Optimization als ca. 500 MB kleines Express-Paket ausgeliefert werden, wenn der Zielpfad passt. Deferral-Zeiträume sind hier bis zu 365 Tage konfigurierbar.
  • Quality Updates (monatliche kumulative Updates): Das sind die monatlichen Patches am sogenannten Patch Tuesday (zweiter Dienstag des Monats), die Sicherheitslücken schließen. Sie kumulativ – jedes enthält alle vorherigen Fixes. Zusätzlich enthält jedes kumulative Update die Servicing Stack Updates (SSU), die später mit den LCU (Latest Cumulative Updates) verschmolzen wurden. Deferral-Zeiträume sind hier auf 30 Tage begrenzt – bewusst, denn monatliche Sicherheitspatches sollten nie länger als ein Monat verzögert werden.

Dazu kommen als dritte Kategorie Treiber-Updates und Microsoft-Produkt-Updates (Office etc.), die über dieselbe Windows-Update-Pipeline laufen können. Microsoft-Produkt-Updates für Office sind in WUfB-Kontexten meist irrelevant, weil Office über Click-to-Run ohnehin einen eigenen Update-Kanal besitzt; Treiber-Updates lassen sich in Intune separat über die Update-Ringe mitsteuern („Allow Windows 11 Feature Updates“ nein, sondern das Setting „Driver update profile“ – dazu mehr in der Praxis-Sektion).

Die vier Steuerungs-Elemente von WUfB

WUfB kontrolliert Updates über vier zentrale Mechanismen, die du alle kennen und bewusst einsetzen musst:

  • Deferral (Zurückstellung): Ab dem Tag, an dem Microsoft ein Update veröffentlicht, wartet das Gerät eine konfigurierte Anzahl von Tagen, bevor es das Update überhaupt in Betracht zieht. Beispiel: Ein Quality-Update-Deferral von 7 Tagen bedeutet, dass ein am 9. September veröffentlichtes Patch am 16. September erstmals angeboten wird.
  • Pause (Aussetzung): Ein temporärer Stop für bis zu 35 Tage pro Update-Klasse (Feature und Quality getrennt pausierbar). Die Pause ist ein Reaktionsmechanismus: Wenn ein fehlerhaftes Update publik wird, pausierst du schnell, bis Microsoft einen Fix liefert. Nach Ablauf (oder manueller Aufhebung) müssen Updates wieder installiert werden – Pause verschiebt, sie verhindert nicht dauerhaft.
  • Deadline (Frist): Definiert, wie viele Tage nach dem Angebot des Updates (nicht nach Veröffentlichung durch Microsoft!) die Installation zwingend abgeschlossen sein muss. Vorher darf der Nutzer selbst steuern, ab der Deadline erzwingt das System die Installation inklusive Neustart. Optional mit Grace Period (Toleranzperiode) für den Reboot.
  • Safeguard Holds (Sicherheitsblocker): Microsoft blockiert automatisch den Upgrade-Pfad auf neue Feature-Update-Versionen, wenn auf einem konkreten Gerät ein bekannter Kompatibilitätsfehler erkannt wurde – z. B. ein alter Treiber oder eine Applikation, die mit der neuen Version nicht funktioniert. Safeguard Holds sind kein Bug, sondern ein Feature: Sie sind der Grund, warum WUfB-Flotten im Schnitt deutlich stabilere Upgrades erleben als manuelle Upgrade-Sprints.

Ein häufiges Missverständnis sei an dieser Stelle korrigiert: WUfB-Deferrals sind nicht „könnte man ja auch mit WSUS machen“. Der fundamentale Unterschied ist, dass WSUS ein binäres Genehmigungsmodell hat (Update genehmigt oder nicht, für alle Geräte einer Zielgruppe gleich), während WUfB ein kontinuierliches, zeitbasiertes Modell fährt. Das Update ist immer für alle da – es kommt nur gestaffelt an. Das ist die Grundlage für das Ring-Modell im nächsten Abschnitt.

Wichtig: WUfB und die Update-Quelle

WUfB setzt voraus, dass Geräte Updates direkt von Microsoft Windows Update (im Internet) beziehen. Geräte, die klassisch auf einen WSUS oder einen konfigurierten Update-Server zeigen (Group Policy „Specify intranet Microsoft update service location“ oder die Registry-Values UseWUServer und WUServer unter HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU), sind ein Sonderfall: Seit Windows 10 1607+ greift ein Mechanismus namens „Dual Scan“, bei dem Windows trotzdem parallel nach Updates im Microsoft-Netz suchen kann. In hybriden Umgebungen führt das oft zu unklaren Zuständen (Updates tauchen auf, die niemand genehmigt hat, oder genehmigte Updates erscheinen nicht). In reinen Intune-Umgebungen ohne WSUS ist das kein Thema – sobald aber GPO und WUfB parallel existieren, musst du wissen, dass es diese Interaktion gibt und sie bewusst managen.

Praxis-Implementierung: Update-Ringe in Intune aufbauen

Warum Ringe? Die Logik des gestaffelten Rollouts

Der Gedanke hinter Deployment-Rings ist identisch mit dem, was Microsoft intern selbst macht: Neue Updates werden zuerst an eine kleine, kontrollierbare Gruppe ausgeliefert. Falls ein Fehler auffällt, ist der Schaden klein und die breite Flotte hat das Update noch nicht. Erst wenn die Pilotgruppe stabil läuft, wandert das Update weiter in die nächste Gruppe.

Ein bewährtes Ring-Modell für Unternehmen sieht so aus:

  • Ring 0 – IT-Pilot (ca. 1-2% der Flotte): Deferral 0 Tage für Quality Updates, 0 Tage für Feature Updates. Diese Geräte bekommen alles sofort. Hier gehören die Geräte der IT-Abteilung hinein – wer andere mit Updates beglückt, soll die ersten Fehler selbst erleben.
  • Ring 1 – Pilot (ca. 5-10%): Quality-Deferral 3-5 Tage, Feature-Deferral 7 Tage. Freiwillige Testnutzer, besonders wichtige Testgeräte, Vertreter kritischer Abteilungen.
  • Ring 2 – Broad / Fast (ca. 80-90%): Quality-Deferral 7-10 Tage, Feature-Deferral 21-30 Tage. Die Standardbelegschaft.
  • Ring 3 – Kritische Systeme (Rest): Quality-Deferral 14-21 Tage (innerhalb der 30-Tage-Grenze!), Feature-Deferral 60-90 Tage. Produktionsnahe Systeme, Kassensysteme, Geräte mit kritischen Branchen-Apps, Entwicklungsmaschinen mit sensibler Toolchain.

Wichtig ist, dass Quality-Deferrals selbst im kritischsten Ring die 30-Tage-Grenze nie ausreizen. Ein unpatchedes Windows ist ein größeres Risiko als ein monatliches Update-Paket – Quality-Updates sind kumulativ und werden von Microsoft millionenfach getestet, bevor du sie nach 3 Wochen erhältst.

Update-Ring in Intune anlegen: Schritt für Schritt

In Intune sind WUfB-Policies über Geräte → Windows → Updates → Update-Ringe für Windows 10 und höher (im neuen Portal: Devices → Update rings for Windows 10 and later) konfiguriert. Alternativ – und für maximale Flexibilität – über den Settings Catalog mit der Kategorie „Windows Update for Business“. Wir gehen den Standardweg über die Update-Ringe:

  1. Intune-Portal öffnen → Devices → Update rings for Windows 10 and later → Create profile.
  2. Name und ggf. Beschreibung vergeben, z. B. „WUfB Ring 1 – Pilot“.
  3. Die Settings konfigurieren (Details unten).
  4. Zuweisen (Assignments) auf eine dynamische Device-Group, z. B. „GRP-Devices-WUfB-Ring1“.
  5. Erstellen – die Policy sync’t automatisch beim nächsten Geräte-Checkin.

Die wichtigsten Settings im Detail (Windows 10 und Windows 11 haben fast identische Settings, kleinere Namensunterschiede existieren):

  • Feature update deferral period (days): 0-365. Für den Pilot-Ring 0-7, für Broad 21-30, für kritische Ringe 60+.
  • Quality update deferral period (days): 0-30.
  • Pause feature updates / quality updates (days): 0-35. Diese Settings setzt du normalerweise NICHT dauerhaft in der Policy – sie sind für den Notfall. Besser: bei 0 belassen und nur im Incident-Fall hochsetzen (siehe unten).
  • Feature update deadline (days) / Quality update deadline (days): Ab Windows 10 21H2/Windows 11 verfügbar. Praxistipp: Quality-Deadline von 3-5 Tagen für Broad-Ringe bewirkt, dass Nutzer die Installation nicht ewig aufschieben können, aber trotzdem in der Nacht des Workdays selbst rebooten können.
  • Deadline grace period (days): Toleranz nach der Deadline für den Reboot, typisch 1-2 Tage.
  • Auto reboot before deadline: Wenn aktiviert, startet Windows auch ohne Nutzereingriff vor Ablauf der Deadline neu – ideal für Broad-Ringe mit geteilten oder wenig genutzten Geräten.
  • Change notification update level: Legt fest, ob Nutzer Vorab-Benachrichtigungen über anstehende Reboots erhalten („Default“ = Standardbenachrichtigungen, „Restart warnings only“ = weniger nervige Warnungen, „Disable all notifications“ = komplettes Silent-Update – nur für Server-artige Szenarien sinnvoll).
  • Engaged restart settings: Kontrolliert, wie der Nutzer den Reboot aktiv planen kann (Deadline für geplanten Reboot, Grace-Periode). Diese Settings werden von den Deadline-Settings in Windows 11 zunehmend ersetzt, sind aber für Windows 10-Geräte noch relevant.
  • Use deadline deadlines for feature updates / restart: Windows 11-spezifische Erweiterung der Deadline-Logik, z. B. sofortiger Download sobald verfügbar.
  • Windows 11 Feature-Update-Kanal: Hier darf in Produktivumgebungen immer nur „General Availability Channel“ stehen. Insider Channels (Beta/Dev/Canary) haben auf Produktivgeräten nichts verloren.
  • Automatic update behavior: Steuerung des klassischen Installationsverhaltens, z. B. „Install automatically and reboot at scheduled time“. Diese Setting greift auf die klassische AU-Logik und sollte mit den Deadlines konsistent sein.
  • Automatic maintenance time: Uhrzeit für die automatische Wartung – praxisrelevant für den Silent-Betrieb, wenn Updates nachts installiert werden sollen.
  • Delivery Optimization: Zwar technisch eine separate Policy, aber für WUfB-Flotten essenziell – ohne Delivery Optimization lädt jedes Gerät sein Feature-Update (mehrere GB) einzeln aus dem Microsoft-Cloud herunter. Mit aktivierter DO (Download mode „HTTP blended with peering behind the same NAT“) tauschen Geräte im lokalen Netzwerk Pakete untereinander aus und reduzieren den Internet-Traffic drastisch.

Hinweis zur Windows-Version: Die Deadline-Settings (Feature update deadline, Quality update deadline) erfordern Windows 10 ab Version 21H2 oder Windows 11. Auf älteren Windows-10-Builds werden diese Settings ignoriert – prüfe also deine Build-Verteilung, bevor du dich auf Deadlines als Kontrollmechanismus verlässt.

PowerShell: Update-Ring-Policies direkt anlegen und prüfen

Für größere Umgebungen lohnt sich die Automatisierung über das Microsoft Graph SDK. Das folgende Beispiel legt einen Pilot-Ring über die Graph API an:

# Voraussetzung: Microsoft.Graph.Beta Module installiert und verbunden
Install-Module Microsoft.Graph.Beta.DeviceManagement -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"

# Update-Ring "Pilot" anlegen (vereinfachtes Beispiel mit Kern-Settings)
$params = @{
    "@odata.type" = "#microsoft.graph.windowsUpdateForBusinessConfiguration"
    displayName = "WUfB Ring 1 - Pilot"
    description = "Pilot-Ring: schnelles Feedback, kleine Gruppe"
    featureUpdateDeferralPeriodInDays = 7
    qualityUpdateDeferralPeriodInDays = 3
    featureUpdateDeadlineInDays = 7
    qualityUpdateDeadlineInDays = 5
    deadlineGracePeriodInDays = 2
    windowsUpdateForBusinessUpdateWeeks = "everyWeek"
    automaticUpdateMode = "autoInstallAtMaintenanceTime"
}

New-MgBetaDeviceManagementDeviceConfiguration -BodyParameter $params

Und so prüfst du, welche WUfB-Policies ein bestimmtes Gerät tatsächlich erhalten hat – inklusive ihrer Einstellungen:

# Alle Update-Ring-Policies und ihre Zuweisungen auslesen
$rings = Get-MgBetaDeviceManagementDeviceConfiguration `
    -Filter "isof('#microsoft.graph.windowsUpdateForBusinessConfiguration')"

foreach ($ring in $rings) {
    Write-Host "Policy: $($ring.displayName)"
    Write-Host "  Feature-Deferral: $($ring.featureUpdateDeferralPeriodInDays) Tage"
    Write-Host "  Quality-Deferral: $($ring.qualityUpdateDeferralPeriodInDays) Tage"
    Write-Host "  Feature-Deadline: $($ring.featureUpdateDeadlineInDays) Tage"
}

Der 35-Tage-Pause im Notfall: Manöverkritik richtig umsetzen

Das klassische Szenario: Microsoft veröffentlicht ein monatliches Update, am Folgetag häufen sich weltweit Berichte über Bluescreens oder abstürzende VPN-Clients. Jetzt entscheiden Minuten. In Intune gehst du in den betroffenen Update-Ring und setzt „Quality update pause (days)“ auf z. B. 14. Die Policy geht in wenigen Minuten an alle Geräte, die bereits installiert haben, behalten das Update (deshalb ist der Pilot-Ring so wichtig – der Schaden bleibt dort begrenzt), aber alle Geräte, die noch nicht installiert haben, stoppen.

Über Graph geht der Notfall-Pause auch für hunderte Ringe in einem Rutsch:

# Alle Broad-Rings für Quality Updates um 14 Tage pausieren
$rings = Get-MgBetaDeviceManagementDeviceConfiguration `
    -Filter "isof('#microsoft.graph.windowsUpdateForBusinessConfiguration')" `
    | Where-Object { $_.displayName -like "*Broad*" }

foreach ($ring in $rings) {
    Update-MgBetaDeviceManagementDeviceConfiguration `
        -DeviceConfigurationId $ring.id `
        -QualityUpdatesPaused $true `
        -QualityUpdatesPauseExpiryDateTime ((Get-Date).AddDays(14))
}

Beachte: QualityUpdatesPauseExpiryDateTime ist ein absolutes Datum, kein „ab jetzt x Tage“-Wert. Pausen, die du vergisst aufzuheben, laufen automatisch ab – aber ein abgelaufener Pause bedeutet, dass alle zurückgestauten Updates sofort kommen. Plane also Pausen bewusst mit Ablaufdatum und dokumentiere sie.

Was die Policies auf dem Gerät anrichten: Registry-Realität

Intune-Update-Ringe landen als MDM-Policies auf dem Gerät und materialisieren sich in der Registry unter HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Für Troubleshooting und Audits ist dieser Schlüssel Gold wert:

# Effektive WUfB-Policies direkt aus der Registry lesen
$polPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$auPath  = "$polPath\AU"

Write-Host "=== Windows Update Policies ==="
Get-ItemProperty -Path $polPath -ErrorAction SilentlyContinue |
    Select-Object * -ExcludeProperty PS* | Format-List

# Typische Werte, die du dort sehen wirst (Beispiel Ring "Broad"):
# DeferralDays                   : 21          (Feature-Update-Deferral)
# DeferFeatureUpdates             : 1
# DeferQualityUpdates             : 1
# PauseFeatureUpdatesStartTime    :             (leer = keine Pause aktiv)
# SetPolicyDrivenUpdateSourceForFeatureUpdates : 1
# SetPolicyDrivenUpdateSourceForDriverUpdates  : 1

Write-Host "=== AU-Subkey (Verhalten) ==="
Get-ItemProperty -Path $auPath -ErrorAction SilentlyContinue |
    Select-Object * -ExcludeProperty PS* | Format-List

Wenn dieser Schlüssel fehlt oder leer ist, hat das Gerät keine WUfB-Policy erhalten – dann liegt das Problem bei der Intune-Zuweisung, nicht bei Windows Update selbst.

Best Practices: Ring-Design, das in Produktion überlebt

Ringe dynamisch denken – Filter statt manueller Gruppen

Feste Gruppen („Ring 1 = 20 handverlesene Geräte“) klingen gründlich, altern aber: Nach einem Jahr enthält Ring 1 Geräte von Nutzern, die längst in anderen Abteilungen arbeiten. Moderner Ansatz: dynamische Gruppen oder Filters, z. B. über Geräte-Eigenschaften wie Betriebssystem-Build, Abteilung (aus Entra ID), oder ein Device-Tag. In Intune-Syntax (Filters) kann ein Pilot-Ring z. B. so aussehen:

Filter-Regel (Managed Devices):
(device.deviceOwnership -eq "Corporate") and
(device.model -in ["Virtual Machine","Surface Laptop"]) and
(device.osVersion -startsWith "10.0.26")

Damit sind Pilot-Geräte automatisch die aktuelle Build-Generation – exakt die Geräte, die ein neues Feature Upgrade als Erste sehen sollen.

Safeguard Holds niemals aushebeln

Es gibt einen Registry-Wert (AllowWindowsSpotlight ist es nicht – der korrekte Mechanismus ist das Disable-WUfBSafeguards-Feature bzw. seit Windows 10 2004 das Policy-Element „Disable safeguards“), mit dem sich Safeguard Holds umgehen lassen. Das solltest du in Produktivumgebungen nicht tun. Safeguard Holds basieren auf realem, global gemessenen Telemetrie: Wenn Microsoft deinem Gerät das 24H2-Upgrade verweigert, liegt das fast immer an einem konkreten, dir möglicherweise noch nicht bekannten Problem auf genau diesem Gerät (alter Grafiktreiber, inkompatible App, defekter Treiber). Der Hold löst sich automatisch, sobald der Blocker behoben ist. Ausnahme: Lab-/Test-Umgebungen, wo du gezielt Upgrades gegen bekannte Halls testen willst.

Telemetrie für Reporting aktivieren

WUfB selbst funktioniert ohne Diagnosedaten, aber das Azure-Portal-basierte Windows Update Reports (Nachfolger von Update Compliance) braucht mindestens die Diagnosedaten-Ebene „Erforderlich“ (Basic). Aktiviere diese Ebene über eine Intune-Geräteeinschränkung oder Diagnostics-Policy, sonst fliegen deine Geräte blind durch die Pipeline. Windows Update Reports zeigen dir z. B. den aktuellen Update-Status pro Gerät, fehlgeschlagene Installationen und Safeguard-Hold-Ursachen – die zentrale Frühwarnstufe zwischen „Update ist da“ und „Nutzer meldet Problem“.

Die fünf Gebote des Ring-Designs

  • Gebot 1: Ring 0 gehört der IT. Jedes Update-Problem, das andere trifft, trifft zuerst dich selbst – der beste Trigger, Safeguard-Hold-Themen ernst zu nehmen.
  • Gebot 2: Quality-Updates niemals über 30 Tage, real nie über 21. Security first – ein monatliches Sicherheitsupdate ist kein optionaler Kandidat.
  • Gebot 3: Deadlines nur ab Ring 2. Im Pilot erzwingst du nichts – dort willst du Verhalten testen, nicht erzwingen.
  • Gebot 4: Delivery Optimization ist Pflicht. Ohne DO kostet ein Feature-Update-Rollout über 1.000 Geräte Terrabytes an redundantem Download.
  • Gebot 5: Halte Pausen-Runbooks bereit. Der Notfall-Pause ist dein wichtigstes Werkzeug – probiere ihn einmal im Jahr bewusst aus, bevor du ihn brauchst.

Konfliktvermeidung: Nie zwei Steuerungs-Quellen parallel

WUfB-Policies über Intune plus GPO-basierte Windows-Update-Settings parallel zu betreiben ist die häufigste Ursache für „Update-Chaos“ in hybriden Umgebungen. Typische Fehlkonfiguration: eine alte GPO setzt noch UseWUServer=1 mit einem WSUS, der längst stillgelegt wurde – die Geräte suchen dann gegen einen toten Endpunkt und finden nie Updates. Faustregel: Pro Update-Klasse (Feature, Quality, Treiber) existiert genau eine authoritative Quelle. In Co-Management-Szenarien (SCCM + Intune) wird das über die Co-Management-Slider geregelt („Windows Update policies“ auf Intune oder SCCM gestellt – nicht auf „Beide“).

Troubleshooting: Wenn Updates nicht kommen, wo sie sollen

Schritt 1: Hat das Gerät die Policy überhaupt?

Der erste Check gehört immer der Intune-Seite: Status der Policy im Portal prüfen (Devices → Update rings → deine Policy → „Device status“). Für das konkrete Gerät vor Ort ist der schnellste Weg der Registry-Check aus der Praxis-Sektion oben. Alternativ: MDM-Diagnostics mit mdmdiagnosticstool -area "DeviceManagement" -zip "C:\temp\mdmlogs.zip" – das ZIP enthält alle angewandten CSP-Policies inklusive WindowsUpdate-Adapter.

Schritt 2: Windows Update Scan manuell triggern und Logs lesen

Das klassische Windows-Update-Eventlog zeigt dir, was der Update-Client zuletzt gemacht hat:

# Scan manuell über den Update Session Orchestrator starten
Start-Process -FilePath "UsoClient.exe" -ArgumentList "StartInteractiveScan"

# Windows Update Log generieren (das ETW-Log ist nur so lesbar)
Get-WindowsUpdateLog

# Die letzten Scan-Ergebnisse aus dem Eventlog filtern
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 50 |
    Where-Object { $_.Message -match "scan|detect|install" } |
    Select-Object TimeCreated, Id, LevelDisplayName, @{n="Message";e={$_.Message.Substring(0, [Math]::Min(200, $_.Message.Length))}} |
    Format-Table -Wrap

Wichtige Event-IDs: 19 (Installation erfolgreich), 20 (Installation fehlgeschlagen – hier steht der Fehlercode), 25 (Reset/Recovery), 43 (Update wird als nicht anwendbar erkannt – oft der Hinweis auf Safeguard Holds).

Schritt 3: Der Blick in den Update-Store

Windows speichert den Update-Status in einer ESE-Datenbank. Der Windows Update Medic Service (WaaSMedicSvc) repariert sie bei Beschädigung automatisch, aber manchmal braucht er Hilfe:

# Status des Update Medic Service prüfen (sollte Running sein)
Get-Service WaaSMedicSvc, wuauserv, BITS, UsoSvc |
    Select-Object Name, Status, StartType

# SoftwareDistribution-Store zurücksetzen (der Klassiker, hilft bei korrumpierten Caches)
Stop-Service -Name wuauserv, bits -Force
Rename-Item "$env:SystemRoot\SoftwareDistribution" "$env:SystemRoot\SoftwareDistribution.bak"
Start-Service -Name bits, wuauserv

# Danach neuen Scan triggern - Windows baut den Store neu auf
UsoClient StartInteractiveScan

Typische Fehlerbilder und ihre Lösungen

  • Gerät ignoriert Quality-Update-Deferral, Updates kommen sofort: Prüfe, ob tatsächlich die richtige Policy zugewiesen ist. Häufige Ursache ist ein Konflikt mit einer zweiten Update-Ring-Policy – bei Konflikten gewinnt in der Regel die Policy mit dem restriktiveren (früheren) Datum. Außerdem wichtig: Das Deferral zählt ab dem Tag, den Microsoft als Veröffentlichungstag des Updates definiert hat – nicht ab dem Tag, an dem du die Policy gesetzt hast. Eine Policy-Änderung wirkt nicht rückwirkend auf Updates, die das Gerät bereits als „fällig“ eingestuft hat.
  • Feature-Update (z. B. 24H2) wird nie angeboten, obwohl Deferral abgelaufen: Zu 90% ein Safeguard Hold. Diagnose: In Windows Update Reports (Azure) nach dem Gerät suchen, dort steht die Hold-Reason. Oder lokal im Setupact-Log: Select-String -Path "$env:SystemRoot\Panther\setupact.log" -Pattern "Safeguard" -Context 2,5.
  • Fehler 0x80240438, 0x80072EE2 oder 0x80072EFD: Netzwerk-/Proxy-Probleme auf dem Weg zu Windows Update. Prüfe Proxy-Ausnahmen für *.windowsupdate.com und *.deliveryoptimization.com in der Firewall und im Proxy (SSL-Inspection deaktivieren für diese Domains!).
  • Fehler 0x80240017: Update-Paket für falsche Architektur/Sprache oder blockierter Treiber – häufig bei manueller Installation von ausgesuchten MSU-Dateien. In WUfB-Flotten selten, aber ein klassischer Diagnose-Punkt.
  • Gerät meldet „Ihr Gerät ist auf dem neuesten Stand“, obwohl Updates fehlen: Prüfe, ob das Gerät gegen einen WSUS/Update-Server zeigt (Registry: UseWUServer unter HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU). Wert 1 = alter Dual-Scan-Zustand, der bei stillgelegtem WSUS genau dieses Symptom produziert.
  • Neustart-Schleife nach Feature-Update: setuperr.log unter C:\$WINDOWS.~BT\Sources\Panther\ prüfen; klassische Ursachen sind alte Drittanbieter-Treiber (v. a. VPN, Antivirus) – ein weiteres Argument für gestaffelte Ringe, weil genau solche Treiber im Pilot-Ring auffallen.

Der Diagnose-Allrounder in einem Skript

Für den Support-Alltag lohnt sich ein Kombiskript, das alle kritischen Punkte in einem Durchlauf prüft:

# Quick-Diagnose WUfB (als Admin ausführen)
Write-Host "== Services ==" -ForegroundColor Cyan
Get-Service wuauserv, BITS, UsoSvc, WaaSMedicSvc | Format-Table Name, Status, StartType

Write-Host "== WUfB Policies (Registry) ==" -ForegroundColor Cyan
$wu = Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" -ErrorAction SilentlyContinue
if (-not $wu) { Write-Warning "KEINE WUfB-Policies gefunden - Policy fehlt oder nicht angewandt!" }
else { $wu | Select-Object DeferralDays, DeferFeatureUpdates, DeferQualityUpdates, Pause* | Format-List }

Write-Host "== Update-Server (Dual-Scan-Check) ==" -ForegroundColor Cyan
$au = Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -ErrorAction SilentlyContinue
if ($au.UseWUServer -eq 1) { Write-Warning "UseWUServer=1 - GERAET ZEIGT AUF WSUS: $($au.WUServer)" }
else { Write-Host "OK - Windows Update (Microsoft) wird direkt genutzt" }

Write-Host "== Letzte Fehler aus Eventlog ==" -ForegroundColor Cyan
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 200 |
    Where-Object { $_.LevelDisplayName -eq "Error" } |
    Select-Object -First 5 TimeCreated, Id, @{n="Msg";e={$_.Message.Substring(0,[Math]::Min(150,$_.Message.Length))}} |
    Format-List

Fazit: Weniger Genehmigungs-Overhead, mehr Kontrolle durch Geschwindigkeit

Windows Update for Business ist ein Paradigmenwechsel: weg von „ich genehmige jedes Update manuell“ hin zu „Microsoft veröffentlicht, ich definiere nur, wie schnell welche Geräte folgen“. In Verbindung mit einem sauberen Ring-Modell – IT-Pilot, Pilot, Broad, kritische Systeme – bekommst du eine Patch-Infrastruktur, die nahezu ohne operativen Overhead läuft und gleichzeitig ein kontrolliertes Risiko-Management bietet: Der Pilot-Ring fängt die Probleme ab, Deadlines verhindern endlose Nutzer-Prokrastination, Pausen stoppen im Notfall die gesamte Flotte in Minuten, und Safeguard Holds schützen Geräte, auf denen Microsoft ein konkretes Kompatibilitätsproblem erkannt hat.

Der häufigste Fehler in der Praxis ist nicht die Technologie, sondern das Ring-Design: zu große Pilot-Gruppen, Quality-Deferrals jenseits jeder Sicherheitsvernunft, oder parallele GPO-Altlasten, die die WUfB-Policies konterkarieren. Wenn du die fünf Gebote aus dem Best-Practices-Kapitel befolgst, dein Delivery Optimization aktivierst, dein Reporting über Windows Update Reports anbindest und den Diagnose-Werkzeugkasten aus dem Troubleshooting-Kapitel einmal durchgespielt hast, dann ist WUfB der stabileste und ressourcenschonendste Weg, eine Windows-Flotte aktuell zu halten – ganz ohne WSUS, ohne SCCM und ohne einen einzigen manuellen Genehmigungsschritt.