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:
| Anillo | Qué servidores | Cuándo |
|---|---|---|
| 0 · Pruebas | Laboratorio y preproducción de las aplicaciones clínicas | Día +1 a +3 |
| 1 · No críticos | Ficheros, impresión, herramientas de IT | Semana 1 |
| 2 · Con redundancia | Clústeres y pares balanceados, de un nodo en uno | Semana 2 |
| 3 · Únicos y sensibles | Servidores sin redundancia, en su ventana pactada | Semana 2 o 3 |
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 StoppedTest-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'FalseGet-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.
- 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. - Se arranca a mano y se comprueba con radiología que entran estudios.
- 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.
What you'll get
Applying each month's security updates to the hospital's Windows servers without A&E, the laboratory or radiology losing service. The idea is simple: nothing critical reboots on its own, anything with redundancy is patched one node at a time, and anything without it is patched in a window agreed with the people who use it, with the downtime procedure ready.
Before you start
- The inventory of servers with their application, their clinical or service owner, and whether each is a cluster, a balanced pair or a single server.
- The deployment tool: WSUS, MECM or Azure Update Manager (section 4).
- Recent backups or VM snapshots, and the rule for deleting them afterwards (a forgotten snapshot is a problem too).
- The list of clinical application vendors that validate patches before you install them, and how long they take.
1. Rings and calendar
Microsoft releases on the second Tuesday of each month (Patch Tuesday). The calendar counts from that day:
| Ring | Which servers | When |
|---|---|---|
| 0 · Test | Laboratory and pre-production of the clinical applications | Day +1 to +3 |
| 1 · Non-critical | File, print, IT tools | Week 1 |
| 2 · Redundant | Clusters and balanced pairs, one node at a time | Week 2 |
| 3 · Single and sensitive | Servers without redundancy, in their agreed window | Week 2 or 3 |
A critical patch under active exploitation can shorten the timings: that is decided in the change board, not by the urgency of whoever reads about it first.
2. Windows with clinical owners
- One window per system, not one for the whole hospital. The laboratory peaks first thing; radiology works nights with A&E; the pharmacy prepares unit doses at fixed times.
- The window is agreed with the service owner and the duty nurse manager is told, since they know what is happening on the wards at that hour.
- For single servers, the maximum outage is agreed (for example, 20 minutes) and the paper downtime procedure is ready.
- Outside the window, servers don't reboot: the Windows Update policy or the tool's maintenance window prevents it.
3. Clusters and balanced pairs
Failover clusters. Cluster-Aware Updating (CAU) pauses a node, moves its roles, updates it, reboots it, brings it back and moves on to the next. It uses the update source configured on the nodes, so it respects WSUS.
Invoke-CauScan -ClusterName CL-LIS01 -CauPluginName Microsoft.WindowsUpdatePlugin | Select-Object NodeName, UpdateTitleNodeName UpdateTitle-------- -----------SRV-LIS-N1 Cumulative Update for Windows Server 2022 (KB50xxxxx)SRV-LIS-N2 Cumulative Update for Windows Server 2022 (KB50xxxxx)Invoke-CauRun -ClusterName CL-LIS01 -CauPluginName Microsoft.WindowsUpdatePlugin -MaxFailedNodes 0 -MaxRetriesPerNode 2 -RequireAllNodesOnline -Force-MaxFailedNodes 0 makes the run stop if a node fails, instead of carrying on and leaving the cluster without redundancy. The report is in Get-CauReport -ClusterName CL-LIS01 -Last -Detailed.
Pairs behind a load balancer (web or application servers). One at a time: drain the node in the load balancer until it has no sessions, patch and reboot it, check it, re-enable it and only then move to the other. If sessions are long (a nursing station open the whole shift), start draining hours in advance.
4. The tools
- WSUS: approval by computer groups, which map to the rings. Simple, but reboot scheduling goes through policy.
- MECM: software update groups, deployments per collection and maintenance windows on each collection (MECM / SCCM guide).
- Azure Update Manager: for Azure VMs and on-premises servers connected through Azure Arc, with scheduled maintenance configurations. On Windows Server 2025 with Arc, Hotpatch installs most security patches without a reboot; baseline months do reboot.
5. Before and after each server
Get-Service | Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' } | Select-Object Name, StatusName Status---- ------sppsvc StoppedTest-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'FalseGet-CimInstance Win32_LogicalDisk -Filter "DeviceID='C:'" | Select-Object DeviceID, @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}}DeviceID FreeGB-------- ------C: 18.4- Before: the list of stopped automatic services (so you know which were already stopped), no pending reboot, space on
C:, backup or snapshot taken. - After: the same list, compared with the earlier one; the application responds; error events since the reboot; and a functional test by the owner (a study that opens in the viewer, a result that arrives).
6. The ticket: "after Patch Tuesday a server didn't come back / a service didn't start"
The server doesn't come back. Look at the console (hypervisor or the physical server's remote management): if it shows "Working on updates" or is undoing changes, wait the agreed time. If it loops, revert pending actions from the recovery environment with dism /image:C:\ /cleanup-image /revertpendingactions. If it still won't boot, restore the snapshot or backup and tell the owner the server is left without the patch.
A service didn't start. Sunday, 7:10: radiology isn't receiving images from the MRI scanner. The service that receives them is stopped after the overnight reboot.
- The system log says why:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7000,7009,7023,7034; StartTime=(Get-Date).AddHours(-8)}. An event 7009 is a timeout while starting. - Start it by hand and check with radiology that studies are coming in.
- The cause: the service depends on the database, which takes longer to be ready after the patch. With the vendor, set a dependency or Automatic (Delayed Start).
Uninstalling the patch. Only if the patch is the problem. Recent cumulative updates are bundled with the servicing stack update and can't be removed with wusa /uninstall: find the package with DISM /Online /Get-Packages and remove it with DISM /Online /Remove-Package /PackageName:....
Next steps
- The Level 2 Windows Server guide covers basic server administration.
- The MECM / SCCM guide details deployments and maintenance windows.
- The Hyper-V guide explains the clusters CAU runs on.
- The Azure Monitor and Log Analytics guide helps you alert on stopped services after the window.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →