Cómo informar de las causas raíz de los fallos de parches sin una herramienta de analytics dedicada

La gestión de parches conlleva muchos riesgos. El software incompatible y las actualizaciones que entran en conflicto pueden provocar despliegues fallidos, lo que a su vez deriva en incumplimientos normativos y un mayor riesgo de brechas de seguridad.

Piénsalo así: no desplegar los parches de tus aplicaciones es como dejar la puerta de casa sin cerrar.

Por eso tu equipo debería informar cuándo falla un parche y por qué. Existen distintas herramientas de terceros para visualizar tendencias, pero suelen ser demasiado caras o tener un alcance demasiado amplio como para identificar causas raíz concretas.

Para que ningún despliegue fallido pase desapercibido, conviene crear un proceso estandarizado de informes de errores de parches que no dependa de paneles de terceros.

En esta guía te mostramos cómo diagnosticar e informar de errores de parches con las herramientas nativas del SO.

Si prefieres verlo explicado en vídeo, mira Cómo informar de las causas raíz de los fallos de parches sin una herramienta de analytics dedicada.

Cómo diagnosticar e informar de errores de parches con herramientas nativas de Windows

Hay varias formas de diagnosticar e informar de errores de parches con herramientas nativas de Windows, pero antes de empezar asegúrate de cumplir estos requisitos:

📌 Requisitos previos:

• Acceso de administrador a los dispositivos afectados
• Conocimientos de PowerShell, Visor de eventos e inspección del registro
• Registros locales o accesibles desde el RMM
• Conocimiento de los códigos de error de Microsoft Update y de los instaladores de actualizaciones de terceros más habituales
• Programar la ejecución de scripts mediante el Programador de tareas o una política de NinjaOne (opcional)

📌 Estrategias de despliegue recomendadas:

Paso 1: define las categorías habituales de causa raíz

📌 Caso de uso: crear un proceso estandarizado para identificar las posibles causas de los fallos de parches en cientos de endpoints.

Agrupa todos los fallos de parches notificados en causas raíz comunes, por ejemplo:

Crear estas categorías te ayudará a aplicar procedimientos de remediación e informes coherentes.

Paso 2: elige un método para identificar, registrar e informar de los fallos de parches

El siguiente paso es elegir un método para identificar, registrar e informar de los fallos de parches. Puedes optar por uno de los métodos que se describen a continuación o combinarlos, según tus necesidades y objetivos.

Método 1: recopilar registros de fallos con PowerShell y consultas al registro de eventos

📌 Caso de uso: solucionar fallos de parches en equipos concretos extrayendo los registros y las marcas del sistema relevantes con PowerShell.

1. Consultar las actualizaciones fallidas (ID de evento 20 de Windows)

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

⚠️Importante: la ruta debe existir para que este método funcione. De lo contrario, devolverá un mensaje de error.

2. Comprobar si hace falta reiniciar

$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. Obtener las 5 últimas actualizaciones de seguridad fallidas

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

4. Listar las 5 últimas actualizaciones críticas y hotfixes fallidos

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étodo 2: usar CMD para extraer registros y errores de actualización

📌 Caso de uso: realizar diagnósticos rápidos en varios endpoints revisando los registros de Windows Update.

1. Consultar los registros de Windows Update (Windows 10 y posteriores)

Get-WindowsUpdateLog

Puedes revisar el resultado de este comando en: C:\Users\<YourUsername>\Desktop\WindowsUpdate.log

2. Buscar errores de actualización

findstr /C:"error"

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

3. Confirmar que los servicios necesarios están en ejecución

sc query wuauserv

sc query bits

💡Nota: el nombre de servicio wuauserv corresponde a Windows Update, mientras que bits hace referencia al Servicio de transferencia inteligente en segundo plano. Este transfiere archivos aprovechando el ancho de banda inactivo de la red y permite que Windows Update descargue las actualizaciones de forma eficiente.

4. Listar los cambios de nombre de archivo pendientes (motivo habitual de reinicio)

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

