Sektion 22: WUfB: Feature Updates & Quality Updates steuern

WUfB in Intune: Feature Updates und Quality Updates wirklich steuern

Windows Update for Business (WUfB) ist keine eigenständige Technologie, die man neben Intune installiert – sie ist das Steuerungsmodell, das Microsoft seit Windows 10 direkt ins Betriebssystem eingebaut hat. Intune ist in diesem Setup nichts anderes als die Verwaltungsoberfläche, die WUfB-Richtlinien per OMA-URI bzw. Settings-Catalog in Richtung Windows-Client schickt. Wer das verstanden hat, versteht auch, warum es keine „Intune-Updates“ gibt: Der Windows Update-Agent (WUA) und der Update Session Orchestrator (USO) holen die Updates weiterhin direkt von Windows Update, Microsoft Update oder Windows Server Update Services (WSUS) – Intune entscheidet nur, wann und was installiert wird.

Diese Sektion behandelt die beiden zentralen Steuerungselemente: Update Rings für Quality Updates und Feature Update Profiles für Versionssprünge. Beide zusammen bilden das vollständige Update-Management für Windows-Geräte ohne klassische Infrastruktur.

Grundkonzepte: Die zwei Update-Kanäle von Windows

Quality Updates

Quality Updates sind die monatlichen kumulativen Updates, die an jedem zweiten Dienstag des Monats (Patch Tuesday) erscheinen. Sie enthalten Sicherheitskorrekturen, Bugfixes und gelegentlich kleinere Funktionsänderungen. Entscheidend: Quality Updates sind kumulativ – wer das Oktober-Update installiert, erhält automatisch den kompletten Inhalt aller vorherigen Updates. Ein „Selektieren“ einzelner Fixes ist nur über Out-of-Band-Pakete oder Hotpatching möglich, nicht über den normalen WUfB-Weg.

Quality Updates folgen einem festen Rhythmus:

B-Release (Patch Tuesday): Das reguläre kumulative Update, für die breite Masse gedacht.
C-Release (dritte Woche): Preview-Updates mit nicht-sicherheitsrelevanten Fixes – optional, werden aber im nächsten B-Release ohnehin ausgeliefert.
Out-of-Band-Releases: Notfall-Patches für kritische, aktiv ausgenutzte Lücken (z. B. Zero-Days), sofort nach Veröffentlichung ohne Deferral-Zeit.

Feature Updates

Feature Updates sind die einmal jährlich erscheinenden Versionssprünge von Windows (z. B. Windows 11 24H2 auf 25H2). Technisch sind sie ein komplettes Betriebssystem-Upgrade per Setup-Engine – deshalb gelten für sie andere Steuerungsparameter, ein anderes Fehlerverhalten und ein eigenes Deployment-Modell in Intune. Ein Feature Update wird nicht über den normalen WUA-Kanal installiert, sondern über die SetupEngine mit eigenem Rollback-Verhalten und eigenen Protokollen (setupact.log, setuperr.log).

Deferrals, Pause und Safeguard Holds

Bevor wir in die Intune-Implementierung einsteigen, die drei Konzepte, die in jeder WUfB-Diskussion auftauchen:

Deferral (Rückstellung): Zeitfenster in Tagen, das zwischen Veröffentlichung eines Updates durch Microsoft und der Installation auf dem Client liegt. Standard für Quality Updates sind 7 Tage, maximal 30 Tage. Feature Updates können bis zu 365 Tage zurückgestellt werden.
Deadline: Hartes Installationsdatum – nach Ablauf wird die Installation erzwungen, inklusive automatischem Neustart. Deadlines sind der moderne Ersatz für klassische „Patch-Nights“.
Safeguard Holds: Microsoft blockiert die Installation von Feature Updates auf Geräten, bei denen bekannte Kompatibilitätsprobleme mit der Zielversion existieren (Treiber, Anwendungen, Hardware). Safeguard Holds sind der häufigste Grund, warum ein Feature-Update-Deployment bei 80–95 % hängen bleibt – obwohl laut Intune alles zugewiesen ist. Holds kann man für Testgeräte per Target Release-Registry-Key umgehen (dazu später mehr).

