Redfish GracefulRestart che non avvia il riavvio su Windows Server 2019/2022: diagnosi, log 1074 e automazione PowerShell

Il comando Redfish GracefulRestart non avvia il riavvio di Windows Server 2019/2022? In questa guida trovi come verificare con certezza se la richiesta è stata recepita, quali condizioni la bloccano e come automatizzare controlli e fallback con PowerShell e Redfish.

Indice

Scenario e obiettivo

Un amministratore invia al BMC (iDRAC, iLO, XClarity, IMM, iRMC, ecc.) la chiamata Redfish ComputerSystem.Reset con ResetType=GracefulRestart, ma il sistema operativo non riparte. L’obiettivo è:

capire se Windows ha effettivamente ricevuto e avviato il riavvio;
individuare condizioni che ne impediscono l’esecuzione (sospensione, utenti connessi, servizi/driver bloccati, errori di sistema);
impostare una procedura ripetibile con monitoraggio e piani di fallback.

Anatomia di un “GracefulRestart” Redfish

Il percorso tipico è questo:

POST Redfish su /redfish/v1/Systems/{Id}/Actions/ComputerSystem.Reset con payload {"ResetType": "GracefulRestart"}.
Il BMC risponde HTTP 202 Accepted: ha accettato la richiesta, ma non garantisce che l’OS la eseguirà.
Il BMC tenta un riavvio “ordinato” (meccanismo dipendente dal vendor: segnale ACPI, integrazione agent, ecc.).
Windows riceve la richiesta, registra l’evento 1074 (source USER32) e avvia il ciclo di shutdown/reboot.

Se l’evento 1074 non compare poco dopo l’istante della chiamata, il riavvio non è partito. Il 202 del BMC, da solo, non è sufficiente a concludere che la macchina si riavvierà.

Il controllo che non mente: Event ID 1074

Su Windows Server l’unica “prova” che il riavvio è stato accettato è la comparsa di Event ID 1074 (registro Windows Logs → System, origine USER32). L’evento specifica chi/che cosa ha richiesto l’operazione (utente, servizio, API), il tipo di azione (shutdown o riavvio) e il motivo, se fornito.

Eventi da monitorare (sequenza tipica)

Event ID	Source	Significato	Cosa dedurre
1074	USER32	L’OS ha ricevuto e avviato un arresto/riavvio “graceful”. Spesso include il motivo.	Se presente dopo il tuo POST Redfish, il riavvio è partito regolarmente.
6006	EventLog	“Event Log service stopped”	Conferma che il shutdown è arrivato alla fase finale.
6005	EventLog	“Event Log service started”	Conferma l’avvio dopo il reboot.
6008	EventLog	Shutdown precedente imprevisto	Indica un riavvio forzato/crash (non “graceful”).
41	Kernel‑Power	Riavvio imprevisto	Segno di power-loss o reset hardware.
109	Kernel‑Power	Avvio di una transizione di shutdown	Talvolta appare in riavvii pianificati o scriptati.
42	Kernel‑Power	Ingresso in sospensione	Se presente nelle vicinanze temporali, l’OS potrebbe essere in S3/S4 e non elaborare il gracefull.

Nota importante: non esiste un evento “richiesta rifiutata”. L’assenza di 1074 (o della sequenza 6006→6005) equivale a dire che il riavvio non è stato avviato dall’OS.

Perché il riavvio “graceful” può non partire

Sospensione/Ibernazione (S3/S4): in sleep/hibernate il sistema non processa la richiesta; finché non torna in S0, GracefulRestart non ha effetto.
Sessioni utente e app: Windows notifica le sessioni aperte; applicazioni o servizi che non rispondono possono ritardare/bloccare lo shutdown fino allo scadere di un timeout.
Servizi/driver in errore: componenti in stato “stop pending” o in crash possono mandare in stallo la pipeline di shutdown; gli errori compaiono nei log Applicazione/Sistema.
Policy/interazione: se è attivo lo Shutdown Event Tracker o policy di blocco, alcune implementazioni richiedono una motivazione; in assenza, il percorso può degradare su attese prolungate.
Problemi di integrazione BMC ↔ OS: in alcuni ambienti il BMC invia un “power button press” ACPI; se il sistema è disabilitato per reagire o è in stato non pronto, l’evento non innesca il 1074.

