Reinicio por Redfish en Windows Server 2019/2022: diagnóstico completo y soluciones paso a paso

Un reinicio “limpio” (graceful reboot) enviado por Redfish es la forma más segura de reiniciar un servidor sin forzar la alimentación. Sin embargo, en Windows Server 2019 y 2022 no siempre se completa: el BMC reporta que ha despachado la orden, pero el sistema operativo permanece encendido o simplemente se apaga sin volver a arrancar. A continuación se explica cómo diagnosticar y resolver el problema, desde la llegada de la señal ACPI hasta la intervención de las aplicaciones que pueden bloquear el apagado.

Índice

Por qué la orden puede no llegar al sistema operativo

Redfish transforma la llamada ResetType=GracefulRestart en una señal ACPI (Shutdown o Reboot) a través del firmware del BMC. Entre el endpoint REST y el kernel de Windows intervienen:

BMC / iLO / iDRAC (traduce la API Redfish en una interrupción física).
BIOS/UEFI (puede filtrar la señal si existe una política de energía restrictiva).
El controlador ACPI de Windows (procesa la interrupción e inicia el apagado).
Servicio de Control de Sesiones (CSRSS) y Restart Manager (negocian con procesos usuarios y servicios).

Un fallo en cualquiera de estos niveles deja al servidor en estado “pendiente” y sin eventos de sistema evidentes. Por ello el primer paso es confirmar si Windows recibió la orden.

Cómo comprobar si el SO aceptó la solicitud de reinicio

Objetivo	Qué revisar / hacer	Detalles clave
Confirmar que la orden llegó al SO	Visor de eventos → Registro “System” → ID 1074 (Origen = User32)	• El evento indica el inicio de un apagado/reinicio “limpio”. • Muestra quién/qué lo solicitó y la razón. • Su ausencia implica que la señal ACPI no se vio reflejada en el kernel.
Verificar que el reinicio realmente comenzó y terminó	IDs 6006 (servicio de registro detenido) y 6005 (iniciado)	• 6006 marca el apagado ordenado de los servicios. • 6005 marca la siguiente puesta en marcha. • 6008 indica “apagado inesperado”.
Detectar aplicaciones que bloquean el reinicio	Registro Applications & Services Logs → Microsoft → Windows → RestartManager (eventos 10000‑10010)	• Identifica procesos que impiden el reinicio porque mantienen archivos abiertos o no responden.
Identificar rechazos o peticiones sin respuesta	No existe un ID “rechazado” específico	• Windows solo registra la acción cuando inicia el apagado. • Si el equipo estaba en suspensión o el usuario cancela el diálogo, no se genera evento alguno.
Escenarios que impiden o aplazan el reinicio	Suspensión/hibernación Sesiones RDP abiertas sin `/f` Servicios colgados o drivers que no responden BitLocker con PIN detenido en prearranque	• La orden “graceful” no despierta al host. • Sin opción forzar (`/f`), Windows espera confirmación. • Servicios atascados bloquean indefinidamente. • BitLocker requiere interacción si no se configuró autodesbloqueo.

Pasos prácticos rápidos con PowerShell

# 1. Eventos de reinicio solicitados
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} |
    Select TimeCreated, MachineName, ProviderName, Message |
    Format-Table -AutoSize

2. Cronología de apagados y arranques (éxitos y fallos)

Get-WinEvent -FilterHashtable @{LogName='System'; Id=6005,6006,6008} |
Sort-Object TimeCreated -Descending |
Select -First 20 TimeCreated, Id, Message |
Format-Table -AutoSize

3. Procesos que bloquearon el ciclo de apagado

Get-WinEvent -LogName 'Microsoft-Windows-RestartManager/Operational' |
Where-Object {\$.Id -ge 10000 -and \$.Id -le 10010} |
Select TimeCreated, Id, LevelDisplayName, Message |
Sort-Object TimeCreated

Escenarios de fallo frecuentes y cómo resolverlos

Servidor en suspensión o hibernado

La especificación Redfish no obliga al BMC a reactivar el sistema operativo antes de enviar ResetType=GracefulRestart. Si el equipo está en S3 (sleep) o S4 (hibernate), Windows no “escucha” la señal ACPI. Verifica el estado de energía con powercfg /a y deshabilita hibernación en servidores críticos:

powercfg /hibernate off

Como alternativa, envía primero un comando “On” o “Wake” desde Redfish y, tras confirmar que el sistema vuelve a S0, dispara el reinicio.

Sesiones activas sin forzar cierre

En entornos con administradores conectados por RDP o con consolas virtuales abiertas, el kernel muestra un cuadro de diálogo esperando confirmación para cerrar sesiones. La API Redfish por defecto no incluye el parámetro “force”. Si necesitas evitar bloqueos en servidores sin supervisión:

