So berichten Sie über die Ursachen von Patch-Fehlern ohne dediziertes Analytics-Tool

Patch-Management bringt viele Risiken mit sich. Inkompatible Software und sich widersprechende Updates können dazu führen, dass Bereitstellungen fehlschlagen. Die Folge sind Compliance-Verstöße und ein höheres Risiko für Sicherheitsvorfälle.

Stellen Sie es sich so vor: Patches für Ihre Anwendungen nicht bereitzustellen, ist wie eine unverschlossene Tür in Ihrem Zuhause.

Umso wichtiger ist es, dass Ihr Team dokumentiert, ob ein Patch fehlgeschlagen ist und warum. Für die Visualisierung von Trends gibt es zahlreiche Drittanbieter-Tools, doch diese Anwendungen sind entweder zu teuer oder zu breit angelegt, um konkrete Ursachen zu identifizieren.

Damit keine fehlgeschlagene Bereitstellung unbemerkt bleibt, sollten Sie einen standardisierten Prozess für die Berichterstattung zu Patch-Fehlern aufsetzen, der ohne Dashboards von Drittanbietern auskommt.

In diesem Leitfaden zeigen wir Ihnen, wie Sie Patch-Fehler mit bordeigenen Betriebssystem-Tools diagnostizieren und dokumentieren.

Eine visuelle Aufbereitung des Themas finden Sie hier: So berichten Sie über die Ursachen von Patch-Fehlern ohne dediziertes Analytics-Tool.

Patch-Fehler mit bordeigenen Windows-Tools diagnostizieren und dokumentieren

Es gibt verschiedene Wege, Patch-Fehler mit bordeigenen Windows-Tools zu diagnostizieren und zu dokumentieren. Bevor wir loslegen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

Voraussetzungen:

• Administratorzugriff auf die betroffenen Geräte
• Vertrautheit mit PowerShell, Ereignisanzeige und Registry-Prüfung
• Lokal oder über RMM zugängliche Protokolle
• Kenntnisse zu Microsoft-Update-Fehlercodes und gängigen Update-Installern von Drittanbietern
• Zeitgesteuerte Skriptausführung über die Aufgabenplanung oder eine NinjaOne-Richtlinie (optional)

Empfohlene Bereitstellungsstrategien:

Schritt 1: Gängige Ursachenkategorien festlegen

Anwendungsfall: Einen standardisierten Prozess schaffen, um mögliche Ursachen von Patch-Fehlern über Hunderte von Endpunkten hinweg zu identifizieren.

Ordnen Sie alle gemeldeten Patch-Fehler gängigen Ursachen zu, zum Beispiel:

Solche Kategorien sorgen für konsistente Abläufe bei Behebung und Berichterstattung.

Schritt 2: Methode zum Erkennen, Protokollieren und Melden von Patch-Fehlern wählen

Als Nächstes wählen Sie eine Methode, um Patch-Fehler zu erkennen, zu protokollieren und zu melden. Sie können eine der unten aufgeführten Methoden nutzen oder sie beliebig kombinieren, je nach Ihren Anforderungen und Zielen.

Methode 1: Fehlerprotokolle mit PowerShell und Ereignisprotokoll-Abfragen sammeln

Anwendungsfall: Patch-Fehler auf einzelnen Rechnern beheben, indem Sie relevante Protokolle und System-Flags mit PowerShell auslesen.

1. Fehlgeschlagene Updates abfragen (Windows-Ereignis-ID 20)

Get-WinEvent -FilterHashtable @{LogName='System'; ID=20} |Where-Object { $_.Message -like "*failed*" } |Select TimeCreated, Message | Export-Csv "C:\Logs\FailedPatches.csv" -NoTypeInformation

Wichtig: Der Pfad muss existieren, damit diese Methode funktioniert. Andernfalls wird eine Fehlermeldung ausgegeben.

2. Prüfen, ob ein Neustart erforderlich ist

$rebootRequired = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

Extend the script to display a message when a reboot is required

$rebootRequired = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

if ($rebootRequired) {

Write-Host "System reboot is required."

} else {

Write-Host "No reboot required."

}

3. Die letzten 5 fehlgeschlagenen Sicherheitsupdates abrufen

Get-HotFix | Where-Object {$_.Description -eq "Security Update"} |Sort-Object InstalledOn | Select-Object -Last 5

4. Die letzten 5 fehlgeschlagenen kritischen Updates und Hotfixes auflisten