Si el valor PendingFileRenameOperations existe o contiene datos, significa que hay uno o más archivos pendientes y que se requiere un reinicio para completar la operación.

Método 3: guardar los metadatos de la causa raíz en el Registro para generar informes

📌 Caso de uso: automatizar los informes de errores de parches escribiendo metadatos categorizados en el registro de Windows para que los recopile tu herramienta RMM.

1. Cuando se produzca un fallo, escribe los valores de causa raíz categorizados en el Registro para que el RMM los consulte

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

Después, registra o exporta los datos de auditoría a un archivo para los informes:

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

💡Nota: «DiskFull» es solo un valor de ejemplo. Debes sustituirlo por la causa raíz real detectada (por ejemplo, «NetworkTimeout», «PermissionDenied», etc.)

2. Comprobación en CMD

reg query HKLM\SOFTWARE\Org\PatchAudit

⚠️Importante: el comando reg query HKLM\SOFTWARE\Org\PatchAudit solo funciona si los pasos anteriores se han completado correctamente.

Método 4: automatizar los informes de fallos con tareas programadas o herramientas RMM

📌 Caso de uso: crear una tarea programada que analice los fallos de parches, etiquete las causas raíz y active alertas para los errores recurrentes.

1. Crear una tarea programada que analice y etiquete

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

AuditPatchFailure.s1 es un script de PowerShell que recopila todos los eventos de parches fallidos, analiza sus causas raíz y guarda metadatos categorizados en el registro de Windows, en HKLM:\SOFTWARE\Org\PatchAudit.

Como alternativa, puedes usar NinjaOne para:

• • Recopilar automáticamente el resultado en un campo personalizado.
  • Crear alertas para parches fallidos, reinicios pendientes y la detección de una causa raíz concreta.
  • Abrir tickets automáticamente para los errores recurrentes.

NinjaOne simplifica el proceso de parcheado mostrando todos los parches instalados, ausentes, pendientes o fallidos sin necesidad de scripts manuales ni tareas programadas. Centraliza la gestión de parches en una sola plataforma, lo que facilita la monitorización y la resolución de los fallos de parches.

Para más detalles, consulta más abajo cómo NinjaOne puede mejorar los informes y el análisis de errores de parches.

⚠️ Importante: antes de aplicar este método debes crear el script AuditPatchFailure.s1.

Método 5: usar directivas de grupo para anticiparse a los fallos más comunes

📌 Caso de uso: evitar los errores de parches más habituales aplicando configuraciones a nivel de sistema en varios endpoints mediante directivas de grupo.

1. Forzar el registro de WUA y 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. Usar un GPO para impedir que se posponga el reinicio

Configuración del equipo > Windows Update > No reiniciar automáticamente si hay usuarios con sesión iniciada en las instalaciones programadas de actualizaciones automáticas.

Para que la tarea se ejecute incluso si el sistema está suspendido durante la instalación programada, debes:

• • Activar la opción de reactivación

1. 1. 1. En el Programador de tareas, ve a las Propiedades de la tarea → pestaña Condiciones
      2. Activa «Despertar el equipo para ejecutar esta tarea»

• • Activar los temporizadores de reactivación

1. 1. 1. Ve a Panel de control → Opciones de energía → Cambiar la configuración del plan → Configuración avanzada de energía
      2. En Suspender, busca Temporizadores de reactivación y actívalos

• • Configurar los ajustes del Programador de tareas

1. 1. 1. Abre el Programador de tareas y ve a las Propiedades de la tarea
      2. En la pestaña Configuración, activa «Ejecutar la tarea lo antes posible si se pasa por alto un inicio programado» para asegurarte de que la tarea se ejecute aunque el sistema estuviera suspendido o apagado a la hora prevista.

⚠️ Aspectos a tener en cuenta

Ten presentes estos posibles problemas al seguir nuestra guía:

Amplía tu caja de herramientas: consejos adicionales para seguir e informar de los errores de parches

Estos pasos adicionales te ayudarán a agilizar tu proceso de informes de errores de parches:

No te olvides de los registros de parches de terceros

No centres tus informes solo en los registros de Windows: revisa también C:\ProgramData\Package Cache\ o %ProgramFiles% para localizar los registros de terceros.

Los registros de Windows Update solo te dirán que una actualización ha fallado, pero los registros del proveedor te ayudan a entender por qué ha fallado. Consultarlos te permitirá corregir los errores más rápido.

Crea un runbook para tu equipo

Un runbook es un documento vivo que recoge los tipos de fallo más habituales, cómo identificarlos y qué hacer a continuación. Es una herramienta muy útil para simplificar la resolución de parches fallidos.

Vigila las tendencias con informes basados en umbrales

Un parche fallido puede ser un simple fallo puntual, pero un error que se repite en tres dispositivos o más es una señal de alarma. Esos despliegues fallidos apuntan a un problema de fondo que podría afectar a varias sedes.

Para seguir la pista a estos patrones, crea alertas que salten cuando tres o más equipos notifiquen la misma causa. Así podrás escalar el problema rápidamente y evitar fallos futuros.

Convierte los códigos de causa raíz en resúmenes fáciles de entender

No todas las partes implicadas son expertos en TI capaces de entender qué significa «RebootRequired» o «ID de evento 20». Lo mejor es traducir esos errores a resúmenes claros y legibles que puedas incluir en tus revisiones trimestrales de negocio (QBR).

Por qué importa informar de las causas de los errores de parches

Acelera la resolución de problemas

Los informes de errores de parcheado eliminan las conjeturas al resolver parches fallidos y te permiten automatizar la remediación. Tus técnicos ya no tendrán que hacer de detectives cada vez que falle un parche.

Ayuda a no repetir los mismos errores

Entender por qué falló un parche te ayudará a evitar que vuelva a ocurrir. Y, lo que es más importante, te permitirá detectar el software obsoleto o las configuraciones problemáticas que provocan esos fallos.

Facilita la elaboración de informes para QBR y auditorías

Unos informes claros de errores de parches te ayudan a ganarte la confianza de tus clientes en las QBR y las auditorías. Demuestran tu compromiso con crear y mantener un entorno de TI seguro.

Mantiene el parcheado dentro del calendario

Los errores que no se detectan pueden alargar las ventanas de parcheado o provocar incumplimientos de los acuerdos de nivel de servicio (SLA). Una base de datos de errores de parcheado te ayudará a detectar los problemas a tiempo y a ajustar el despliegue en consecuencia.

Cómo NinjaOne mejora los informes y el análisis de errores de parches

NinjaOne puede mejorar tus informes de errores de parches y su análisis gracias a que te permite:

• Desplegar scripts de auditoría estandarizados en varios entornos
• Etiquetar dispositivos con la causa del fallo y la marca de tiempo mediante campos personalizados, en lugar de usar el registro de Windows
• Configurar alertas para las causas recurrentes de parches fallidos, como problemas de disco, reinicios bloqueados o conflictos de MSI
• Generar informes de fiabilidad de parches por cliente para revisiones internas y QBR
• Activar flujos de remediación, como forzar el reinicio o vaciar la caché, según el tipo de fallo detectado

Con NinjaOne, los MSP pueden cerrar el círculo entre detección, clasificación, remediación e informes sin depender de una herramienta de terceros.

Simplifica los informes de errores de parcheado con las herramientas nativas de Windows

No necesitas herramientas complejas ni caras para entender cómo y por qué fallan los parches. Las herramientas de terceros pueden ser útiles, pero las nativas de Windows, como PowerShell y el registro del Registro, ya te permiten etiquetar y clasificar las causas raíz.

Y lo que es más importante: te ayudan a resolver los bloqueos más habituales con GPO y a ofrecer servicios de remediación proactiva a todos tus clientes.

Temas relacionados:

• Errores en la gestión de parches y cómo evitarlos
• Proceso de gestión de parches: buenas prácticas
• Cómo automatizar la gestión de parches
• Cómo desinstalar un parche problemático: guía paso a paso