Redfish GracefulRestart : diagnostiquer un redémarrage Windows Server 2019/2022 ignoré (événements 1074/6006, veille S3/S4, RDP)

Vous envoyez « Redfish Reset = GracefulRestart » à des Windows Server 2019/2022… mais rien ne se passe ? Ce guide concret vous aide à savoir si l’OS a accepté, rejeté ou ignoré la demande, et à fiabiliser vos redémarrages distants.

Sommaire

Problème posé

Dans certains environnements, une requête Redfish POST /redfish/v1/Systems/{Id}/Actions/ComputerSystem.Reset avec {"ResetType":"GracefulRestart"} ne déclenche aucun redémarrage du serveur Windows Server 2019/2022. Les objectifs opérationnels sont :

Vérifier si l’OS a accepté ou rejeté la demande.
Identifier les cas d’ignorance de la demande (veille/hibernation, sessions actives, services bloquants, GPO, etc.).

Points essentiels déjà établis

Les constats suivants servent de base à l’analyse :

Objectif	Piste proposée	Limites
Savoir qui a déclenché un redémarrage	Observateur d’événements → « Système » → ID 1074 (source : User32) : indique l’utilisateur/processus, le motif et le type (planifié / non planifié).	Si aucun 1074 n’apparaît, Windows n’a pas commencé la séquence d’arrêt.
Comprendre les refus	Aucune entrée explicite « rejetée » n’est journalisée ; seul un échec (erreur) ou l’absence totale d’événement est visible.	Sans corrélation temporelle, difficile de distinguer « jamais reçu » de « bloqué ».
Effet de la mise en veille	Un système en S3/S4 (Veille/Hibernation) ne traite pas l’appel ; il faut d’abord le réveiller.	Les BMC déclenchent parfois un appui « virtuel » sur le bouton ; sans réveil préalable, l’OS ne réagit pas.
Sessions actives	En présence d’utilisateurs connectés, Windows peut afficher des boîtes de dialogue « Enregistrer votre travail ». Sans interaction, l’arrêt reste bloqué.	Le comportement dépend des stratégies GPO, du temps d’attente et des apps en cours.

Comment “GracefulRestart” est censé fonctionner

Sur l’interface Redfish du BMC (iDRAC, iLO, XCC, BMC générique), l’action ComputerSystem.Reset avec ResetType=GracefulRestart signifie : demander à l’OS un redémarrage propre. Concrètement :

Le BMC accepte la requête et renvoie souvent HTTP 202 Accepted lorsqu’il a relégué la demande vers la couche gérée (OS/ACPI/agent).
L’exécution réelle dépend de l’OS : si Windows ne voit pas l’événement (machine en S3/S4, agent/ACPI non opérationnel, service bloquant), il n’y a pas de 1074 et donc pas d’arrêt.
Un vrai redémarrage propre doit laisser des traces jumelles : ID 1074 au déclenchement, puis ID 6006 (arrêt du journal) suivi de ID 6005 (démarrage du journal) après reboot.

Ce que Windows journalise (et comment le lire vite)

Usage	Événements à surveiller	Interprétation
Validation d’un arrêt propre	6006 (Event log stopped) & 6005 (Event log started)	Confirment un arrêt effectif puis une reprise du service d’événements.
Déclencheur d’arrêt/reboot	1074 (User32)	Qui/quoi a lancé la séquence : utilisateur, processus (ex. `svchost`, `shutdown.exe`), motif.
Arrêt inattendu	6008	Signale un redémarrage non prévu (crash, power off). Souvent accompagné de 41 Kernel‑Power.
Transition veille/hibernation	42 Kernel‑Power	Indique une entrée en veille/hibernation. S’il n’y a pas de 1074, la demande est probablement arrivée pendant le sommeil.
Code raison détaillé	1076	Présent quand une raison est consignée (ex. « Panne d’alimentation », « Maintenance »), utile pour différencier manuel vs. script.

Astuce visibilité : activez le mode VerboseStatus pour des traces plus bavardes pendant l’arrêt :

Clé&nbsp;: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Valeur&nbsp;: VerboseStatus (REG_DWORD) = 1

Vérification côté Redfish/BMC