Praxis-Implementierung: Update Rings für Quality Updates

Der Update Ring im Detail

Ein Update Ring ist ein Richtlinienobjekt in Intune, das alle Quality-Update-Parameter bündelt: Deferral, Deadline, Neustartverhalten, Arbeitszeiten und mehr. Ein Update Ring definiert ausdrücklich nicht, welches Update installiert wird – nur das Zeitverhalten. Das Update selbst kommt immer von Windows Update.

Die Parameter im Überblick (Intune Portal: Devices → Windows → Update Rings):

Feature update deferral period: 0–365 Tage. Greift für Feature Updates, wird aber typischerweise in Feature-Update-Profilen überschrieben (dort ist die Zielversion fix, der Deferral läuft gegen die Versionsverfügbarkeit).
Quality update deferral period: 0–30 Tage. Der Hebel für Patch Tuesday. 7 Tage sind ein guter Startwert für Pilot-Ringe.
Update deadline (Feature/Quality): 0–30 Tage bzw. 1–30 Tage für Quality Updates. Nach Ablauf: erzwungene Installation.
Grace period: 0–7 Tage zusätzlich nach der Deadline, bevor der Neustart erzwungen wird.
Auto-reboot: Ob der Neustart außerhalb der Arbeitszeiten automatisch erfolgt. Seit Windows 10 1809 auch die Option, den Neustart aktiv in die Arbeitszeiten zu legen („Engaged restart“ ist out, Auto-Reboot ist in).
Opt in to preview builds / Delivery Optimization / User access: Preview-Teilnahme, DO-Regeln und ob Nutzer Einstellungen in den Windows-Einstellungen selbst ändern dürfen.

Ring-Strategie: Deployment in Wellen

Der praktische Standard ist ein 3–4-stufiges Wellenmodell:

Ring 0 (Canary/Test): 5–10 Geräte, Deferral 0 Tage, Deadline 1 Tag. Bekommt jeden Patch sofort – hier sollen Fehler zuerst auftreten.
Ring 1 (Pilot/IT): IT-Team und Early Adopter, Deferral 3 Tage, Deadline 3 Tage.
Ring 2 (Broad Early): 10–20 % der Flotte, Deferral 7 Tage, Deadline 7 Tage.
Ring 3 (Broad): Restliche Flotte, Deferral 10–14 Tage, Deadline 14 Tage + Grace Period.

Der Punkt, der in der Praxis fast immer falsch gemacht wird: Deadlines wirken pro Update-Release, nicht pro Kalenderdatum. Ein Deferral von 7 Tagen und eine Deadline von 7 Tagen ergeben zusammen: Das Update erscheint am Patch Tuesday, wird ab Tag 7 für die Installation sichtbar und am Tag 14 erzwungen. Der Rechner läuft also immer gegen den Release-Tag des jeweiligen Updates – das Modell skaliert automatisch mit jedem Patch Tuesday, ohne dass man etwas anfassen muss.

Update Ring per Graph API erstellen

Für alle, die Intune als Code betreiben (und das solltest du spätestens ab dieser Sektion), hier das komplette Erstellen eines Update Rings über die Microsoft Graph API:

# Voraussetzungen: Microsoft.Graph.Beta Module
Install-Module Microsoft.Graph.Beta -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"

$params = @{
    "@odata.type" = "#microsoft.graph.windowsUpdateForBusinessUpdateRing"
    displayName = "WUfB - Ring 2 - Broad Early"
    description = "Quality Updates: 7 Tage Deferral, 7 Tage Deadline"
    deferralPeriodMinutes = 0          # Preview-Releases: nicht anbieten
    featureUpdateDeferralDays = 0     # Feature Updates laufen ueber separates Profil
    qualityUpdateDeferralDays = 7     # Patch Tuesday + 7
    featureUpdatePauseDays = 0
    qualityUpdatePauseDays = 0
    featureUpdateTimeOfDay = "00:00:00"
    qualityUpdateTimeOfDay = "00:00:00"
    featureUpdateDeadlineDays = 0
    qualityUpdateDeadlineDays = 7
    featureUpdatePauseStartDate = "0000-00-00"
    qualityUpdatePauseStartDate = "0000-00-00"
    qualityUpdateDeadline = $null
    featureUpdateDeadline = $null
    featureUpdateRollbackWindowDays = 14
    engagementLevelDeferralDays = 0
    prereleaseFeatureUpdatesEnabled = $false
    deadlineForFeatureUpdatesInDays = 0
    deadlineForQualityUpdatesInDays = 7
    gracePeriodDays = 2
    rebootOnDeadline = $true
    prereleaseQualityUpdatesEnabled = $false
}

New-MgBetaDeviceManagementWindowsUpdateForBusinessUpdateRing -BodyParameter $params

Anschließend das Assignment – hier auf eine dynamische Gerätegruppe, die alle Pilot-Geräte enthält:

$ring = Get-MgBetaDeviceManagementWindowsUpdateForBusinessUpdateRing `
    -Filter "displayName eq 'WUfB - Ring 2 - Broad Early'"

$group = Get-MgBetaGroup -Filter "displayName eq 'GRP-INTUNE-WUFB-PILOT'"

New-MgBetaDeviceManagementWindowsUpdateForBusinessUpdateRingAssignment `
    -WindowsUpdateForBusinessUpdateRingId $ring.Id `
    -Target "@odata.type=#!microsoft.graph.groupAssignmentTarget,groupId=$($group.Id)"

Für Compliance-Reporting oder die eigene Automatisierung lohnt ein Lookup aller Ringe inklusive Status:

Get-MgBetaDeviceManagementWindowsUpdateForBusinessUpdateRing | `
    Select-Object DisplayName, QualityUpdateDeferralDays, `
    QualityUpdateDeadlineDays, GracePeriodDays | Format-Table

Praxis-Implementierung: Feature Updates steuern

Feature Update Profiles: Die Version als Zielobjekt

Feature Updates werden in Intune nicht über den Ring gesteuert, sondern über ein eigenes Profil (Devices → Windows → Feature Updates). Hier definiert man explizit die Zielversion, z. B. „Windows 11 24H2“. Das Gerät bleibt auf dieser Version, bis das Profil geändert wird – das ist der entscheidende Unterschied zum alten Windows-10-Modell, bei dem Geräte automatisch auf die neueste Version rollten.

Daraus folgt der wichtigste operative Grundsatz des modernen Windows-Update-Managements: Feature Updates sind ein Projekt, Quality Updates sind ein Prozess. Ein Feature-Update-Rollout plant man einmal pro Jahr mit Tests, Anwendungsvalidierung und Kommunikation. Quality Updates laufen monatlich automatisch – und wenn die Ringe einmal sauber konfiguriert sind, darf man sie wortwörtlich ein Jahr nicht anfassen.

Das Feature-Update-Profil anlegen

Im Portal sind nur wenige Felder relevant: der Anzeigename, die Feature-Version, das Rollout als „Make update available immediately“ oder „Make update available gradually“ (für gestaffelte Ausrollung) sowie die Assignment-Gruppen. Per Graph API sieht das so aus:

$featureProfile = @{
    "@odata.type" = "#microsoft.graph.windowsFeatureUpdateProfile"
    displayName = "WUfB - Feature Update - Windows 11 24H2 - Ring 1"
    description = "Rollout 24H2 auf Pilot-Geraete"
    featureUpdateVersion = "Windows 11, version 24H2"
    rolloutSettings = @{
        "@odata.type" = "microsoft.graph.windowsUpdateRolloutSettings"
        startDateTime = "2026-10-14T00:00:00Z"
        endDateTime = "2026-11-14T00:00:00Z"
    }
}

New-MgBetaDeviceManagementWindowsFeatureUpdateProfile `
    -BodyParameter $featureProfile

