Windows Server: actualizaciones planificadas sin cortar el servicio

Qué vas a conseguir

Aplicar las actualizaciones de seguridad de cada mes a los servidores Windows del hospital sin que urgencias, el laboratorio o radiología se queden sin servicio. La idea es sencilla: nada crítico se reinicia solo, todo lo que tiene redundancia se parchea de un nodo en uno, y lo que no la tiene se parchea en una ventana pactada con quien trabaja con ello, con el procedimiento de contingencia preparado.

Antes de empezar

• El inventario de servidores con su aplicación, su responsable clínico o de servicio, y si es un clúster, un par balanceado o un servidor único.
• La herramienta de despliegue: WSUS, MECM o Azure Update Manager (sección 4).
• Copias de seguridad recientes o instantáneas de las VM, y el criterio para borrarlas después (una instantánea olvidada también es un problema).
• La lista de proveedores de aplicaciones clínicas que validan los parches antes de que los instales, y en qué plazo.

1. Anillos y calendario

Microsoft publica el segundo martes de cada mes (Patch Tuesday). El calendario cuenta desde ese día:

Un parche crítico explotado activamente puede acortar los plazos: se decide en el comité de cambios, no por la urgencia de quien lo lee primero.

2. Ventanas con los responsables clínicos

• Una ventana por sistema, no una para todo el hospital. El laboratorio tiene picos a primera hora; radiología trabaja de noche con urgencias; la farmacia prepara la dosis unitaria a horas fijas.
• La ventana se pacta con el responsable del servicio y se avisa a la supervisión de guardia, que es quien sabe a esa hora qué está pasando en planta.
• Para los servidores únicos se acuerda el corte máximo (por ejemplo, 20 minutos) y se tiene preparado el procedimiento de contingencia en papel.
• Fuera de la ventana, los servidores no reinician: la directiva de Windows Update o la ventana de mantenimiento de la herramienta lo impide.

3. Clústeres y pares balanceados

Clústeres de conmutación por error. Cluster-Aware Updating (CAU) pausa un nodo, mueve sus roles, lo actualiza, lo reinicia, lo devuelve y pasa al siguiente. Usa el origen de actualizaciones configurado en los nodos, así que respeta WSUS.

›Invoke-CauScan -ClusterName CL-LIS01 -CauPluginName Microsoft.WindowsUpdatePlugin | Select-Object NodeName, UpdateTitleNodeName     UpdateTitle--------     -----------SRV-LIS-N1   Actualización acumulativa para Windows Server 2022 (KB50xxxxx)SRV-LIS-N2   Actualización acumulativa para Windows Server 2022 (KB50xxxxx)›Invoke-CauRun -ClusterName CL-LIS01 -CauPluginName Microsoft.WindowsUpdatePlugin -MaxFailedNodes 0 -MaxRetriesPerNode 2 -RequireAllNodesOnline -Force

-MaxFailedNodes 0 hace que la ejecución se detenga si un nodo falla, en lugar de seguir y dejar el clúster sin redundancia. El informe queda en Get-CauReport -ClusterName CL-LIS01 -Last -Detailed.

Pares detrás de un balanceador (servidores web o de aplicación). De uno en uno: se drena el nodo en el balanceador hasta que no tiene sesiones, se parchea y reinicia, se comprueba, se vuelve a activar y solo entonces se pasa al otro. Si las sesiones son largas (un puesto de enfermería abierto todo el turno), el drenaje se empieza con horas de antelación.

4. Las herramientas

• WSUS: aprobación por grupos de equipos, que se corresponden con los anillos. Sencillo, pero la programación de reinicios va por directiva.
• MECM: grupos de actualizaciones de software, despliegues por colección y ventanas de mantenimiento en cada colección (guía de MECM / SCCM).
• Azure Update Manager: para VM de Azure y servidores locales conectados con Azure Arc, con configuraciones de mantenimiento programadas. En Windows Server 2025 con Arc, Hotpatch instala la mayoría de los parches de seguridad sin reiniciar; los meses de línea base sí reinician.

5. Antes y después de cada servidor

›Get-Service | Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' } | Select-Object Name, StatusName              Status----              ------sppsvc            Stopped›Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'False›Get-CimInstance Win32_LogicalDisk -Filter "DeviceID='C:'" | Select-Object DeviceID, @{n='LibreGB';e={[math]::Round($_.FreeSpace/1GB,1)}}DeviceID LibreGB-------- -------C:       18.4

• Antes: la lista de servicios automáticos parados (para saber cuáles ya lo estaban), sin reinicio pendiente, espacio en C:, copia o instantánea hecha.
• Después: la misma lista, comparada con la de antes; la aplicación responde; los eventos de error desde el reinicio; y una prueba funcional del responsable (un estudio que se abre en el visor, un resultado que llega).

6. El ticket: "tras el Patch Tuesday un servidor no volvió / un servicio no arrancó"

El servidor no vuelve. Mira la consola (hipervisor o gestión remota del físico): si está en "Trabajando en las actualizaciones" o deshaciendo cambios, espera el tiempo pactado. Si entra en bucle, desde el entorno de recuperación se revierten las acciones pendientes con dism /image:C:\ /cleanup-image /revertpendingactions. Si con eso no arranca, se restaura la instantánea o la copia y se avisa al responsable de que el servidor queda sin el parche.

Un servicio no arrancó. Domingo, 7:10: radiología no recibe imágenes de la resonancia. El servicio que las recibe está parado tras el reinicio de la noche.

1. El registro del sistema dice por qué: Get-WinEvent -FilterHashtable @{LogName='System'; Id=7000,7009,7023,7034; StartTime=(Get-Date).AddHours(-8)}. Un evento 7009 es un tiempo de espera agotado al arrancar.
2. Se arranca a mano y se comprueba con radiología que entran estudios.
3. La causa: el servicio depende de la base de datos, que tarda más en estar lista tras el parche. Con el proveedor se configura una dependencia o el inicio Automático (inicio retrasado).

Desinstalar el parche. Solo si el problema es el parche. Las acumulativas recientes van con la actualización de la pila de servicio y no se quitan con wusa /uninstall: se busca el paquete con DISM /Online /Get-Packages y se elimina con DISM /Online /Remove-Package /PackageName:....

Siguientes pasos

• La guía de Windows Server del Nivel 2 cubre la administración básica de los servidores.
• La guía de MECM / SCCM detalla despliegues y ventanas de mantenimiento.
• La guía de Hyper-V explica los clústeres sobre los que corre CAU.
• La guía de Azure Monitor y Log Analytics sirve para alertar de servicios parados tras la ventana.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.