Hotpatch y Cluster-Aware Updating en Windows Server

Los servidores se quedan atrás en los parches por un motivo principal: reiniciarlos cuesta algo. Un reinicio mensual de una base de datos, un servidor de archivos o una aplicación de negocio necesita una ventana, un responsable y un plan de reversión, y cada mes alguien tiene un motivo para saltárselo. La guía principal sobre parches fija objetivos para los servidores; esta guía cubre las dos funciones de Windows Server que hacen realistas esos objetivos al reducir u ocultar el tiempo de inactividad: hotpatch y Cluster-Aware Updating (CAU).

Cómo funciona hotpatch

Un hotpatch actualiza el código en memoria de los procesos en ejecución, y en disco para el siguiente inicio, sin reiniciar. Microsoft publica los hotpatches en un ciclo trimestral:

Un servidor con hotpatch está completamente parcheado en cuanto a seguridad; no está actualizado "a medias". La contrapartida es que las correcciones no relacionadas con la seguridad esperan a la siguiente línea base, y todo lo que queda fuera de la actualización acumulativa del sistema operativo (controladores, firmware, .NET, software de terceros) sigue su proceso normal y puede reiniciar el servidor.

Paso 1: comprueba si cumples los requisitos

Hotpatch depende de la edición, la ubicación y las funciones de seguridad:

• Windows Server 2022 o 2025 Datacenter: Azure Edition en máquinas virtuales de Azure o en Azure Local. Hotpatch está incluido y se gestiona con Azure Update Manager.
• Windows Server 2025 Standard o Datacenter (compilación 26100.1742 o posterior, Desktop Experience o Server Core) en máquinas físicas o virtuales fuera de Azure, conectadas a Azure Arc, con Hotpatch habilitado en el recurso de Arc. Desde mayo de 2026 no tiene coste adicional; antes era una suscripción de pago por núcleo.
• La seguridad basada en virtualización (VBS) debe estar en ejecución, así que la máquina necesita UEFI con arranque seguro (en Hyper-V, una máquina virtual de generación 2). Hotpatch se apoya en VBS para proteger el proceso de aplicación del parche, lo que lo convierte también en un buen complemento de VBS e integridad de memoria.
• El servidor debe estar en la línea base actual; una máquina que se salta una línea base no puede recibir los hotpatches siguientes y vuelve a las actualizaciones acumulativas completas hasta ponerse al día.

Windows 11 Enterprise 24H2 y posteriores también pueden recibir hotpatches a través de Windows Autopatch en Intune. Ese programa para clientes tiene sus propios requisitos de licencia y de dispositivo, distintos del modelo de servidor descrito aquí.

Comprueba VBS en un servidor candidato:

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning
# VirtualizationBasedSecurityStatus = 2 significa que VBS está en ejecución

Si VBS está desactivado, habilítalo con Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, prueba la carga de trabajo (algunos controladores antiguos y herramientas que dependen del hipervisor protestan) y reinicia.

Paso 2: inscribe los servidores

Máquinas virtuales de Azure con Azure Edition: elige una imagen compatible con hotpatch y, en la configuración de parches de la máquina virtual, usa la aplicación de parches orquestada por Azure con hotpatch habilitado. Azure Update Manager programa entonces por ti las líneas base y los hotpatches.

Windows Server 2025 conectado a Arc: incorpora la máquina a Azure Arc con el agente Connected Machine y, en Azure Portal, ve a Azure Arc > Machines, abre la máquina, selecciona Hotpatch y después Confirm. El cambio se aplica en unos 10 minutos (el portal comprueba que VBS está en ejecución y falla en caso contrario). El servidor recibe hotpatches a partir del siguiente mes de hotpatch, siempre que esté en la línea base actual. Usa Azure Update Manager o tu herramienta actual para programar los reinicios de línea base.

La incorporación a Arc da una identidad de Azure a un servidor local. Trata la entidad de servicio de incorporación y los permisos del recurso de Arc como privilegiados: un rol que puede ejecutar comandos o instalar extensiones en máquinas de Arc es, en la práctica, administrador de esos servidores. Acota Azure RBAC con el mismo cuidado que aplicas a la administración por niveles y no incorpores nunca controladores de dominio a una suscripción gestionada por administradores de un nivel inferior.

Paso 3: planifica el calendario de parches en torno a las líneas base

Con hotpatch, el plan mensual cambia de forma:

• Meses de línea base: el mismo proceso que hoy. Grupos de parches, ventanas de mantenimiento, responsables de aplicaciones de guardia. Programa estas ventanas con un año de antelación, porque los meses son fijos.
• Meses de hotpatch: instala en los días siguientes al Patch Tuesday, en todos los servidores aptos a la vez si tus pruebas lo permiten, ya que no hay reinicio que coordinar. Mantén un pequeño grupo piloto uno o dos días por delante.
• Líneas base no planificadas: ten un procedimiento de ventana de emergencia permanente para que una línea base fuera de ciclo no espere al trimestre siguiente.

Separa en los informes los servidores inscritos en hotpatch de los demás. Es fácil pasar por alto un servidor que se ha salido en silencio del ciclo de hotpatch y ahora necesita un reinicio cada mes.

Paso 4: Cluster-Aware Updating para los roles en clúster

En los clústeres de conmutación por error (hosts Hyper-V, servidores de archivos, instancias de clúster de conmutación por error de SQL Server), CAU automatiza el patrón escalonado: vaciar un nodo, mover sus roles, instalar las actualizaciones, reiniciar, reanudar y pasar al siguiente nodo. Funciona con o sin hotpatch y forma parte de la característica Clúster de conmutación por error (módulo ClusterAwareUpdating).

Comprueba primero que todo está listo y después añade el rol en clúster de CAU en modo de actualización automática:

Test-CauSetup -ClusterName FS-CLU01

Add-CauClusterRole -ClusterName FS-CLU01 `
  -DaysOfWeek Tuesday -WeeksOfMonth 3 `
  -MaxFailedNodes 0 -MaxRetriesPerNode 2 -RequireAllNodesOnline `
  -EnableFirewallRules -Force

Parámetros clave:

• -RequireAllNodesOnline se niega a empezar si ya hay un nodo caído, para que una ejecución de actualizaciones nunca degrade aún más un clúster ya degradado.
• -MaxFailedNodes 0 detiene la ejecución en el primer nodo con error en lugar de continuar.
• -PreUpdateScript y -PostUpdateScript ejecutan tus propias comprobaciones, por ejemplo confirmar que un grupo de disponibilidad de SQL está en buen estado antes de pasar al siguiente nodo.
• El complemento predeterminado, Microsoft.WindowsUpdatePlugin, usa el Agente de Windows Update y el origen para el que estén configurados los nodos (Windows Update, WSUS). Microsoft.HotfixPlugin instala paquetes desde un recurso compartido que tú controlas.

Para una ejecución puntual a petición, desde una máquina de administración y no desde un nodo del clúster:

Invoke-CauScan -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin
Invoke-CauRun  -ClusterName FS-CLU01 -CauPluginName Microsoft.WindowsUpdatePlugin `
  -MaxFailedNodes 0 -RequireAllNodesOnline -Force

El objeto de equipo de CAU y la cuenta que ejecuta el modo de actualización remota tienen acceso de administrador a todos los nodos. Coloca el clúster y su máquina de administración en el nivel adecuado, y limita las reglas de firewall de CAU a la red de administración (consulta endurecimiento del firewall).

Los clústeres de Azure Local usan su propio administrador de ciclo de vida para las actualizaciones del sistema operativo, los controladores y el firmware; sigue ese proceso en ellos en lugar de configurar CAU directamente.

Paso 5: mantén al día el resto del servidor

Hotpatch y CAU gestionan la actualización acumulativa del sistema operativo. Las demás capas siguen necesitando su propio proceso:

• Firmware y controladores: herramientas del fabricante (por ejemplo, la suite de actualización del fabricante del servidor) en el calendario de los meses de línea base, para que sus reinicios coincidan con el que ya tienes. En los servidores protegidos con BitLocker puede que haya que suspender la protección durante un reinicio.
• .NET y otros productos de Microsoft: permite Microsoft Update en tu origen de actualizaciones; las actualizaciones de .NET suelen requerir reiniciar las aplicaciones que lo usan y, a veces, el servidor.
• Roles de servidor y aplicaciones: las actualizaciones acumulativas de SQL Server, Exchange, los módulos de IIS y los agentes de terceros siguen el calendario de sus fabricantes. Alinéalos con los meses de línea base siempre que puedas.
• Hosts Hyper-V: los invitados solo se benefician de hotpatch si su sistema operativo es apto; el reinicio del host sigue moviendo o pausando las máquinas virtuales, y ahí es donde ayuda CAU.

El objetivo es un reinicio planificado por trimestre que lo absorba todo, en lugar de varios no planificados.

Verificación

En un servidor, comprueba la revisión de compilación y el historial de actualizaciones:

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0}.{1}' -f $cv.CurrentBuild, $cv.UBR
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, Description, InstalledOn
(Get-CimInstance Win32_OperatingSystem).LastBootUpTime

Un servidor con hotpatch muestra una revisión de compilación nueva mientras LastBootUpTime se queda en la última línea base. Compara la revisión con la que figura en las notas de la versión de Microsoft para el hotpatch del mes. Los resultados de la instalación están en el registro System con el origen Microsoft-Windows-WindowsUpdateClient (evento 19 correcto, 20 error). En Azure Update Manager, el historial de actualizaciones de la máquina muestra por separado las instalaciones de hotpatch y de línea base.

Para CAU, revisa la última ejecución y los registros de eventos:

Get-CauReport -ClusterName FS-CLU01 -Last -Detailed
Get-WinEvent -LogName 'Microsoft-Windows-ClusterAwareUpdating/Admin' -MaxEvents 20

Qué se rompe

• VBS deshabilitado por un controlador o un cambio en la BIOS. El servidor deja de ser apto para hotpatch sin avisar. Supervisa VirtualizationBasedSecurityStatus.
• Línea base perdida. Un servidor que se salta el reinicio trimestral vuelve a las actualizaciones acumulativas completas. Trata las ventanas de línea base como obligatorias.
• Instalaciones manuales de actualizaciones acumulativas. Instalar un paquete independiente fuera de secuencia puede sacar una máquina del ciclo de hotpatch; deja que la herramienta de orquestación instale las actualizaciones.
• Ejecuciones de CAU que se atascan en un nodo que no se vacía, a menudo por un rol con propietarios preferidos o una máquina virtual que no puede migrarse en vivo. Corrige el problema de estado del clúster; no subas MaxFailedNodes.
• Clústeres parcheados a la vez por CAU y por otra herramienta. Dos orquestadores reinician nodos de forma independiente y pueden hacer caer el quórum. Excluye los nodos en clúster de las directivas de anillos de tipo cliente, como las directivas de Windows Update.

Lista de comprobación

• Parque de servidores clasificado: Azure Edition, 2025 conectado a Arc, no apto
• VBS en ejecución y supervisado en los candidatos a hotpatch
• Identidad de incorporación a Arc y RBAC acotados como acceso privilegiado
• Ventanas de línea base programadas para enero, abril, julio y octubre
• Meses de hotpatch instalados en pocos días, primero el grupo piloto
• Clústeres actualizados por CAU con RequireAllNodesOnline y MaxFailedNodes 0
• Scripts de estado previos y posteriores a la actualización para los roles en clúster críticos
• Los informes separan los servidores con hotpatch, los que solo reciben líneas base y los que no cumplen

Hotpatch y CAU eliminan la objeción del reinicio en la mayoría de los servidores. El resto del proceso, desde los anillos hasta el software de terceros, está en el área de parches y actualizaciones.