Schlüsselpunkte
- Fehlgeschlagene Patches erkennen: Nutzen Sie PowerShell (PSWindowsUpdate oder Ereignisprotokolle), um fehlgeschlagene oder unvollständige Update-Versuche vor einem erneuten Versuch zu identifizieren.
- Installation per PowerShell wiederholen: Starten Sie fehlgeschlagene Updates erneut, mit skriptbasierter Logik und Fehlerbehandlung, damit nichts unbemerkt scheitert.
- Wiederholungsversuche nachverfolgen: Speichern Sie Zähler, Zeitstempel und fehlgeschlagene KBs in der Registry, um Endlosschleifen zu vermeiden und den Überblick zu behalten.
- Mit geplanten Aufgaben oder RMM automatisieren: Planen Sie wiederkehrende Retry-Skripte ein oder stellen Sie sie mit NinjaOne, GPO oder vergleichbaren Tools im großen Maßstab bereit.
- Update-Bedingungen prüfen: Stellen Sie sicher, dass die Update-Quellen erreichbar sind, und starten Sie den Windows Update-Dienst vor dem erneuten Versuch neu, um die Erfolgsquote zu erhöhen.
Fehlgeschlagene Updates sind eine wiederkehrende Herausforderung im Patch-Management, häufig ausgelöst durch Netzwerkprobleme, Systemsperren oder Dienstkonflikte. Bleiben sie ungelöst, leidet die Systemstabilität und Endpunkte werden angreifbar.
Ein automatisierter Patch-Retry senkt diese Risiken, verkürzt die mittlere Reparaturzeit (MTTR) und erhöht die Erfolgsquote von Updates, ohne Techniker:innen mit hohem Ticketaufkommen zu belasten.
Standardisieren Sie Ihre Patch-Workflows und verbessern Sie MTTR und Dokumentation.
→ Testen Sie NinjaOne Autonomes Patch-Management kostenlos
So automatisieren Sie den Patch-Retry und fangen fehlgeschlagene Updates ab
Die automatisierte Behebung von Patch-Fehlern erspart hektische manuelle Diagnosen und sichert die Patch-Compliance auf allen Endpunkten. Das reduziert den Aufwand für Techniker:innen und macht über Protokolle gleichzeitig sichtbar, welche Fehler immer wieder auftreten.
📌 Anwendungsfälle: Mit PowerShell-Skripten lassen sich vergangene Update-Versuche auflisten und Fehlercodes auslesen, sodass Skripte erneut versuchen, pausieren oder abbrechen können. Über geplante Aufgaben, RMM-Plattformen und GPO-Bereitstellung können Techniker:innen den Patch-Retry für fehlgeschlagene oder fehlende Updates automatisieren.
📌 Voraussetzungen:
- Unterstütztes Betriebssystem: Windows 11 oder Windows Server 2016 und neuer
- Berechtigungen: Administrator- oder SYSTEM-Rechte
- Update-Quelle: WSUS, Intune oder Windows Update
- Optional: RMM-Plattformen wie NinjaOne
💡 Hinweis: Einzelne Schritte können je nach Systemstandards oder aktiven Einstellungen in Ihrer Umgebung abweichen. Microsoft hat außerdem angekündigt, WSUS einzustellen. Zum Zeitpunkt der Veröffentlichung wird es zwar noch mit Windows ausgeliefert, wir empfehlen jedoch den Umstieg auf Cloud-Tools wie Windows Autopatch und Intune oder Azure Update Manager.
Schritt 1: Fehlgeschlagene Patches mit PowerShell-Skripten identifizieren
Eine wirksame automatisierte Behebung von Patch-Fehlern beginnt mit proaktiver Erkennung. Die folgenden Skripte fragen den Update-Verlauf und die Ergebnisse eines Endpunkts ab und geben die problematischen Einträge zurück.
Fehlgeschlagene Patches mit dem Modul PSWindowsUpdate filtern
Dieses Skript liest die letzten 200 Einträge des Update-Verlaufs, filtert erfolgreiche Installationen heraus und gibt nur die fehlgeschlagenen Einträge aus.
| Import-Module PSWindowsUpdate # Retrieve failed updates $failedUpdates = Get-WindowsUpdate -IsHidden:$false -ErrorAction SilentlyContinue | Where-Object { $_.ResultCode -ne 2 } # 2 = Succeeded |
⚠️ Wichtig: Wird PSWindowsUpdate nicht installiert, treten Fehler auf, denn dieses PowerShell-Modul ist in Windows standardmäßig nicht enthalten. (Siehe ⚠️ Darauf sollten Sie achten)
Alternative: Fehlgeschlagene Patches über das Windows-Ereignisprotokoll filtern
Dieses Skript durchsucht die Protokolle des Windows Update-Clients nach Einträgen mit typischen Fehlersignalen wie den IDs 20, 25 und 31.
Get-WinEvent -LogName "System" | Where-Object {$_.ProviderName -eq „Microsoft-Windows-WindowsUpdateClient“ -and $_.Id -in 20, 25, 31 # Common failure event IDs } |
Schritt 2: Fehlgeschlagene Patches per PowerShell-Logik erneut versuchen
Sobald fehlgeschlagene Updates auf einem Endpunkt auftauchen, können Sie Patches per PowerShell-Skript automatisiert erneut anstoßen. Damit entfällt das manuelle Patching und die Behebung läuft nach erkanntem Patch-Fehler ohne Zutun im großen Maßstab.
Beispielskript in PowerShell für die erneute Installation fehlgeschlagener Updates
Dieses Skript baut auf $failedUpdates aus Schritt 1 auf und durchläuft die ermittelten fehlgeschlagenen Updates zur Neuinstallation.
| foreach ($update in $failedUpdates) { Write-Output „Retrying: $($update.Title)“ Install-WindowsUpdate -KBArticleID $update.KBArticleID -AcceptAll -AutoReboot -IgnoreReboot -ErrorAction Continue } |
Beispielskript mit Fehlerbehandlung
| try { Install-WindowsUpdate -KBArticleID $update.KBArticleID -AcceptAll -ErrorAction Stop } catch { Write-Output „Retry failed for: $($update.KBArticleID) – $_“ } |
⚠️ Wichtig: Setzen Sie Fehlerbehandlung ein, damit Skripte nicht unbemerkt scheitern. (Siehe ⚠️ Darauf sollten Sie achten.)
Schritt 3: Wiederholungsversuche über die Registry protokollieren und nachverfolgen
Nutzen Sie die Registry, um die Anzahl der Wiederholungsversuche und die fehlgeschlagenen KBs für schnelle lokale Abfragen zu speichern. So bleibt die Zuordnung auch dann erhalten, wenn ein Endpunkt während eines WSUS- oder RMM-Ausfalls getrennt ist.
Beispielskript in PowerShell zum Nachverfolgen von Wiederholungsversuchen und Ergebnis-Zeitstempeln in der Registry:
New-Item -Path "HKLM:\SOFTWARE\Org\PatchRetry" -ForceSet-ItemProperty -Path "HKLM:\SOFTWARE\Org\PatchRetry" -Name "LastRetry" -Value (Get-Date).ToString(„u“)Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\PatchRetry" -Name "FailedKBs" -Value ($failedUpdates.KBArticleID -join „, „) |
Beispielskript in PowerShell zur Prüfung des Patch-Status über die Registry:
| Get-ItemProperty -Path ‚HKLM:\SOFTWARE\Org\PatchRetry‘ |
Schritt 4: Wiederholungen mit geplanten Aufgaben oder NinjaOne RMM automatisieren
Planen Sie Skripte endpunktübergreifend ein, um die Compliance regelmäßig zu prüfen und Patches auf nicht konformen Geräten automatisiert erneut zu installieren. Mit NinjaOne können Techniker:innen zusammengesetzte Bedingungen erstellen, damit Patch-Wiederholungen nach einer fehlgeschlagenen Ausführung erneut greifen.
Wiederkehrende geplante Aufgabe mit einem vorhandenen .ps1-Skript über die Eingabeaufforderung erstellen:
schtasks /create /tn „RetryFailedPatches“ /tr "powershell.exe -File C:\Scripts\PatchRetry.ps1" /sc daily /st 02:00 /ru SYSTEM |
💡 Tipp: Speichern Sie das Retry-Skript aus Schritt 2 als .ps1-Datei und verweisen Sie im Befehl auf deren Pfad.
Registry-Werte automatisiert aktualisieren und Erfolg oder Wiederholungslimit per PowerShell-Skript überwachen
$retryCount = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Org\PatchRetry").RetryCountif ($retryCount -gt 3) { # escalate or log for technician } |
Schritt 5: Mit GPO für retry-taugliche Update-Einstellungen sorgen
Automatisierte Patch-Wiederholungen wirken am besten, wenn sich Windows Update vorhersehbar verhält. Techniker:innen können GPOs bereitstellen, um Update-Inhalte vorab herunterzuladen, Installationen zu planen und Neustarts innerhalb von Baseline-Konfigurationen zu verschieben.
⚠️ Warnung: Es empfiehlt sich, GPOs vor dem Rollout lokal zu testen. (Siehe ⚠️ Darauf sollten Sie achten.)
- Öffnen Sie die Gruppenrichtlinienverwaltungskonsole (gpmc.msc) und navigieren Sie zu:
Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Windows Update
- Konfigurieren Sie die folgenden Richtlinien:
| Einstellungen | Empfohlene Konfiguration | Beschreibung |
| Automatische Updates konfigurieren | Aktivieren Sie das Kontrollkästchen neben Autom. Herunterladen und Installation planen. | Lädt Updates automatisiert vorab herunter und installiert sie nach einem festen Zeitplan. |
| Internen Pfad für den Microsoft Updatedienst angeben | Wählen Sie Aktiviert und tragen Sie die HTTP(S)-URL Ihres bevorzugten WSUS-Servers in diese Felder ein:
| Legt den WSUS-Server fest, den die automatischen Updates nach Updates abfragen. |
| Kein automatischer Neustart für geplante Installationen automatischer Updates | Setzen Sie die Richtlinie auf Aktiviert. | Verhindert automatische Neustarts, solange jemand angemeldet ist, und damit Unterbrechungen mitten in der Sitzung. |
| Erneut zum Neustart bei geplanten Installationen auffordern | Setzen Sie die Richtlinie auf Deaktiviert. | Verhindert, dass Benutzer:innen mitten in der Sitzung zum Neustart nach einem geplanten Update aufgefordert werden. |
- Nachdem Sie die GPO mit einer Organisationseinheit (OU) verknüpft haben, führen Sie auf einem Ziel-Endpunkt folgenden PowerShell-Befehl aus: gpupdate /force
⚠️ Darauf sollten Sie achten
| Risiken | Mögliche Folgen | Gegenmaßnahmen |
| Installation des Moduls PSWindowsUpdate übersprungen | Windows Update-Cmdlets ohne das erforderliche PowerShell-Modul zu verwenden, führt zu Fehlern. | Laden Sie das Modul PSWindowsUpdate, indem Sie Import-Module PSWindowsUpdate in einer PowerShell-Eingabe ausführen. |
| Keine Fehlerbehandlung in den Skripten | Ohne saubere Fehlerbehandlung scheitern Skripte stillschweigend und Techniker:innen müssen raten, was schiefgelaufen ist. | Nutzen Sie Fehlerbehandlung in PowerShell in Ihren Skripten, damit Fehler besser dokumentiert werden. |
| Ungetestete GPOs ausrollen | Ungetestete GPOs können Fehlkonfigurationen enthalten, die Endpunkte nach dem Rollout massiv beeinträchtigen. | Testen Sie GPOs lokal in einer kontrollierten Umgebung, bevor Sie sie umgebungsweit ausrollen. |
Das sollten Sie beim automatisierten Patch-Retry beachten
Beim automatisierten Patch-Retry kommt es auf einen reibungslosen Übergang zwischen den Schritten an, denn schon ein Stolperstein kann Fehler auslösen. Die folgenden Überlegungen helfen Skripten, den richtigen nächsten Schritt zu wählen, und erhöhen die Erfolgsquote der Wiederholungen.
Wiederholungslimits durchsetzen
Wiederholungslimits in der Registry verhindern Endlosschleifen und Ticket-Fluten. Erhöhen Sie den Zähler bei jedem Durchlauf, um die Wartezeit nach jedem Fehlversuch zu verlängern. Ist die maximale Anzahl an Versuchen erreicht, stoppen die Limits die Skriptausführung und eskalieren den Fall einmalig.
Den Windows Update-Dienst neu starten
Patch-Fehler treten auch auf, wenn Windows Update (wuauserv) nicht erreichbar ist, und ein kurzer Neustart des Dienstes behebt das häufig. Es empfiehlt sich daher, Windows Update vor dem nächsten Wiederholungsversuch neu zu starten.
- Beispielskript in PowerShell zum Neustart von wuauserv: Restart-Service -Name wuauserv
Lösung für Offline-Geräte
Offline-Geräte verbrauchen Wiederholungslimits schnell, sodass Skripte sie am Ende ganz überspringen. Über RMM-Plattformen wie NinjaOne können Techniker:innen eine Bedingung auf Basis des Skriptergebnisses setzen, die den Versuch oder einen Neustart in Randzeiten auslöst.
Patch-Quellen validieren
Vor einem erneuten Versuch sollten Skripte prüfen, ob die Patch-Quelle erreichbar ist, denn nicht erreichbare Quellen sind eine häufige Fehlerursache. Ist die Quelle nach der Prüfung nicht verfügbar, legen Sie eine kurze Wartezeit ein, werten den Durchlauf aber nicht als fehlgeschlagenen Versuch. Scheitert ein einzelnes KB, stellen Sie dieses zurück, fahren mit den übrigen Patches fort und versuchen es später erneut.
Quick-Start-Guide
NinjaOne bietet mehrere Funktionen, um das Patch-Management zu automatisieren und manuelle Eingriffe zu reduzieren:
1. Patch Intelligence KI
Bewertet Patch-Risiken alle sechs Stunden automatisiert
- Kann Patches auf Basis von Community-Feedback zwischen den Status „genehmigt“, „manuell“ und „abgelehnt“ verschieben
- Verringert Risiken durch potenziell problematische Patches
2. Genehmigungs- und Wiederholungsstrategien
Mehrere Ebenen der Patch-Genehmigung:
- Überschreibungen auf Geräteebene
- Überschreibungen auf Richtlinienebene
- Globale vorab festgelegte Genehmigungen/Ablehnungen
- Kann Patches nach einer festgelegten Anzahl von Tagen automatisiert genehmigen (bis zu 30 Tage für Updates, 365 Tage für Funktionsupdates)
- Ermöglicht die manuelle Genehmigung oder Ablehnung von Patches anhand der KB-Nummer oder Patch-ID
3. Ring Deployment
Gestaffelter Patch-Rollout zur Risikominimierung
- Gerätegruppen für unterschiedliche Deployment-Ringe anlegen
- Patches vor dem breiten Rollout an einer kleinen Geräteauswahl testen
4. Patch-Planung und -Wiederholung
Empfohlen wird, Scan- und Update-Zyklen um mindestens eine Stunde zu trennen
- Scan-Zyklen laufen vor den Anwendungszyklen
- Konfigurierbare Neustartoptionen und Benachrichtigungen
Fehlerbehebung bei der Automatisierung von Patch-Retry-Skripten
Problem 1: Keine Wiederholungsaktivität
Ohne ausreichende Rechte wird die Retry-Logik nicht ausgeführt und es ist keinerlei Aktivität zu sehen. Prüfen Sie deshalb, ob das Skript als SYSTEM oder mit höchsten Rechten läuft. Kontrollieren Sie außerdem die Syntax Ihres Skripts und ob alle referenzierten Pfade existieren.
Problem 2: Update nicht gefunden
Prüfen Sie, ob das fehlende Update über die angegebene Quelle verfügbar ist. Ziehen Sie alternative Quellen wie Windows Update anstelle der Windows Server Update Services (WSUS) in Betracht, damit keine Wiederholungsversuche durch ergebnislose Abfragen verbraucht werden.
Problem 3: Updates schlagen dauerhaft fehl
Kombinieren Sie Ihre Wiederholungsversuche mit den Erkenntnissen aus den Windows Update-Protokollen, um Fehler in fehlgeschlagenen Patches genau einzugrenzen.
- Beispielskript in PowerShell zum Abfragen der Windows Update-Protokolle:
Import-Module PSWindowsUpdate
Get-WindowsUpdateLog
Problem 4: Neustartschleife
Manche Updates verlangen vor der Anwendung einen Geräteneustart, ein Herunterfahren hat dabei nicht denselben Effekt. Wird das übersehen, gerät man leicht in einen Kreislauf, in dem Patches ohne erkennbare Wirkung immer wieder angewendet werden. Prüfen Sie deshalb, ob ein Endpunkt einen Neustart anfordert, bestätigen Sie diesen und starten Sie das Update danach erneut.
NinjaOne-Services, die die Automatisierung von Patch-Wiederholungen vereinfachen
NinjaOne hilft dabei, Patch-Abfragen und Behebung zu automatisieren, um die Compliance sicherzustellen und manuelle Eingriffe zu reduzieren. Diese Funktionen von NinjaOne vereinfachen die Automatisierung von Patch-Wiederholungen im großen Maßstab.
- Geplante Richtlinienaufgabe. Nutzen Sie die geplante Automatisierung von NinjaOne, um Wiederholungen für Gerätegruppen in festgelegten Intervallen zu setzen.
- Patch-Management-Dashboard. Das Dashboard von NinjaOne gruppiert Geräte nach fehlgeschlagenen, erfolgreichen und ausstehenden Patches und schafft so mehr Transparenz. Techniker:innen können darüber außerdem unkompliziert eigene Patch-Berichte erstellen.
- Zusammengesetzte Bedingungen. Erstellen Sie eigene Automatisierungs-Trigger, die auf Basis von Skriptergebnissen Benachrichtigungen erzeugen, Skripte starten oder Fälle eskalieren.
- Remote-Skriptbereitstellung. Führen Sie Skripte remote im großen Maßstab aus und sorgen Sie so umgebungsweit für eine konsistente Wiederholungsautomatisierung bei fehlgeschlagenen Patches.
Automatisieren Sie Ihre Patch-Dokumentation für eine effiziente Fehlerbehandlung.
Patch-Fehler automatisiert beheben und Verfügbarkeit maximieren
Von der Abfrage des Update-Verlaufs bis zur Durchsetzung von Baseline-Richtlinien liefert dieser Leitfaden Techniker:innen ein solides Fundament für die Automatisierung. Übernimmt NinjaOne Überwachung, Skriptbereitstellung und Zeitplanung, lässt sich die Retry-Logik für Patches über eine einheitliche Benutzeroberfläche automatisieren.
Werden Automatisierungsstrategien in einer zentralen Plattform gebündelt, wird das gesamte Automatisierungs-Framework proaktiv und Probleme lassen sich sofort nach ihrer Erkennung beheben. Das reduziert Ausfallzeiten, senkt das Ticketaufkommen und sorgt für durchgängige Patch-Compliance auf allen Endpunkten.
Verwandte Themen:
