Zo rapporteert u over de oorzaken van mislukte patches zonder speciale analytics-tool

Patchbeheer brengt veel risico’s met zich mee. Incompatibele software en conflicterende updates kunnen leiden tot mislukte implementaties, wat weer compliance-overtredingen en een groter risico op beveiligingsinbreuken tot gevolg heeft.

Zie het zo: patches niet uitrollen op uw applicaties is als de deur van uw huis niet op slot doen.

Uw team zou daarom moeten rapporteren of een patch is mislukt en waarom. U kunt allerlei tools van derden gebruiken om trends te visualiseren, maar die applicaties zijn vaak te duur of hebben een te brede scope om specifieke onderliggende oorzaken te achterhalen.

Om te zorgen dat geen enkele mislukte implementatie onopgemerkt blijft, is het belangrijk dat u een gestandaardiseerd proces opzet voor het rapporteren van patchfouten dat niet afhankelijk is van dashboards van derden.

In deze gids laten we u zien hoe u patchfouten diagnosticeert en rapporteert met de tools van het OS zelf.

Wilt u dit onderwerp liever visueel uitgelegd krijgen? Bekijk dan Hoe u rapporteert over de oorzaken van mislukte patches zonder speciale analytics-tool.

Patchfouten diagnosticeren en rapporteren met de eigen tools van Windows

Er zijn verschillende manieren om patchfouten te diagnosticeren en te rapporteren met de eigen tools van Windows. Zorg eerst dat aan de volgende voorwaarden is voldaan:

Vereisten:

• Beheerderstoegang tot de betrokken devices
• Kennis van PowerShell, Logboeken (Event Viewer) en het inspecteren van het register
• Lokale of via RMM toegankelijke logboeken
• Kennis van de foutcodes van Microsoft Update en van gangbare update-installateurs van derden
• Scriptuitvoering plannen via Taakplanner of een NinjaOne-beleid (optioneel)

Aanbevolen implementatiestrategieën:

Stap 1: bepaal de categorieën van veelvoorkomende oorzaken

Use case: een gestandaardiseerd proces opzetten om de mogelijke oorzaken van mislukte patches op honderden endpoints te achterhalen.

Deel alle gemelde patchfouten in naar veelvoorkomende oorzaken, bijvoorbeeld:

Met deze categorieën zorgt u voor consistente herstel- en rapportageprocedures.

Stap 2: kies een methode om patchfouten te signaleren, te loggen en te rapporteren

Vervolgens kiest u een methode om patchfouten te signaleren, te loggen en te rapporteren. U kunt één van de onderstaande methoden kiezen of een combinatie ervan, afhankelijk van uw specifieke behoeften en doelen.

Methode 1: foutlogboeken verzamelen met PowerShell en query’s op gebeurtenissenlogboeken

Use case: patchfouten op afzonderlijke computers oplossen door relevante logboeken en systeemvlaggen op te halen met PowerShell.

1. Mislukte updates opvragen (Windows Event ID 20)

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

Belangrijk: het pad moet bestaan, anders werkt deze methode niet en krijgt u een foutmelding.

2. Controleren of een reboot nodig is

$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. De laatste 5 mislukte beveiligingsupdates ophalen

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

4. De laatste 5 mislukte kritieke updates en hotfixes weergeven

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: updatelogboeken en fouten ophalen met CMD

Use case: snelle diagnostiek uitvoeren op meerdere endpoints door de logboeken van Windows Update te controleren.

1. Logboeken van Windows Update controleren (Windows 10+)

Get-WindowsUpdateLog

U kunt de uitvoer van deze opdracht bekijken op: C:\Users\<YourUsername>\Desktop\WindowsUpdate.log

2. Scannen op updatefouten

findstr /C:"error"

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

3. Controleren of de vereiste services draaien

sc query wuauserv

sc query bits

Let op: de servicenaam wuauserv verwijst naar Windows Update, terwijl bits staat voor de Background Intelligence Transfer Service. Die verplaatst bestanden met ongebruikte netwerkbandbreedte en zorgt dat Windows Update updates efficiënt kan downloaden.

4. Hernoemingen van bestanden in behandeling weergeven (veelvoorkomende reden voor een vereiste reboot)

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

Als de waarde PendingFileRenameOperations bestaat of gegevens bevat, betekent dit dat er een of meer bestanden in behandeling zijn en dat er een reboot nodig is om die af te ronden.

Methode 3: metadata over de oorzaak opslaan in het register voor rapportage

Use case: de rapportage van patchfouten automatiseren door gecategoriseerde metadata naar het Windows-register te schrijven, zodat uw RMM-tool die kan verzamelen.

1. Bij een fout gecategoriseerde oorzaakwaarden naar het register schrijven voor uitlezing door de RMM

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")

Log of exporteer de auditgegevens vervolgens naar een bestand voor rapportage:

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

Let op: “DiskFull” is slechts een voorbeeldwaarde. U moet die vervangen door de werkelijk gevonden oorzaak (bijvoorbeeld “NetworkTimeout”, “PermissionDenied” enzovoort).

2. Controle via CMD

reg query HKLM\SOFTWARE\Org\PatchAudit

Belangrijk: de opdracht reg query HKLM\SOFTWARE\Org\PatchAudit werkt alleen als de hierboven genoemde stappen zijn gelukt.

Methode 4: foutrapportage automatiseren met geplande taken of RMM-tools

Use case: een geplande taak maken die patchfouten scant, oorzaken labelt en notificaties activeert bij terugkerende fouten.

1. Een geplande taak maken om te scannen en te labelen

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

AuditPatchFailure.s1 is een PowerShell-script dat alle gebeurtenissen van mislukte patches verzamelt, de oorzaken analyseert en gecategoriseerde metadata opslaat in het Windows-register onder HKLM:\SOFTWARE\Org\PatchAudit.

U kunt ook NinjaOne gebruiken om:

• • De uitvoer automatisch in een aangepast veld te verzamelen.
  • Notificaties aan te maken voor mislukte patches, reboots in behandeling en gedetecteerde specifieke oorzaken.
  • Automatisch tickets te openen voor terugkerende fouten.

NinjaOne vereenvoudigt het patchproces door alle geïnstalleerde, ontbrekende, in behandeling zijnde of mislukte patches te tonen zonder handmatige scripts of geplande taken. Het brengt patchbeheer samen in één platform, waardoor het eenvoudiger wordt om patchfouten te volgen en op te lossen.

Lees hieronder hoe NinjaOne de rapportage en analyse van patchfouten kan verbeteren.

Belangrijk: u moet eerst het script AuditPatchFailure.s1 maken voordat u met deze methode verdergaat.

Methode 5: veelvoorkomende foutscenario’s voorkomen met Groepsbeleid

Use case: veelvoorkomende patchfouten voorkomen door via Groepsbeleid configuraties op systeemniveau af te dwingen op meerdere endpoints.

1. WUA- en MSI-logboekregistratie afdwingen

# 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. Uitstel van de reboot voorkomen met een GPO

Computerconfiguratie > Windows Update > Geen automatische herstart met aangemelde gebruikers voor geplande installaties van automatische updates.

Om te zorgen dat de taak ook wordt uitgevoerd als het systeem tijdens de geplande installatie in de slaapstand staat, moet u:

• • De wekoptie inschakelen

1. 1. 1. Ga in Taakplanner naar Eigenschappen van de taak → tabblad Voorwaarden
      2. Zet “De computer uit de slaapstand halen om deze taak uit te voeren” aan

• • Wektimers inschakelen

1. 1. 1. Ga naar Configuratiescherm → Energiebeheer → De instellingen voor het schema wijzigen → Geavanceerde energie-instellingen wijzigen
      2. Ga onder Slaapstand naar Wektimers en zet die op Inschakelen

• • De instellingen van Taakplanner configureren

1. 1. 1. Open Taakplanner en ga naar Eigenschappen van de taak
      2. Zet op het tabblad Instellingen de optie “Taak zo snel mogelijk uitvoeren nadat een geplande start is gemist” aan, zodat de taak ook wordt uitgevoerd als het systeem tijdens de geplande wektijd in de slaapstand stond of uit was.

Waar u op moet letten

Houd rekening met deze valkuilen als u onze gids volgt:

Uw gereedschapskist uitbreiden: extra tips voor het volgen en rapporteren van patchfouten

Met deze extra stappen stroomlijnt u uw proces voor het rapporteren van patchfouten:

Vergeet de patchlogboeken van derden niet

Richt uw rapportage niet alleen op Windows-logboeken, maar controleer ook C:\ProgramData\Package Cache\ of %ProgramFiles% voor logboeken van derden.

De logboeken van Windows Update vertellen u alleen dát een patch-update is mislukt, maar de logboeken van de leverancier helpen u begrijpen waarom die is mislukt. Door die logboeken te bekijken, lost u fouten sneller op.

Maak een runbook voor uw team

Een runbook is een document dat meegroeit en waarin staat welke fouttypen veel voorkomen, hoe u ze herkent en welke stappen u daarna zet. Het is een handig hulpmiddel om het oplossen van mislukte patches eenvoudig te maken.

Volg trends met rapportage op basis van drempelwaarden

Eén mislukte patch kan een storing zijn, maar een fout die op drie of meer devices optreedt is een alarmsignaal. Zulke mislukte implementaties wijzen op een groot probleem dat meerdere locaties kan treffen.

Maak notificaties aan voor situaties waarin drie of meer machines dezelfde oorzaak melden om deze patronen bij te houden. Zo schaalt u het probleem snel op en voorkomt u toekomstige fouten.

Zet oorzaakcodes om in begrijpelijke samenvattingen

Niet alle belanghebbenden zijn IT-experts die weten wat “RebootRequired” of “Event ID 20” betekent. Zet die fouten daarom om in heldere, leesbare samenvattingen die u kunt opnemen in uw Quarterly Business Reviews (QBR’s).

Waarom het rapporteren van de oorzaken van patchfouten belangrijk is

Het versnelt het oplossen van problemen

Rapportage over patchfouten haalt het giswerk uit het oplossen van mislukte patches en stelt u in staat het herstelproces te automatiseren. Uw technici hoeven niet langer detective te spelen bij elke mislukte patch.

Het voorkomt dat u dezelfde fouten herhaalt

Als u begrijpt waarom een patch eerder is mislukt, voorkomt u dat het opnieuw gebeurt. Nog belangrijker: u ontdekt zo welke verouderde software of problematische configuraties ervoor zorgen dat patches mislukken.

Het maakt rapportages voor QBR’s en audits eenvoudiger

Heldere rapportages over patchfouten helpen u vertrouwen op te bouwen bij uw klanten tijdens QBR’s en audits. Ze laten zien dat u zich inzet voor het opbouwen en onderhouden van een veilige IT-omgeving.

Het houdt het Patching op schema

Onopgemerkte fouten kunnen patchvensters verlengen of leiden tot overtredingen van Service Level Agreements (SLA’s). Met een database van patchfouten signaleert u problemen vroegtijdig en past u uw uitrol tijdig aan.

Hoe NinjaOne de rapportage en analyse van patchfouten verbetert

NinjaOne verbetert uw rapportage over patchfouten en de analyse ervan door:

• Gestandaardiseerde auditscripts uit te rollen in meerdere omgevingen
• Devices te labelen met de oorzaak van de fout en een tijdstempel via aangepaste velden in plaats van via het Windows-register
• Notificaties in te stellen voor terugkerende oorzaken van mislukte patches, zoals schijfproblemen, blokkades door een vereiste reboot of MSI-conflicten
• Rapportages over patchbetrouwbaarheid per klant te genereren voor interne beoordelingen en QBR’s
• Herstel-workflows te activeren, zoals een geforceerde reboot en het legen van de cache, op basis van het gedetecteerde fouttype

Met behulp van NinjaOne kunnen MSP’s de cirkel sluiten tussen detectie, classificatie, herstel en rapportage zonder afhankelijk te zijn van een tool van derden.

Maak het rapporteren van patchfouten eenvoudiger met de eigen tools van Windows

U hebt geen complexe of dure tools nodig om te begrijpen hoe en waarom patches mislukken. Tools van derden kunnen nuttig zijn, maar met de eigen Windows-tools zoals PowerShell en logboekregistratie in het register labelt en categoriseert u de oorzaken net zo goed.

Nog belangrijker: zo lost u veelvoorkomende blokkades op met een GPO en levert u proactieve herstelservices aan al uw klanten.

Gerelateerde onderwerpen:

• Fouten in patchbeheer en hoe u ze voorkomt
• Het proces van patchbeheer: beste praktijken
• Zo automatiseert u patchbeheer
• Een problematische patch verwijderen: een stapsgewijze gids