Comment établir un rapport sur les causes racines des échecs de correctifs sans outil d’analyse dédié

La gestion des correctifs comporte de nombreux risques. Des logiciels incompatibles et des mises à jour conflictuelles peuvent entraîner l’échec des déploiements, ce qui provoque des manquements à la conformité et augmente le risque de failles de sécurité.

Voyez les choses ainsi : ne pas déployer les correctifs de vos applications revient à laisser une porte de votre maison déverrouillée.

Votre équipe doit donc signaler l’échec d’un correctif et en expliquer la raison. Il existe divers outils tiers pour visualiser les tendances, mais ces applications sont souvent trop coûteuses ou d’une portée trop large pour identifier des causes racines précises.

Pour qu’aucun échec de déploiement ne passe entre les mailles du filet, il est important de mettre en place un processus normalisé de reporting des erreurs de correctifs qui ne dépende pas de tableaux de bord tiers.

Dans ce guide, nous vous montrons comment diagnostiquer et signaler les erreurs de correctifs à l’aide des outils natifs du système d’exploitation.

Pour une présentation visuelle du sujet, regardez Comment établir un rapport sur les causes racines des échecs de correctifs sans outil d’analyse dédié.

Diagnostiquer et signaler les erreurs de correctifs avec les outils natifs de Windows

Il existe plusieurs façons de diagnostiquer et de signaler les erreurs de correctifs avec les outils natifs de Windows. Avant de commencer, assurez-vous de remplir les conditions suivantes :

📌 Prérequis :

• Accès administrateur aux appareils concernés
• Bonne connaissance de PowerShell, de l’observateur d’événements et de l’inspection du registre
• Journaux accessibles en local ou via un RMM
• Connaissance des codes d’erreur de Microsoft Update et des installateurs de mises à jour tierces les plus courants
• Planification de l’exécution des scripts via le Planificateur de tâches ou une politique NinjaOne (facultatif)

📌 Stratégies de déploiement recommandées :

Étape 1 : définir les catégories de causes racines courantes

📌 Cas d’utilisation : créer un processus normalisé pour identifier les causes possibles des échecs de correctifs sur des centaines de terminaux.

Regroupez tous les échecs de correctifs signalés par cause racine commune, par exemple :

La création de ces catégories favorise des procédures de remédiation et de reporting cohérentes.

Étape 2 : choisir une méthode pour identifier, journaliser et signaler les échecs de correctifs

Vous devez ensuite choisir une méthode pour identifier, journaliser et signaler les échecs de correctifs. Optez pour l’une des méthodes ci-dessous ou pour une combinaison de plusieurs d’entre elles, selon vos besoins et vos objectifs.

Méthode 1 : collecter les journaux d’échec avec PowerShell et des requêtes sur le journal d’événements

📌 Cas d’utilisation : dépanner les échecs de correctifs sur des postes individuels en extrayant les journaux et les indicateurs système pertinents avec PowerShell.