Der Rollout zwischen startDateTime und endDateTime verteilt die Geräte gleichmäßig über den Zeitraum – Intune errechnet pro Tag, welcher Anteil der Zielgeräte das Update erhält. Das ist eleganter als das manuelle Verschieben von Gruppen und verhindert den „Big Bang“ an einem einzigen Tag.

Target Release: Versionen gegen Microsofts Wollen fixieren

Ohne Steuerung nähert sich jedes Windows-11-Gerät langsam der neuesten Version an (Semi-Annual Channel). Wer das verhindern will, weil z. B. die eigene Anwendungszertifizierung noch für 24H2 läuft, setzt über den Settings Catalog die Richtlinie Target Release Version:

Pfad: Administrative Templates / Windows Components / Windows Update
      / Manage updates offered from Windows Server Update Service

OMA-URI: ./Vendor/MSFT/Policy/Config/Update/TargetReleaseVersion
Typ:      Integer (1)

OMA-URI: ./Vendor/MSFT/Policy/Config/Update/ProductVersion
Typ:      String
Wert:     "Windows 11"
OMA-URI: ./Vendor/MSFT/Policy/Config/Update/TargetReleaseVersionInfo
Wert:     "24H2"

Mit dieser Kombination wird dem WUA mitgeteilt: Bleib auf 24H2, egal was sonst passiert. Das schützt auch vor dem klassischen Fehler, bei dem ein Gerät nach einem Hardwaretausch oder Reset plötzlich die neueste Version ausliefert, obwohl der Rest der Flotte noch validiert.

Expedited Quality Updates: Der Notfallhebel

Seit einiger Zeit bietet Intune Windows Quality Update Policies (Expedited Updates) – die Option, ein bestimmtes kumulatives Update sofort und ohne Ablauf der Deferral-Zeit zu erzwingen. Der Anwendungsfall ist klar: Zero-Day-Exploits. Statt 30 Tage Deferral abzuwarten, kann man z. B. das Out-of-Band-Update vom Vortag per Policy an die komplette Flotte zwingen, mit Restart-Deadline von wenigen Stunden. Das ist kein Ersatz für das Ring-Modell, sondern der Ausbruch daraus im Krisenfall – und genau so sollte man es dokumentieren und verwenden.

Delivery Optimization: Bandbreite im Griff behalten

Wo Windows Update direkt geliefert wird, muss auch der Transport gesteuert werden. Delivery Optimization (DO) lässt Windows-Geräte Updates peers im lokalen Netzwerk und im Internet ziehen, statt jede Maschine einzeln von Microsoft-CDNs laden zu lassen. In Intune wird DO über die Update-Ring-Einstellungen oder den Settings Catalog konfiguriert. Die wichtigsten Modi:

HTTP only: Klassisch, jede Maschine lädt selbst – nur für kleine Umgebungen.
LAN (1): Peering nur im gleichen Subnetz (Gruppenmodus 1). Standard für Office-Umgebungen.
Group (2): Peering über Geräte, die denselben DO-Gruppen-Hash teilen (z. B. gleiche Entra-Tenant-ID) – auch über Subnetzgrenzen hinweg.
Internet (3): Zusätzlich Internet-Peers – nicht empfehlenswert in regulierten Umgebungen.
Simple (99): Deaktiviert Peering, nur HTTP mit Caching.

Zwei DO-Einstellungen haben in der Praxis den größten Effekt: DODownloadMode (der Modus selbst) und MinimumDiskSpaceLimitForPeerCaching – ohne genug freien Platz greift das Peering-Geräte-Caching nicht, und alle laden einzeln. Für Filialen mit schmalem Upstream ist Group-Mode der sweet spot: Das erste Gerät lädt das Update, alle weiteren bedienen sich daran.