Get-WmiObject -Namespace "root\cimv2" -Class "Win32_ReliabilityRecords" |Where-Object {$_.SourceName -eq "Microsoft-Windows-WindowsUpdateClient" -and $_.Message -like "*failed*" -and ($_.ProductName -like "*Security*" -or $_.ProductName -like "*Critical*" -or $_.ProductName -like "*Hotfix*")} |Select-Object TimeGenerated, Message, ProductName |Sort-Object TimeGenerated -Descending |Select-Object -First 5

Methode 2: Update-Protokolle und Fehler über die Eingabeaufforderung auslesen

Anwendungsfall: Schnelle Diagnosen auf mehreren Endpunkten durchführen, indem Sie die Windows-Update-Protokolle prüfen.

1. Windows-Update-Protokolle prüfen (Windows 10+)

Get-WindowsUpdateLog

Die Ausgabe dieses Befehls finden Sie unter: C:\Users\<YourUsername>\Desktop\WindowsUpdate.log

2. Nach Update-Fehlern suchen

findstr /C:"error"

C:\Users\<YourUsername>\Desktop\WindowsUpdate.log

3. Prüfen, ob die erforderlichen Dienste laufen

sc query wuauserv

sc query bits

Hinweis: Der Dienstname wuauserv steht für Windows Update, während bits den Background Intelligent Transfer Service bezeichnet. Dieser überträgt Dateien mit ungenutzter Netzwerkbandbreite und ermöglicht es Windows Update, Updates effizient herunterzuladen.

4. Ausstehende Dateiumbenennungen auflisten (häufige Ursache für Neustartbedarf)

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations

Existiert der Wert PendingFileRenameOperations oder enthält er Daten, bedeutet das: Eine oder mehrere Dateien stehen noch aus und ein Neustart ist erforderlich, um die Vorgänge abzuschließen.

Methode 3: Metadaten zur Fehlerursache für die Berichterstattung in der Registry ablegen

Anwendungsfall: Die Berichterstattung zu Patch-Fehlern automatisieren, indem kategorisierte Metadaten in die Windows-Registry geschrieben werden, wo Ihr RMM-Tool sie abholt.

1. Bei einem Fehler kategorisierte Ursachenwerte für das RMM-Polling in die Registry schreiben

New-Item -Path "HKLM:\SOFTWARE\Org\PatchAudit" -Force

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\PatchAudit" -Name "LastPatchError" -Value "DiskFull"

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\PatchAudit" -Name "AuditDate" -Value (Get-Date).ToString("u")

Protokollieren oder exportieren Sie die Audit-Daten anschließend für die Berichterstattung in eine Datei:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Org\PatchAudit" | Out-File "C:\Logs\PatchAudit.txt"

Hinweis: „DiskFull“ ist nur ein Beispielwert. Ersetzen Sie ihn durch die tatsächlich ermittelte Ursache (z. B. „NetworkTimeout“, „PermissionDenied“ usw.)

2. Prüfung über die Eingabeaufforderung

reg query HKLM\SOFTWARE\Org\PatchAudit

Wichtig: Der Befehl reg query HKLM\SOFTWARE\Org\PatchAudit funktioniert nur, wenn die oben genannten Schritte erfolgreich waren.

Methode 4: Fehlerberichte mit geplanten Aufgaben oder RMM-Tools automatisieren

Anwendungsfall: Eine geplante Aufgabe anlegen, die Patch-Fehler scannt, Ursachen kennzeichnet und bei wiederkehrenden Fehlern Alarmierungen auslöst.

1. Geplante Aufgabe zum Scannen und Kennzeichnen anlegen

schtasks /create /tn "PatchFailureScan" /tr "powershell.exe -File C:\Scripts\AuditPatchFailures.ps1" /sc weekly /ru SYSTEM

AuditPatchFailure.s1 ist ein PowerShell-Skript, das alle Ereignisse fehlgeschlagener Patches erfasst, deren Ursachen analysiert und kategorisierte Metadaten in der Windows-Registry unter HKLM:\SOFTWARE\Org\PatchAudit ablegt.

Alternativ können Sie NinjaOne nutzen, um:

• • die Ausgabe automatisiert in einem benutzerdefinierten Feld zu erfassen.
  • Alarmierungen für fehlgeschlagene Patches, ausstehende Neustarts und erkannte spezifische Ursachen einzurichten.
  • bei wiederkehrenden Fehlern automatisiert Tickets zu eröffnen.

NinjaOne vereinfacht das Patching, indem alle installierten, fehlenden, ausstehenden oder fehlgeschlagenen Patches angezeigt werden, ganz ohne manuelles Skripting oder geplante Aufgaben. Das Patch-Management läuft zentral über eine Plattform, was die Überwachung und Fehlerbehebung bei Patch-Fehlern erleichtert.

Weitere Details lesen Sie weiter unten im Abschnitt dazu, wie NinjaOne die Berichterstattung und Analyse von Patch-Fehlern verbessert.

Wichtig: Sie müssen das Skript AuditPatchFailure.s1 erstellen, bevor Sie mit dieser Methode fortfahren.

Methode 5: Häufigen Fehlerszenarien per Gruppenrichtlinie vorbeugen

Anwendungsfall: Häufige Patch-Fehler verhindern, indem Sie Konfigurationen auf Systemebene per Gruppenrichtlinie über mehrere Endpunkte hinweg erzwingen.

1. WUA- und MSI-Protokollierung erzwingen

# Enable WUA Logging

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace" -Name "LogLevel" -Value 5 -Type DWord

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace" -Name "LogFile" -Value "%windir%\WindowsUpdate.log" -Type String

# Enable MSI Logging

Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\Installer" -Name "Logging" -Value "voicewarmup" -Type String

Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\Installer" -Name "Debug" -Value 7 -Type DWord

Write-Output "WUA and MSI logging have been enabled."

2. Aufschieben von Neustarts per GPO unterbinden

Computerkonfiguration > Windows Update > Kein automatischer Neustart mit angemeldeten Benutzern bei geplanten Installationen automatischer Updates.

Damit die Aufgabe auch dann läuft, wenn sich das System während der geplanten Installation im Energiesparmodus befindet, müssen Sie Folgendes tun:

• • Reaktivierungsoption aktivieren

1. 1. 1. Öffnen Sie in der Aufgabenplanung die Eigenschaften der Aufgabe → Registerkarte „Bedingungen“
      2. Aktivieren Sie „Computer zum Ausführen dieser Aufgabe reaktivieren“

• • Reaktivierungstimer aktivieren

1. 1. 1. Gehen Sie zu Systemsteuerung → Energieoptionen → Energiesparplaneinstellungen ändern → Erweiterte Energieeinstellungen ändern
      2. Wechseln Sie unter „Energie sparen“ zu „Reaktivierungstimer zulassen“ und setzen Sie die Einstellung auf „Aktivieren“

• • Einstellungen der Aufgabenplanung konfigurieren

1. 1. 1. Öffnen Sie die Aufgabenplanung und rufen Sie die Eigenschaften der Aufgabe auf
      2. Aktivieren Sie auf der Registerkarte „Einstellungen“ die Option „Aufgabe so schnell wie möglich nach einem verpassten Start ausführen“. So läuft die Aufgabe auch dann, wenn sich das System zur geplanten Zeit im Energiesparmodus befand oder ausgeschaltet war.

Worauf Sie achten sollten

Behalten Sie diese Stolperfallen im Blick, wenn Sie unserem Leitfaden folgen:

Mehr Werkzeuge im Gepäck: Zusätzliche Tipps zum Nachverfolgen und Melden von Patch-Fehlern

Mit diesen weiteren Schritten optimieren Sie Ihren Prozess für die Berichterstattung zu Patch-Fehlern:

Denken Sie auch an Patch-Protokolle von Drittanbietern

Beschränken Sie Ihre Berichterstattung nicht auf Windows-Protokolle, sondern prüfen Sie auch C:\ProgramData\Package Cache\ oder %ProgramFiles% auf Protokolle von Drittanbietern.

Windows-Update-Protokolle sagen Ihnen nur, dass ein Patch-Update fehlgeschlagen ist. Anbieter-Protokolle zeigen dagegen, warum es fehlgeschlagen ist. Ein Blick in diese Protokolle hilft Ihnen, Fehler schneller zu beheben.

Erstellen Sie ein Runbook für Ihr Team

Ein Runbook ist ein lebendes Dokument, das häufige Fehlertypen beschreibt, erklärt, wie man sie erkennt, und die nächsten Schritte festhält. Es ist ein nützliches Hilfsmittel, um die Fehlerbehebung bei fehlgeschlagenen Patches zu vereinfachen.

Trends mit schwellenwertbasierter Berichterstattung überwachen

Ein einzelner fehlgeschlagener Patch kann ein Ausrutscher sein, doch ein Fehler auf drei oder mehr Geräten ist ein Warnsignal. Solche fehlgeschlagenen Bereitstellungen deuten auf ein größeres Problem hin, das mehrere Standorte betreffen könnte.

Um solche Muster im Blick zu behalten, richten Sie Alarmierungen für den Fall ein, dass drei oder mehr Rechner dieselbe Ursache melden. So können Sie das Problem schnell eskalieren und künftige Fehler verhindern.

Ursachencodes in verständliche Zusammenfassungen übersetzen

Nicht alle Stakeholder sind IT-Expert:innen, die wissen, was „RebootRequired“ oder „Ereignis-ID 20“ bedeutet. Übersetzen Sie diese Fehler am besten in klare, gut lesbare Zusammenfassungen, die Sie in Ihre Quarterly Business Reviews (QBRs) aufnehmen können.

Darum ist die Berichterstattung zu den Ursachen von Patch-Fehlern so wichtig

Sie beschleunigt die Fehlerbehebung

Die Berichterstattung zu Patch-Fehlern nimmt das Rätselraten aus der Fehlerbehebung bei fehlgeschlagenen Patches und ermöglicht es Ihnen, die Behebung zu automatisieren. Ihre Techniker:innen müssen nicht länger bei jedem fehlgeschlagenen Patch Detektiv spielen.

Sie hilft, dieselben Fehler zu vermeiden

Wenn Sie verstehen, warum ein Patch zuvor fehlgeschlagen ist, können Sie eine Wiederholung verhindern. Noch wichtiger: Sie erkennen veraltete Software oder problematische Konfigurationen, die das Scheitern der Patches verursachen.

Sie erleichtert die Berichte für QBRs und Audits

Klare Berichte zu Patch-Fehlern helfen Ihnen, bei QBRs und Audits Vertrauen bei Ihren Kund:innen aufzubauen. Sie zeigen, wie konsequent Sie eine sichere IT-Umgebung aufbauen und pflegen.

Sie hält das Patching im Zeitplan

Unentdeckte Fehler können Patching-Fenster in die Länge ziehen oder zu Verstößen gegen Service Level Agreements (SLA) führen. Eine Datenbank mit Patching-Fehlern hilft Ihnen, Probleme früh zu erkennen und Ihren Rollout entsprechend anzupassen.

So verbessert NinjaOne die Berichterstattung und Analyse von Patch-Fehlern

NinjaOne verbessert Ihre Berichterstattung zu Patch-Fehlern und deren Analyse, indem es:

• standardisierte Audit-Skripte über mehrere Umgebungen hinweg bereitstellt
• Geräte über benutzerdefinierte Felder statt über die Windows-Registry mit Fehlerursache und Zeitstempel kennzeichnet
• Alarmierungen für wiederkehrende Ursachen fehlgeschlagener Patches einrichtet, etwa Speicherplatzprobleme, blockierte Neustarts oder MSI-Konflikte
• Berichte zur Patch-Zuverlässigkeit je Kund:in für die interne Prüfung und QBRs erzeugt
• Workflows zur Behebung auslöst, zum Beispiel erzwungener Neustart oder Cache leeren, abhängig vom erkannten Fehlertyp

Mit NinjaOne schließen MSPs den Kreis zwischen Erkennung, Klassifizierung, Behebung und Berichterstattung, ganz ohne Drittanbieter-Tool.

Berichterstattung zu Patch-Fehlern mit bordeigenen Windows-Tools vereinfachen

Sie brauchen keine komplexen oder teuren Tools, um zu verstehen, wie und warum Patch-Fehler entstehen. Drittanbieter-Tools können hilfreich sein, doch schon bordeigene Windows-Werkzeuge wie PowerShell und die Registry-Protokollierung reichen aus, um Ursachen zu kennzeichnen und zu kategorisieren.

Noch wichtiger: Sie können damit häufige Blockaden per GPO lösen und all Ihren Kund:innen proaktive Behebungsservices bieten.

Verwandte Themen:

• Fehler im Patch-Management und wie Sie sie vermeiden
• Patch-Management-Prozess: Best Practices
• So automatisieren Sie das Patch-Management
• So deinstallieren Sie einen problematischen Patch: eine Schritt-für-Schritt-Anleitung