1. Interroger les mises à jour en échec (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

⚠️Important : le chemin doit exister pour que cette méthode fonctionne. Sinon, un message d’erreur s’affichera.

2. Vérifier les besoins de redémarrage

$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. Récupérer les 5 dernières mises à jour de sécurité en échec

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

4. Lister les 5 dernières mises à jour critiques et correctifs cumulatifs en échec

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

Méthode 2 : utiliser CMD (invite de commande) pour extraire les journaux et les erreurs de mise à jour

📌 Cas d’utilisation : réaliser des diagnostics rapides sur plusieurs terminaux en consultant les journaux de Windows Update.

1. Vérifier les journaux de Windows Update (Windows 10 et versions ultérieures)

Get-WindowsUpdateLog

Vous pouvez consulter le résultat de cette commande ici : C:\Users\<YourUsername>\Desktop\WindowsUpdate.log

2. Rechercher les erreurs de mise à jour

findstr /C:"error"

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

3. Confirmer que les services requis sont en cours d’exécution

sc query wuauserv

sc query bits

💡Remarque : le nom de service wuauserv correspond à Windows Update, tandis que bits désigne le Background Intelligence Transfer Service. Ce dernier transfère les fichiers en utilisant la bande passante réseau inactive et permet à Windows Update de télécharger les mises à jour efficacement.

4. Lister les renommages de fichiers en attente (cause fréquente d’un redémarrage requis)

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

Si la valeur PendingFileRenameOperations existe ou contient des données, cela signifie qu’un ou plusieurs fichiers sont en attente et qu’un redémarrage est nécessaire pour terminer l’opération.

Méthode 3 : stocker les métadonnées de cause racine dans le registre pour le reporting

📌 Cas d’utilisation : automatiser le reporting des erreurs de correctifs en écrivant des métadonnées catégorisées dans le registre Windows afin que votre outil RMM les collecte.

1. En cas d’échec, écrire des valeurs de cause racine catégorisées dans le registre pour interrogation par le 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")

Journalisez ensuite les données d’audit ou exportez-les vers un fichier pour le reporting :

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

💡Remarque : « DiskFull » n’est qu’une valeur d’exemple. Vous devez la remplacer par la cause racine réellement identifiée (par exemple « NetworkTimeout », « PermissionDenied », etc.)

2. Vérification dans CMD (invite de commande)

reg query HKLM\SOFTWARE\Org\PatchAudit

⚠️Important : la commande reg query HKLM\SOFTWARE\Org\PatchAudit ne fonctionne que si les étapes ci-dessus ont réussi.

Méthode 4 : automatiser le reporting des échecs avec des tâches planifiées ou des outils RMM

📌 Cas d’utilisation : créer une tâche planifiée pour analyser les échecs de correctifs, étiqueter les causes racines et déclencher des alertes en cas d’erreurs récurrentes.

1. Créer une tâche planifiée d’analyse et d’étiquetage

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

AuditPatchFailure.s1 est un script PowerShell qui collecte tous les événements liés aux correctifs en échec, analyse leurs causes racines et stocke des métadonnées catégorisées dans le registre Windows sous HKLM:\SOFTWARE\Org\PatchAudit.

Vous pouvez également utiliser NinjaOne pour :

• • collecter automatiquement les résultats dans un champ personnalisé ;
  • créer des alertes pour les correctifs en échec, les redémarrages en attente et la détection d’une cause racine spécifique ;
  • ouvrir automatiquement des tickets pour les erreurs récurrentes.

NinjaOne simplifie le processus de mise à jour en affichant tous les correctifs installés, manquants, en attente ou en échec, sans script manuel ni tâche planifiée. La gestion des correctifs est centralisée sur une seule plateforme, ce qui facilite la surveillance et le dépannage des échecs de correctifs.

Pour en savoir plus, découvrez ci-dessous comment NinjaOne peut améliorer le reporting et l’analyse des erreurs de correctifs.

⚠️ Important : vous devez d’abord créer le script AuditPatchFailure.s1 avant de poursuivre avec cette méthode.

Méthode 5 : utiliser la stratégie de groupe pour anticiper les scénarios d’échec courants

📌 Cas d’utilisation : éviter les erreurs de correctifs les plus courantes en imposant des configurations au niveau du système sur plusieurs terminaux via la stratégie de groupe.

1. Forcer la journalisation WUA et MSI

# 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. Utiliser un GPO pour empêcher le report du redémarrage

Configuration ordinateur > Windows Update > Pas de redémarrage automatique avec des utilisateurs connectés pour les installations planifiées de mises à jour automatiques.

Pour que la tâche s’exécute même si le système est en veille au moment de l’installation planifiée, vous devez :

• • activer l’option de sortie de veille

1. 1. 1. Dans le Planificateur de tâches, ouvrez les Propriétés de la tâche → onglet Conditions
      2. Cochez « Réveiller l’ordinateur pour exécuter cette tâche »

• • activer les minuteurs de réveil

1. 1. 1. Allez dans Panneau de configuration → Options d’alimentation → Modifier les paramètres du mode → Paramètres d’alimentation avancés
      2. Sous Veille, ouvrez Minuteurs de réveil et réglez le paramètre sur Activer

• • configurer les paramètres du Planificateur de tâches

1. 1. 1. Ouvrez le Planificateur de tâches et accédez aux Propriétés de la tâche
      2. Dans l’onglet Paramètres, cochez « Exécuter la tâche dès que possible si un démarrage planifié est manqué » pour garantir l’exécution de la tâche même si le système était en veille ou éteint à l’heure de réveil planifiée.

⚠️ Points de vigilance

Gardez ces écueils en tête lorsque vous suivez notre guide :

Enrichir votre boîte à outils : conseils supplémentaires pour suivre et signaler les erreurs de correctifs

Voici quelques mesures complémentaires pour fluidifier votre processus de reporting des erreurs de correctifs :

N’oubliez pas les journaux des correctifs tiers

Ne limitez pas votre reporting aux journaux Windows : pensez à consulter C:\ProgramData\Package Cache\ ou %ProgramFiles% pour les journaux tiers.

Les journaux de Windows Update vous indiquent seulement qu’une mise à jour de correctif a échoué, alors que les journaux du fournisseur vous aident à comprendre pourquoi elle a échoué. Les consulter vous permettra de corriger les erreurs plus rapidement.

Créez un runbook à l’usage de votre équipe

Un runbook est un document évolutif qui recense les types d’échecs courants, la manière de les identifier et les étapes suivantes à entreprendre. C’est un outil précieux pour simplifier le dépannage des correctifs en échec.

Surveillez les tendances avec un reporting par seuils

Un correctif en échec peut n’être qu’un incident isolé, mais une erreur qui se produit sur trois appareils ou plus est un signal d’alarme. Ces échecs de déploiement révèlent un problème majeur susceptible de toucher plusieurs sites.

Pour suivre ces schémas, créez des alertes lorsque trois machines ou plus signalent la même cause. Vous pourrez ainsi escalader le problème rapidement et éviter de futurs échecs.

Traduisez les codes de cause racine en résumés compréhensibles

Toutes les parties prenantes ne sont pas des experts informatiques capables de comprendre ce que signifient « RebootRequired » ou « Event ID 20 ». L’idéal est de traduire ces erreurs en résumés clairs et lisibles, que vous pourrez intégrer à vos revues d’activité trimestrielles (QBR).

L’importance du reporting des causes d’erreurs de correctifs

Il accélère le dépannage

Le reporting des erreurs de mise à jour élimine les approximations dans le dépannage des correctifs en échec et vous permet d’automatiser la remédiation. Vos techniciens n’ont plus besoin de jouer les détectives à chaque échec de correctif.

Il évite de répéter les mêmes erreurs

Comprendre pourquoi un correctif a échoué par le passé vous aidera à éviter que cela ne se reproduise. Plus important encore, cela vous permettra d’identifier les logiciels obsolètes ou les configurations problématiques à l’origine des échecs.

Il facilite la production de rapports pour les QBR et les audits

Des rapports d’erreurs de correctifs clairs vous aident à instaurer la confiance avec vos clients lors des QBR et des audits. Ils démontrent votre engagement à construire et à maintenir un environnement informatique sécurisé.

Il maintient le calendrier de mise à jour

Les erreurs non détectées peuvent allonger les fenêtres de mise à jour ou entraîner des manquements aux SLA (contrat de niveau de service). Une base de données des erreurs de mise à jour vous aidera à détecter les problèmes au plus tôt et à ajuster votre déploiement en conséquence.

Comment NinjaOne améliore le reporting et l’analyse des erreurs de correctifs

NinjaOne peut renforcer votre reporting des erreurs de correctifs et votre analyse grâce à :

• le déploiement de scripts d’audit normalisés dans plusieurs environnements ;
• l’étiquetage des appareils avec la cause de l’échec et l’horodatage via des champs personnalisés, au lieu du registre Windows ;
• la configuration d’alertes pour les causes récurrentes d’échec des correctifs, comme les problèmes de disque, les blocages de redémarrage ou les conflits MSI ;
• la génération de rapports de fiabilité des correctifs par client, pour les revues internes et les QBR ;
• le déclenchement de workflows de remédiation, comme le redémarrage forcé ou le vidage du cache, en fonction du type d’échec détecté.

Avec NinjaOne, les MSP peuvent boucler le cycle détection, classification, remédiation et reporting, sans dépendre d’un outil tiers.

Simplifiez le reporting des erreurs de mise à jour avec les outils natifs de Windows

Vous n’avez pas besoin d’outils complexes ou coûteux pour comprendre comment et pourquoi les échecs de correctifs se produisent. Les outils tiers peuvent être utiles, mais les outils natifs de Windows comme PowerShell et la journalisation du registre suffisent à eux seuls pour étiqueter et catégoriser les causes racines.

Plus important encore, ils vous aident à résoudre les blocages courants avec les GPO et à proposer à tous vos clients des services de remédiation proactifs.

Sujets connexes :

• Les erreurs de gestion des correctifs et comment les éviter
• Processus de gestion des correctifs : bonnes pratiques
• Comment automatiser la gestion des correctifs
• Comment désinstaller un correctif problématique : guide étape par étape