202 Accepted sur POST /redfish/v1/Systems/{Id}/Actions/ComputerSystem.Reset = la commande est acceptée par le BMC, pas forcément exécutée par l’OS.
Surveillez périodiquement /redfish/v1/Systems/{Id} : la propriété Status.State (Enabled, Standby, etc.) et les informations exposées dans ResetActionInfo donnent l’état d’avancement.
Si Redfish affiche Completed mais qu’aucun 1074/6006 n’existe côté Windows, la demande n’a pas été traitée par l’OS → veille, sessions bloquantes ou couche intermédiaire manquante/défaillante.

Scénarios fréquents où la demande est ignorée

Veille / Hibernation (S3/S4) : l’OS ne reçoit pas la demande tant qu’il dort. Solution : réveil préalable (WoL, PDU, Redfish PushPowerButton), puis GracefulRestart.
Services critiques en attente (MS Failover Cluster, SQL Server en SHUTDOWN WITH NOWAIT/WAIT, sauvegarde VSS, agents EDR) : la séquence d’arrêt reste suspendue. Solution : vérifier Event Viewer > Application, systemctl équivalents Windows (services), Get-Service.
GPO qui modifient l’expérience d’arrêt (ex. « Turn off automatic restart for updates ») : peut différer les redémarrages planifiés. Solution : auditer la stratégie et tester hors GPO.
Sessions RDP déconnectées mais ouvertes : Windows considère l’utilisateur actif. Solution : fermer les sessions inactives ou imposer une stratégie de déconnexion.
Fenêtres d’applications bloquantes (fichiers non sauvegardés) : boîtes « Enregistrer/Annuler ». Solution : shutdown.exe /f en dernier recours (forçage).
Pile ACPI/agent non disponible : drivers, services ou agents d’intégration absents/gelés. Solution : valider la santé OS (services critiques actifs, pas de BSOD récent).

Méthode de corrélation fiabilisée

Pour qualifier chaque tentative de GracefulRestart, appliquez la corrélation ci‑dessous :

Redfish/BMC	Windows (événements)	Conclusion	Action recommandée
202 Accepted	1074 présent → 6006 puis 6005	Redémarrage réussi	Rien à faire, logguer l’heure & l’initiateur.
202 Accepted	Aucun 1074, présence d’un 42 Kernel‑Power	Machine endormie au moment de la demande	Réveiller → réémettre la commande.
202 Accepted	1074 absent, pas de 6006, services « long‑running »	Blocage par service/app	Clore sessions/arrêter services → retester.
Échec HTTP (4xx/5xx)	—	Commande non transmise au BMC	Corriger auth/URI/firmware BMC.
Completed	6008/41 sans 1074	Redémarrage non gracieux	Analyser crash/PowerLoss, envisager `shutdown.exe /d` pour traçabilité.

Contrôles et diagnostics “pré‑vol”

Contrôle	Commande	Attendu
Sessions actives	`quser` ou `query user`	0 session ou sessions « Disc » fermées avant reboot
Demandes de veille & blocages	`powercfg /requests`	Aucun handle bloquant
États de veille supportés	`powercfg /a`	Identifier S3/S4 activés (pour gérer le réveil)
Reboot en attente (Windows Update/CBServicing)	Voir script ci‑dessous (clés RebootPending)	Décider d’un graceful vs force
Santé journaux Système	`Get-WinEvent -LogName System -MaxEvents 1`	Pas d’erreurs « disk », « ntfs », « volmgr »

Scripts PowerShell prêts à l’emploi

1) Lecture immédiate des preuves Windows

# Dernier redémarrage demandé (User32/1074)
Get-WinEvent -LogName System -FilterHashtable @{ID=1074} -MaxEvents 1 |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message

# OS a-t-il redémarré depuis "X" ?

\$lastBoot = (Get-CimInstance Win32\_OperatingSystem).LastBootUpTime
"Dernier démarrage : \$lastBoot"

# Veille/hibernation récente ?

Get-WinEvent -LogName System -FilterHashtable @{ID=42; ProviderName='Microsoft-Windows-Kernel-Power'} -MaxEvents 5 |
Select-Object TimeCreated, Id, Message

2) Détection d’un redémarrage en attente

function Test-PendingReboot {
  $paths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired',
    'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations'
  )
  $pending = $false
  foreach ($p in $paths) { if (Test-Path $p) { $pending = $true } }
  [pscustomobject]@{ PendingReboot = $pending; CheckedPaths = ($paths -join '; ') }
}
Test-PendingReboot

3) Fermeture contrôlée des sessions RDP inactives

# Liste et fermeture (optionnelle) des sessions déconnectées depuis &gt; 2h
$query = quser 2&gt;&amp;1
$lines = $query | Select-String -Pattern 'Disc'
foreach ($l in $lines) {
  $parts = ($l -split '\s+') | Where-Object { $_ -ne '' }
  $sessionId = $parts[2]
  # Logoff si idle &gt;= 02:00 (à adapter)
  # logoff $sessionId
  &quot;Session déconnectée détectée : ID=$sessionId (simulation)&quot;
}

4) Envoi Redfish « GracefulRestart » et corrélation

Exemple générique (adapter l’URL, l’Id système et le certificat/TLS selon votre BMC) :

$BmcBase   = 'https://bmc.exemple.local'
$SystemId  = 'System.Embedded.1'
$User      = 'admin'
$Password  = 'MotDePasseTresSecret'

\$body = @{ ResetType = 'GracefulRestart' } | ConvertTo-Json

# 1) Poster la demande

try {
\$resp = Invoke-RestMethod -Method Post -Uri "\$BmcBase/redfish/v1/Systems/\$SystemId/Actions/ComputerSystem.Reset" `          -Body $body -ContentType 'application/json' -Credential (New-Object pscredential($User,(ConvertTo-SecureString $Password -AsPlainText -Force)))`
-SkipCertificateCheck
"Redfish Reset posté : \$(\$resp | Out-String)"
} catch {
Write-Warning "Echec POST Redfish : \$($\_.Exception.Message)"
return
}

# 2) Poll état côté BMC (simplifié)

for (\$i=0; \$i -lt 10; \$i++) {
Start-Sleep -Seconds 3
\$sys = Invoke-RestMethod -Method Get -Uri "\$BmcBase/redfish/v1/Systems/\$SystemId" `        -Credential (New-Object pscredential($User,(ConvertTo-SecureString $Password -AsPlainText -Force)))`
-SkipCertificateCheck
"Etat Redfish : \$(\$sys.Status.State) / PowerState=\$(\$sys.PowerState)"
}

# 3) Vérifier preuves OS

\$evt = Get-WinEvent -LogName System -FilterHashtable @{ID=1074} -MaxEvents 1
\$boot = (Get-CimInstance Win32\_OperatingSystem).LastBootUpTime
\[pscustomobject]@{
Has1074 = (\$null -ne \$evt)
Last1074 = if (\$evt) { \$evt.TimeCreated } else { \$null }
LastBoot = \$boot
}

5) Traçabilité renforcée (raison obligée)

Pour forcer une signature lisible dans les logs, déclenchez un redémarrage côté OS avec un motif explicite (utile dans vos tests comparatifs) :

shutdown.exe /r /t 0 /d p:4:1 /c &quot;Graceful Restart Test&quot;

Procédure opératoire recommandée

Réveil garanti : si la cible peut être en S3/S4, réveillez‑la (WoL, PDU, Redfish PushPowerButton), attendez 10–20 s que les services critiques reviennent.
Pré‑vol : exécutez les contrôles (sessions, powercfg /requests, reboot pending, santé journaux) et corrigez ce qui bloque.
Emission Redfish : ResetType=GracefulRestart → attendez 202 Accepted. En cas d’erreur HTTP, corrigez auth/cert/URI.
Corrélation OS : cherchez un 1074 dans les 0–2 min. Sans 1074 ? re‑vérifiez veille/sessions/services.
Validation : attendez 6006 puis 6005. Comparez à LastBootUpTime. Déclarez « succès » uniquement si ces preuves existent.
Remédiation : si la demande reste ignorée, envisagez GracefulShutdown puis On, ou ForceRestart en dernier recours (fenêtres forcées : /f).

Tableau de dépannage rapide (cause → symptôme → remède)

Cause probable	Ce que vous voyez	Remède
Veille/hibernation	202 OK, aucun 1074, événements 42 proches	Réveil puis relancer la commande
Sessions RDP ouvertes	Boîtes « Enregistrer votre travail », pas de 6006	Politiques de fermeture, `logoff` ciblé
Service longue exécution (VSS/Backup/DB)	1074 absent, journaux Application verbaux	Arrêt propre du service, fenêtre de maintenance
GPO « No auto‑restart »	Reboots planifiés différés	Ajuster GPO pour maintenance
Crash/powerloss	6008/41 sans 1074	Diagnostic matériel/driver/énergie

Bonnes pratiques de configuration

Activer VerboseStatus pour rendre l’arrêt bavard (meilleure visibilité).
Afficher le Shutdown Event Tracker sur serveurs d’intégration : encourage la saisie d’une raison (1076), utile en audit.
GPO de gestion RDP : déconnexion forcée des sessions inactives et fermeture applicative avant maintenance.
Fenêtre de maintenance : aligner sauvegardes/patching/cluster pour éviter des verrous concurrents.
Observabilité : collectez 1074/6006/6005/6008/41/42 dans votre SIEM avec corrélation par hôte et horodatage Redfish.

FAQ opérationnelle

Q : Redfish “GracefulRestart” et shutdown.exe /r sont‑ils équivalents ?
R : Pas exactement. Redfish délègue au BMC qui tente un redémarrage propre via ACPI/agent. shutdown.exe agit dans l’OS. Les traces Windows (1074/6006) restent l’unique preuve d’exécution côté OS.

Q : Pourquoi ai‑je un “202 Accepted” mais aucun redémarrage ?
R : Le BMC a accepté la requête mais l’OS n’a pas réagi (veille, sessions/applications bloquantes, couche d’intégration indisponible). Cherchez 1074 ; s’il manque, la séquence n’a pas démarré.

Q : Faut‑il forcer avec “ForceRestart” ?
R : Seulement en dernier recours. Essayez d’abord wake → graceful → vérifier → remédier. En cas d’urgence, force peut provoquer perte de données.

Exemples de rapports exploitables

Voici des gabarits de rapports que votre orchestrateur peut produire après chaque tentative de GracefulRestart :

Champ	Exemple	Comment l’obtenir
Horodatage commande Redfish	2025‑09‑17T21:43:10Z	Orchestrateur/BMC response time
HTTP status Redfish	202 Accepted	Réponse POST
OS 1074 (oui/non + heure)	Oui @ 21:43:25Z	`Get-WinEvent 1074`
6006/6005	6006 @ 21:43:55Z / 6005 @ 21:46:08Z	Journaux Système
LastBootUpTime	2025‑09‑17 21:46:02	`Get-CimInstance Win32_OperatingSystem`
Conclusion	Reboot gracieux confirmé	Règles de corrélation (table ci‑dessus)

Annexe : snippets utiles

Revenir d’une veille avant Redfish

Si votre BMC expose l’action « PushPowerButton », vous pouvez simuler une pression de bouton pour sortir de S3/S4, puis relancer GracefulRestart. Autrement, utilisez WoL ou PDU.

Nettoyage applicatif avant redémarrage

# Exemple : arrêter proprement un service critique avant le reset
$svc = 'MSSQLSERVER' # à adapter
if ((Get-Service $svc -ErrorAction SilentlyContinue)?.Status -eq 'Running') {
  Stop-Service $svc -Force -ErrorAction Stop
}

Collecte SIEM des événements clés

$ids = 1074,6006,6005,6008,41,42
Get-WinEvent -LogName System -FilterHashtable @{ID=$ids} |
  Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, MachineName, Message

Synthèse des solutions

Corréler 202 Redfish → Windows 1074. Pas de 1074 = l’OS n’a pas reçu/traité la demande → vérifier veille, sessions, services, GPO.
Surveiller 6006/6005 pour confirmer l’extinction et la reprise.
Activer VerboseStatus et consigner une raison (shutdown.exe /d … /c …) pour des audits précis.
Automatiser : script PowerShell qui interroge 1074, compare à LastBootUpTime, alerte sur délai dépassé.
Gérer les états spéciaux : réveiller avant commande, fermer les sessions RDP inactives, débloquer les services empêchant l’arrêt.

Conclusion

“Accepté” côté Redfish ne veut pas dire “exécuté” par Windows. La clé est la corrélation entre BMC et journaux OS : 1074 → 6006 → 6005. En appliquant les contrôles et scripts fournis, vous saurez en quelques minutes si la demande GracefulRestart a réellement déclenché la séquence d’arrêt Windows, pourquoi elle aurait été ignorée, et comment fiabiliser vos redémarrages sur Windows Server 2019/2022.