Checklist rapida (playbook operativo)

Invia il GracefulRestart via Redfish, annotando l’istante T0.
Entro ~30 s, verifica l’evento 1074 con timestamp ≥ T0:
- Se presente → ok, il riavvio è partito.
- Se assente → indaga cause bloccanti (sleep, utenti, servizi/driver).
Automatizza: script che invia il POST, monitora l’evento 1074 e, se non compare entro N secondi, lancia una notifica o un fallback (ad es. shutdown /r /t 0 /f via WinRM) o valuta ForceRestart dal BMC se il servizio è critico.

Comandi veloci di verifica

Controllo immediato dell’evento 1074 (ultimi 15 minuti)

Get-WinEvent -LogName System -FilterHashtable @{Id=1074; StartTime=(Get-Date).AddMinutes(-15)} |
  Select-Object TimeCreated, Id, ProviderName, Message

Se non torna nessuna voce dopo la tua chiamata Redfish → il reboot non è partito da Windows.

Timeline essenziale di un riavvio riuscito

$t0 = Get-Date
... invia il POST Redfish ...
poi verifica la catena eventi
$ev = Get-WinEvent -LogName System -FilterHashtable @{StartTime=$t0; Id=@(1074,6006,6005,6008,41,109)} |
      Select-Object TimeCreated, Id, ProviderName, Message
$ev | Format-Table -AutoSize

Rilevare utenti connessi

# Utenti interattivi (RDP/console)
quser

Sessioni con dettagli via CIM

Get-CimInstance Win32_LogonSession |
Where-Object {$*.LogonType -in 2,10} |
ForEach-Object {
$* | Add-Member -NotePropertyName Users -NotePropertyValue (
(Get-CimAssociatedInstance -InputObject $ -ResultClassName Win32Account).Name -join ','
) -PassThru
} | Select-Object StartTime, LogonType, Users

Verificare sospensione/ibernazione

powercfg /a
wevtutil qe System /q:"*[System[(EventID=42 or EventID=107) and TimeCreated[timediff(@SystemTime) &lt;= 600000]]]" /f:text /rd:true

Trovare servizi che non si spengono

# Servizi in STOP_PENDING (possibili colli di bottiglia)
Get-Service | Where-Object {$_.Status -eq 'StopPending'}

Eventi di servizio nel System log, ultimi 10 minuti

Get-WinEvent -LogName System -FilterHashtable @{StartTime=(Get-Date).AddMinutes(-10); ProviderName='Service Control Manager'} |
Select-Object TimeCreated, Id, LevelDisplayName, Message

Monitoraggio dal lato Redfish

Dopo il POST GracefulRestart, molti BMC restituiscono 202. Per un riscontro lato hardware:

Interroga /redfish/v1/Systems/{Id} e leggi PowerState.
Se resta On a lungo e non vedi il 1074 su Windows, è probabile che l’OS non abbia accettato la richiesta.

POST /redfish/v1/Systems/1/Actions/ComputerSystem.Reset
{
  "ResetType": "GracefulRestart"
}

GET successivo

GET /redfish/v1/Systems/1
{
"PowerState": "On",
...
}

Automazione end‑to‑end con PowerShell (pronto all’uso)

Lo script seguente esegue: sessione Redfish → GracefulRestart → polling dell’evento 1074 → fallback opzionale (shutdown /r /t 0 /f) → verifica PowerState. Adatta URI/id di sistema, credenziali e timeout al tuo ambiente. È pensato per essere lanciato da una workstation di gestione con connettività sia verso BMC che verso l’OS (WinRM).

param(
  [Parameter(Mandatory)]
  [string]$BmcBaseUri,            # es. https://10.0.0.100
  [Parameter(Mandatory)]
  [string]$SystemId,              # es. 1 o System.Embedded.1
  [Parameter(Mandatory)]
  [pscredential]$BmcCredential,
  [Parameter(Mandatory)]
  [string]$ComputerName,          # hostname dell'OS Windows
  [int]$EventTimeoutSec = 120,    # attesa dell'evento 1074
  [switch]$EnableOsFallback,      # se vero, tenta shutdown /r /t 0 /f via WinRM
  [switch]$EnableForceRestart     # se vero, se tutto fallisce prova ForceRestart Redfish
)

function New-RedfishSession {
param([string]$BaseUri, [pscredential]$Cred)
$body = @{
UserName = $Cred.UserName
Password = [Runtime.InteropServices.Marshal]::PtrToStringAuto(
[Runtime.InteropServices.Marshal]::SecureStringToBSTR($Cred.Password)
)
} | ConvertTo-Json
$resp = Invoke-WebRequest -Uri "$BaseUri/redfish/v1/SessionService/Sessions" `
-Method POST -Body $body -ContentType 'application/json' -SkipCertificateCheck
return $resp.Headers['X-Auth-Token']
}

function Invoke-RedfishReset {
param([string]$BaseUri, [string]$SysId, [string]$Token, [ValidateSet('GracefulRestart','ForceRestart')][string]$Type)
$headers = @{ 'X-Auth-Token' = $Token }
$payload = @{ ResetType = $Type } | ConvertTo-Json
Invoke-WebRequest -Uri "$BaseUri/redfish/v1/Systems/$SysId/Actions/ComputerSystem.Reset" `
-Headers $headers -Method POST -Body $payload -ContentType 'application/json' -SkipCertificateCheck
}

function Get-RedfishPowerState {
param([string]$BaseUri, [string]$SysId, [string]$Token)
$headers = @{ 'X-Auth-Token' = $Token }
($r = Invoke-RestMethod -Uri "$BaseUri/redfish/v1/Systems/$SysId" -Headers $headers -SkipCertificateCheck).PowerState
}

function Wait-WindowsEvent1074 {
param([string]$Target, [datetime]$Since, [int]$TimeoutSec)
$deadline = (Get-Date).AddSeconds($TimeoutSec)
do {
Start-Sleep -Seconds 3
try {
$ev = Get-WinEvent -ComputerName $Target -LogName System `
-FilterHashtable @{ Id = 1074; StartTime = $Since }
if ($ev) { return $true }
} catch {
WinRM non disponibile, continua tentativi fino al timeout
}
} while (Get-Date -lt $deadline)
return $false
}

=== main ===

$t0 = Get-Date
Write-Host "[$t0] Apertura sessione Redfish su $BmcBaseUri ..."
$token = New-RedfishSession -BaseUri $BmcBaseUri -Cred $BmcCredential

Write-Host "[$(Get-Date)] Invio ResetAction=GracefulRestart ..."
$resp = Invoke-RedfishReset -BaseUri $BmcBaseUri -SysId $SystemId -Token $token -Type 'GracefulRestart'
Write-Host "HTTP: $($resp.StatusCode) - attesa dell'evento 1074 su $ComputerName (timeout $EventTimeoutSec s) ..."

$started = Wait-WindowsEvent1074 -Target $ComputerName -Since $t0 -TimeoutSec $EventTimeoutSec
if ($started) {
Write-Host "Evento 1074 rilevato: Windows ha avviato il riavvio."
} else {
Write-Warning "Evento 1074 NON trovato entro il tempo previsto."
if ($EnableOsFallback) {
Write-Warning "Esecuzione fallback: shutdown /r /t 0 /f su $ComputerName"
try {
Invoke-Command -ComputerName $ComputerName -ScriptBlock { shutdown.exe /r /t 0 /f } -ErrorAction Stop
} catch { Write-Warning "Fallback OS non riuscito: $*" }
}
if ($EnableForceRestart) {
Write-Warning "Invio ResetAction=ForceRestart dal BMC"
try { Invoke-RedfishReset -BaseUri $BmcBaseUri -SysId $SystemId -Token $token -Type 'ForceRestart' | Out-Null }
catch { Write-Warning "ForceRestart non riuscito: $*" }
}
}

Write-Host "PowerState lato Redfish: $(Get-RedfishPowerState -BaseUri $BmcBaseUri -SysId $SystemId -Token $token)"

Note: -SkipCertificateCheck è usato qui per semplicità in laboratorio: in produzione configura certificati validi. Valuta la protezione delle credenziali e l’auditing.

Diagnosi guidata delle cause bloccanti

Sospensione o ibernazione attive

Su server, sleep/hibernate dovrebbero essere disabilitati. Se il sistema entra in S3/S4, un GracefulRestart può essere ignorato fino al rientro in S0.

Verifica stati supportati: powercfg /a.
Controlla eventi di sleep (ID 42) o resume (ID 107) nelle ultime finestre temporali.
Disabilita via criteri: Computer Configuration → Administrative Templates → System → Power Management → Sleep Settings (disabilita S1–S3 e hibernate dove non necessario).

Utenti e applicazioni interattive

Terminal server, jump host o server applicativi con utenti attivi possono ritardare lo shutdown per “lavoro non salvato”. Per i server, spesso è accettabile impostare chiusura forzata app.

Valuta policy/registry come AutoEndTasks e WaitToKillServiceTimeout (HKCU/HKLM), con prudenza.
Prima del riavvio pianificato, invia notifica e chiudi sessioni inattive.

Servizi/driver problematici

Servizi in “stop pending” persistente o driver che generano errori possono congelare la pipeline di spegnimento. Il registro System (origine Service Control Manager) è il primo luogo da osservare. Colleziona questi segnali e agisci su aggiornamenti o fix del vendor.

Aggiornamenti Windows

La presenza di aggiornamenti in stato “pending” non dovrebbe impedire un gracefull; al contrario, un riavvio dovrebbe completarne l’installazione. Se osservi stalli ripetuti, indaga componenti Servicing (CBS) e TrustedInstaller nei log Applicazione e nei canali operativi di WindowsUpdateClient.

Best practice per l’osservabilità

Shutdown Event Tracker: abilitalo via GPO (“Display Shutdown Event Tracker”) per forzare la specifica del motivo; rende l’evento 1074 più informativo.
Canali avanzati: abilita Applications and Services Logs → Microsoft → Windows → Kernel‑Power (Operational) e Shutdown‑UI in modalità Verbose.
Windows Event Forwarding (WEF): inoltra gli eventi chiave (1074, 6006, 6005, 41, 6008, 109) a un server centrale/SIEM.
Runbook: formalizza finestra di attesa (es. 90–180 s per 1074), escalation (fallback OS / ForceRestart), e soglie di allarme.

Procedure consigliate (step‑by‑step)

Prima: verifica che il server non usi sleep/hibernate; notifica eventuali utenti; se in cluster, drain del nodo (Hyper‑V, SQL, ecc.) e Pause‑ClusterNode.
Invio comando: POST GracefulRestart e salva T0.
Entro 30–60 s: cerca 1074 (e poi 6006).
Se 1074 assente: analizza rapidamente sleep, sessioni utente e servizi bloccati; valuta fallback.
Dopo il riavvio: conferma 6005; registra esito e motivo (da 1074) nel change record.

Domande frequenti

Il 202 del BMC significa che il server si riavvierà di sicuro?
No: significa solo che il BMC ha accettato la richiesta. La prova dell’avvio del riavvio è l’evento 1074 su Windows.

Esiste un evento che dice “richiesta rifiutata”?
No: l’assenza del 1074 (o della sequenza 6006→6005) indica che il riavvio non è iniziato dal sistema operativo.

Quando ha senso usare ForceRestart?
Quando il servizio è critico e il gracefull non parte dopo i controlli/fallback. ForceRestart equivale a un hard reset: accettane i rischi (perdita di dati non salvati, possibili corruzioni).

Se il server è in sospensione?
Riporta la macchina allo stato S0 e riprova; valuta di disabilitare sleep/hibernate sui ruoli server.

Modelli pronti all’uso

Query PowerShell per reportistica post‑incident

$window = (Get-Date).AddHours(-12)
Get-WinEvent -LogName System -FilterHashtable @{ StartTime=$window; Id=@(1074,6006,6005,6008,41,109) } |
  Sort-Object TimeCreated |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Out-File .\reboot-timeline.txt -Encoding UTF8

Verifica rapida lato Redfish + OS

# Input
$Bmc = 'https://10.0.0.100'
$Sys = '1'
$Os  = 'SRV-WEB01'
$cred = Get-Credential  # BMC

POST GracefulRestart e verifica

$token = (Invoke-WebRequest -Uri "$Bmc/redfish/v1/SessionService/Sessions" -Method POST `  -Body (@{UserName=$cred.UserName;Password=(Read-Host -AsSecureString | ConvertFrom-SecureString)} )`
-ContentType 'application/json' -SkipCertificateCheck).Headers['X-Auth-Token']

Invoke-WebRequest -Uri "$Bmc/redfish/v1/Systems/$Sys/Actions/ComputerSystem.Reset" `  -Headers @{ 'X-Auth-Token' = $token } -Method POST`
-Body (@{ResetType='GracefulRestart'} | ConvertTo-Json) `
-ContentType 'application/json' -SkipCertificateCheck

$t0 = Get-Date
Start-Sleep 5
Get-WinEvent -ComputerName $Os -LogName System -FilterHashtable @{ Id=1074; StartTime=$t0 } |
Select TimeCreated, Message

Tabella riassuntiva (Q&A → azioni concrete)

Tema	Indicazioni pratiche
Log da controllare	Event Viewer → Windows Logs → System • Event ID 1074 (source `USER32`) → l’OS ha ricevuto e avviato uno shutdown/restart (con motivo). Se manca dopo l’ora del comando, la richiesta non è stata accettata. • Eventi correlati utili: 6006 “Event Log service stopped”, 6008 “previous shutdown was unexpected”, 41 “Kernel‑Power”, 109 “Kernel‑Power Manager initiated shutdown”.
Quando la richiesta può fallire	Sospensione/Ibernazione → in S3/S4 non si elaborano comandi “graceful”. Utenti/processi attivi → app o servizi che non rispondono possono bloccare l’arresto fino al timeout. Driver/servizi in errore → possono spezzare la pipeline di shutdown (tracce nei log Applicazione/Sistema).
Verifica automatica	`Get-WinEvent -LogName System -FilterHashtable @{Id=1074; StartTime=(Get-Date).AddMinutes(-15)}` Se non ritorna nulla → il reboot non è partito.
Redfish	Dopo POST ResetAction=GracefulRestart il BMC di norma restituisce HTTP 202 Accepted. Controlla poi PowerState: se resta `On` e 1074 non appare entro la finestra definita, l’OS non ha accettato la richiesta.
Evento inesistente	Non esiste un evento che indichi “richiesta rifiutata”: l’assenza di 1074 (o della sequenza 6006/6005) = nessun reboot avviato dall’OS.

Decision tree (operatività rapida)

202 dal BMC? Sì → prosegui. No → problema di chiamata/permessi.
Event 1074 ≤ 60 s da T0? Sì → attesa del ciclo 6006→6005. No → vai al punto successivo.
Sleep S3/S4? Sì → porta in S0, disabilita sleep su server. No → controlla utenti/app/servizi.
Servizi stop pending o errori SCM? Sì → risolvi o aumenta timeout; riprova. No → fallback programmato.
Fallback OS riuscito? Sì → fine. No → ForceRestart (consapevoli dei rischi) e post‑mortem.

Checklist di hardening e qualità

Disabilita sleep/hibernate sui ruoli server.
Attiva Shutdown Event Tracker per motivazioni tracciabili (Event 1074).
Stabilisci time‑box per il gracefull (es. 120 s), quindi fallback automatico.
Centralizza gli eventi in WEF/SIEM e crea alert su anomalie (es. 6008/41 senza 1074).
Per cluster/HA, integra nel runbook Pause / Drain prima del riavvio.

Conclusioni

Quando un GracefulRestart via Redfish “non parte”, il discrimine tecnico è semplice: c’è o non c’è l’Event ID 1074. Tutto il resto—202 del BMC, PowerState a On, silenzio dei log—non prova che Windows abbia accettato la richiesta. Strutturando un controllo sistematico (1074/6006/6005), verificando condizioni bloccanti (sleep, utenti, servizi) e predisponendo fallback ragionati, porti il processo da “speranza” a esito misurabile, riducendo tempi di fermo e incertezza operativa.