Habilita la directiva de GPO “Shutdown without logon”.
En lugar de GracefulRestart, usa ForceRestart para que el BMC envíe la señal equivalente a shutdown.exe /r /f /t 0.

Servicios o drivers que no responden

Drivers de almacenamiento, antivirus o HBA obsoletos retienen IRPs y previenen el cierre de sesión. El registro Restart Manager mostrará el nombre del proceso en los eventos 10006 (timeout) y 10010 (aplicación no reiniciable). Actualiza controladores y aplica hotfixes recomendados por el fabricante para el hardware específico.

BitLocker con PIN

Si la unidad del sistema está protegida con PIN o USB, el reinicio se detendrá antes de cargar Windows. Esto suele malinterpretarse como “no completó el reinicio”. Implementa BitLocker Network Unlock (para PXE) o cambia la operación a un warm reboot planeado desde una ventana de mantenimiento presencial.

Procedimiento de diagnóstico completo paso a paso

Correlaciona horarios. Anota la hora exacta (UTC) en que el BMC recibió la orden Redfish.
Confirma la llegada al kernel. Busca el ID 1074 pocos segundos después; si no existe, la señal quedó en firmware.
Analiza la negociación con servicios. Inspecciona el canal Restart Manager para identificar procesos problemáticos.
Revisa drivers. Filtra $env:SystemRoot\System32\winevt\Logs\System.evtx por IDs 7011 y 7016 (timeouts de servicio).
Audita políticas de energía. Comprueba Group Policy y powercfg /query para detectar planes que habilitan suspensión.
Prueba con cierre forzado. Ejecuta desde Redfish o WinRM shutdown.exe /r /f /t 0 /d p:4:1 /c "Redfish test" y valida.
Documenta hallazgos. Exporta los eventos a CSV con wevtutil epl para adjuntarlos a un ticket de soporte OEM.

Automatizar el reinicio fiable con PowerShell y Redfish

Cuando la interfaz Redfish admite PATCH sobre /Systems/{Id}, se puede asegurar la ausencia de sesiones activas y forzar el reinicio en un solo script:

$Bmc      = "192.0.2.10"
$Creds    = Get-Credential
$BodyJson = @{
    ResetType = "ForceRestart"
} | ConvertTo-Json

Invoke-RestMethod -Method POST `                  -Uri "https://$Bmc/redfish/v1/Systems/1/Actions/ComputerSystem.Reset"`
-Credential \$Creds `                  -Body $BodyJson`
-ContentType "application/json"

Añade lógica de reintentos y verificación posterior:

Ping incremental cada 5 s hasta que la dirección deje de responder (apagado).
Evento 6005 como indicador de arranque terminado.
Timeout total definido según SLA (por ejemplo 15 min).

Mantenimiento preventivo del firmware

Casos documentados por varios fabricantes muestran que versiones antiguas de BMC convierten incorrectamente GracefulRestart en un pulso de energía equivalente a hard reset, o simplemente descartan la petición si el servidor está en estados de energía mezclada (por ejemplo, memoria en self-refresh). Mantén actualizado:

Firmware del BMC.
BIOS/UEFI (particularmente módulos de administración de energía).
Drivers ACPI e Intel ME.

Tras cada actualización, valida el flujo Redfish con un sistema de pruebas, registrando eventos antes y después, para confirmar que el cambio resuelve el problema sin introducir regresiones.

Buenas prácticas para entornos de producción

Separar “maintenance window” y “user window”: impide sesiones interactivas durante la franja de reinicios automáticos.
Implementar alertas previas: 15 min antes del reinicio, Broadcast en Teams o correo a los administradores con objeto y motivo.
Política de fail‑safe: si tras tres intentos el evento 1074 no aparece, eleva la prioridad y notifica mediante SNMP / webhook.
Versionar scripts: usa GitOps; cada cambio en el proceso Redfish debe pasar por PR y pruebas de integración.

Conclusión

El reinicio mediante Redfish ofrece gestión fuera de banda estándar, pero su fiabilidad depende de:

La entrega correcta de la señal ACPI desde el BMC.
La capacidad del sistema operativo para cerrar sesiones y servicios a tiempo.
La ausencia de bloqueos por drivers, BitLocker o políticas de energía.

Con las verificaciones descritas (eventos 1074, 6005‑6006, Restart Manager, estado de energía) podrás determinar rápidamente en qué capa se interrumpe el flujo y aplicar la solución más adecuada, ya sea actualizar firmware, forzar el cierre de sesiones, o modificar la política de suspensión.