Best Practices aus realen Deployments

Trenne Feature- und Quality-Steuerung konsequent. Feature Updates laufen über Profile mit fester Zielversion, Quality Updates über Ringe mit Deferral/Deadline. Wer beides in einem Ring mischt, verliert die Kontrolle über beides.
Planse Safeguard Holds ein. Wenn ein Feature-Rollout bei ~90 % kleben bleibt, ist das in 9 von 10 Fällen ein Hold, kein Fehler. Prüfe den Status unter Windows Update → „Update available but holds applied“, bevor du Fehlerdiagnose machst.
Nutze dynamische Entra-Gerätegruppen für Ringe. Ein Tag wie `deviceTag = „WUfB-Pilot“` erlaubt, Geräte per Autopilot-Device-Preparation-Tag flexibel zwischen Ringen zu verschieben – ohne manuelle Gruppenpflege.
Dokumentiere die Ring-Logik mit Kalenderbezug. Deferral 7 + Deadline 7 heißt für den Endanwender konkret: „Patch kommt spätestens 14 Tage nach Patch Tuesday mit Neustart“. Diese Vorhersagbarkeit ist der halbe Support-Erfolg.
Co-Management beachten: In Co-Managed-Umgebungen kann die Workload „Windows Update Policies“ bei Intune oder ConfigMgr liegen. Beide gleichzeitig ist unsinnig – und wenn der ConfigMgr-Client denkt, er sei zuständig, ignoriert er Intune-Ringe vollständig (SlidingWindow/COMAnforderungen).
Verwende Update Compliance bzw. Windows Update Reports (Azure Monitor). Ohne Reporting ist WUfB blind: Der Intune-Report zeigt nur, ob die Policy zugewiesen ist, nicht ob sie wirkt. Für Fehlersuche auf Einzelgeräten ist die Windows-Update-Log-Analyse unersetzlich (siehe unten).

Troubleshooting: Wenn Updates nicht kommen

Typische Fehlerbilder und deren Ursachen

Gerät zeigt „You’re up to date“, obwohl Patch Tuesday vorbei ist: Meist ein aktiver Safeguard Hold oder ein Deferral, das noch läuft. Prüfen lässt sich das mit dem Update-Status im Eventlog:

Get-WinEvent -LogName `
  "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 50 |
  Where-Object Id -in 19,20,25,31,43 |
  Select-Object TimeCreated, Id, Message |
  Format-List

Event ID 43 meldet z. B. blockierte Updates inklusive Fehlerursache – dort tauchen Safeguard Holds als „installation blocked by a hold“ auf.

Policy kommt auf dem Gerät nicht an: Der Klassiker bei WUfB-Problemen. Auf dem Client prüfen, ob die Richtlinie überhaupt in der Registry landet:

# Deferral-Werte des WUA pruefen (Registry)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update" |
  Select-Object *Deferral*, *Deadline*, *Pause*

# Komplettes Windows-Update-Protokoll lesbar aufbereiten
Get-WindowsUpdateLog

Get-WindowsUpdateLog konvertiert die kryptischen ETL-Dateien des WUA in ein lesbares Protokoll – dort sieht man, ob der Client den Windows-Update-Dienst kontaktiert, welche Policies er empfangen hat und ob er Updates als „nicht anwendbar“ verwirft. Das sollte das erste Werkzeug bei jedem Update-Problem sein, nicht das letzte.

Feature Update startet nicht, obwohl Profil zugewiesen: Reihenfolge der Prüfung:

Ist das Feature-Update-Profil wirklich der Gruppe zugewiesen, in der das Gerät Mitglied ist? (Gruppenmitgliedschaft dynamisch prüfen, nicht vermuten.)
Hat das Gerät ausreichend Disk Space (min. ~20 GB frei für 24H2)?
Läuft der Windows-Setup-Prozess und bricht ab? Dann setupact.log prüfen: C:\$Windows.~BT\Sources\Panther\setupact.log – die Datei nennt kompatibilitätsbedingte Blocker mit exakter Ursache.
Safeguard Hold aktiv? Für Testgeräte lässt sich ein Hold umgehen (nur für Validierung, nie breit):

Registrierung: HKLM:\SYSTEM\Setup\LabConfig
Wert: BypassTPMCheck / BypassSecureBootCheck / BypassRAMCheck (DWORD 1)

Fuer Target-Release-Skip im Test:
Set-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" `
    -Name TargetReleaseVersionInfo -Value "24H2"

Intune zeigt „Not applicable“ oder Fehler 0x80240438 / 0x8024001e: Das sind typische Proxy- bzw. Content-Fehler. 0x80240438 ist fast immer ein Authentifizierungsproblem am Proxy – der WUA kann sich nicht am Proxy authentifizieren, wenn er im SYSTEM-Kontext läuft. Lösung: Proxy-Ausnahme für die Update-Endpoints oder Proxy-Authentifizierung per WUA-spezifischer Konfiguration. 0x8024001e deutet auf korrupten SoftwareDistribution-Store hin:

Stop-Service wuauserv, bits -Force
Rename-Item C:\Windows\SoftwareDistribution SoftwareDistribution.old
Start-Service wuauserv, bits
# Danach Scan erzwingen:
usoclient StartScan

Deadlines greifen nicht: Der häufigste Overlap-Bug: Wenn noch eine ältere WSUS/ConfigMgr-GPO aktiv ist (Reste aus Migrationsumgebungen), gewinnen lokale GPOs die Priorität gegen Intune-Richtlinien. Prüfen:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" |
  Format-List

Finden sich hier Werte wie DoNotConnectToWindowsUpdateInternetLocations = 1 oder ein gesetzter WSUSServer, ist eine Legacy-Policy im Spiel, die zuerst entfernt werden muss – sonst sind alle Intune-Ringe wirkungslos.

Fazit: Der kontrollierte Verzicht auf Infrastruktur

Windows Update for Business über Intune ist die konsequenteste Form des modernen Update-Managements: keine Patchserver, keine Maintenance-Windows-Skripte, keine WSUS-Cleanup-Wochenenden. Stattdessen zwei bewährte Steuerungsobjekte – Update Rings für den monatlichen Quality-Update-Prozess, Feature-Update-Profile für den jährlichen Versionssprung – plus Delivery Optimization für den Transport und Expedited Updates als Notfallhebel.

Der Lohn für die saubere Trennung dieser Ebenen ist enorme Vorhersagbarkeit: Nutzer wissen, dass ihr Gerät spätestens zwei Wochen nach Patch Tuesday gepatcht und neu gestartet wird. IT-Teams wissen, dass die Pilotgruppe jeden Patch vier Tage vor der Flotte erhält und Probleme so nie die breite Masse erreichen. Und das Feature-Update-Projekt ist – im Gegensatz zum klassischen In-Place-Migrationstheater von SCCM-Zeiten – ein einziges Profil mit einem Start- und Enddatum.

Der Preis dafür ist die Notwendigkeit, die zugrunde liegenden Mechanismen wirklich zu verstehen: Deferrals, Deadlines und Safeguard Holds interagieren miteinander, und wer nur Portalklicks kennt, steht bei einem bei 90 % hängenden Rollout ohne Diagnoseansatz da. Mit Get-WindowsUpdateLog, dem WUA-Eventlog und einem sauberen Ring-Design ist man dagegen für 95 % aller realen WUfB-Situationen gewappnet. Die nächsten Sektionen bauen darauf auf und integrieren Neustart-Steuerung, Update-Compliance-Reporting und Driver/Firmware-Updates in dieses Fundament.