Planifier un redémarrage différé sur un serveur de production ne doit plus être une source de stress : en adoptant quelques vérifications clés et les bons automatismes, vous garantissez que vos VM ou nœuds physiques ne redémarrent qu’au moment voulu, même lorsque Windows Update lance des surprises.
Redémarrage différé après l’installation de mises à jour Windows Server
Vue d’ensemble de la question
Un administrateur a appliqué une série de correctifs via Windows Update. La boîte de dialogue proposait « Redémarrer maintenant » ou « Planifier le redémarrage ». Après avoir retenu la seconde option et choisi un créneau deux jours plus tard, trois interrogations subsistent :
- Doit‑il s’attendre à un redémarrage exactement au créneau choisi ou bien en dehors des heures d’activité ?
- Pourquoi Windows continue‑t‑il d’exiger un redémarrage alors que certaines mises à jour se sont affichées « Échec » ?
- Comment reprogrammer le redémarrage lorsqu’aucune option graphique n’apparaît plus ?
Réponses & solutions condensées
| Problème | Solution pratique | Points clefs |
|---|---|---|
| Comportement du redémarrage différé | La planification crée une tâche (souvent nommée Reboot_AC Power) dans Planificateur de tâches → Microsoft → Windows → UpdateOrchestrator. Tant que la tâche existe et reste active, le serveur redémarre à la minute près indiquée. Si cette tâche est supprimée, bloquée par une GPO (No auto‑restart with logged‑on users, Always schedule restart) ou qu’un utilisateur reste connecté, Windows bascule vers le prochain créneau hors heures d’activité. | Vérifier l’état de la tâche.Contrôler les stratégies locales/GPO.Confirmer la plage « heures d’activité ». |
| Erreur d’installation mais demande de redémarrage | Un échec sur un KB n’annule pas forcément l’ensemble ; d’autres packages sont en phase Pending et exigent un redémarrage pour finaliser. Tant qu’ils restent en attente, Windows signale « Redémarrage nécessaire ». | Consulter WindowsUpdate.log et le journal Event Viewer → WindowsUpdateClient.Relancer le KB fautif.S’assurer de la place libre (≥ 15 % sur C:).Exécuter DISM /Online /Cleanup-Image /RestoreHealth puis sfc /scannow. |
| Reprogrammer le redémarrage | Quand l’option graphique a disparu : Interface : Paramètres → Windows Update → Options de redémarrage (ou sconfig en Server Core).PowerShell : (exemple ci‑dessous) créer ou modifier la tâche planifiée. GPO : Configuration ordinateur → Modèles d’administration → Composants Windows → Windows Update → Redémarrage automatique planifié. | Le module PSWindowsUpdate permet aussi Invoke-WUReboot pour forcer ou replanifier. |
Script PowerShell de planification rapide
$trigger = New-ScheduledTaskTrigger -Once -At "03/03/2024 02:00"
$action = New-ScheduledTaskAction -Execute "shutdown.exe" -Argument "/r /t 0"
Register-ScheduledTask -TaskName "PlannedReboot" -Trigger $trigger -Action $action -User "SYSTEM" -RunLevel Highest
Le script ci‑dessus enregistre une tâche qui redémarrera le serveur en mode silencieux à la date/heure spécifiée, sans dépendre du service Windows Update. Quelques variations utiles :
-At (Get-Date).AddHours(6)pour décaler automatiquement de six heures.-Execute "powershell.exe" -Argument "-NoProfile -WindowStyle Hidden Restart-Computer -Force"pour rester 100 % PowerShell.- Ajouter
-Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries)sur un hôte Hyper‑V portable.
Cycle de vie détaillé d’une mise à jour Windows Server
Comprendre l’état « Pending Reboot » est capital. Lorsqu’un package CAB ou MSI est téléchargé, il passe par :
- Staging : le fichier est décompressé sous
%windir%\SoftwareDistribution\Download. - Install : la table du manifeste (CBS) inscrit la mise à jour dans le registre, copie les binaires dans
%windir%\WinSxSpuis marque « Pending File Rename » en cas d’élément verrouillé. - Commit (au redémarrage) : pendant la phase de démarrage, TrustedInstaller remplace les fichiers protégés et met à jour l’inventaire des composants.
Un échec au stade 2 déclenche l’erreur 0x8024xxxx (échec d’installation) mais n’annule pas les autres packages déjà passés en état « Pending ». D’où l’alerte de redémarrage malgré un résultat « semi‑échec ».
Diagnostic avancé avec les journaux et outils natifs
- WindowsUpdate.log : sous Windows Server 2022+, exécutez
Get-WindowsUpdateLogpour regénérer le fichier lisible. Recherchez « Reboot required = True » ou « Error 0x800f0922 » (manque d’espace dans la partition de récupération). - Event ID 19, 20, 21 dans Setup API signalent les étapes Install/Commit.
- Dism.exe /Get-Packages /State:Pending liste les paquets bloqués.
- Reliability Monitor (
perfmon /rel) offre une vue chronologique claire (courbe rouge) des arrêts système et des échecs de patch.
Gestion des heures d’activité et politiques de redémarrage
Les heures d’activité (« Active Hours ») définissent la fenêtre pendant laquelle Windows évite un redémarrage automatique. Sur un serveur d’applications, fixez‑les à la plage des pics utilisateurs. En PowerShell :
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" `
-Name ActiveHoursStart -Value 8 # 08h00
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" `
-Name ActiveHoursEnd -Value 20 # 20h00
Si vous gérez un parc entier, privilégiez une GPO combinant :
- Turn off auto-restart for updates during active hours.
- Specify active hours range (Windows Server 2019+).
Automatisation sur un cluster : Cluster‑Aware Updating (CAU)
Sur un cluster Hyper‑V ou SQL FCI, laissez CAU orchestrer la mise hors ligne d’un nœud, son patch, le redémarrage, puis sa réintégration avant de passer au suivant. Points de vigilance :
- Valider la stratégie de drainage des rôles (Live Migration ou Move‑Group).
- Surveiller le quorum ; les redémarrages successifs ne doivent pas descendre sous le seuil.
- Tester le scénario de bascule avec un patch fictif (
/simulate).
Surveillance et reporting après patch
Une fois la fenêtre de maintenance terminée :
- Exécutez
Get-WinEvent -LogName System -FilterXPath "*[System[EventID=1074]]"pour confirmer la source « Windows Update » et l’heure du redémarrage. - Récupérez le journal de fiabilité (
perfmon /rel /report) pour l’archiver. - Automatisez l’étape dans votre pipeline Ansible/Puppet : après l’appel
win_updates, ajoutez une tâche de collecte des IDs 19‑21 et 1074.
FAQ rapide
La tâche « Reboot_AC Power » a disparu ; dois‑je recréer manuellement ?
Oui. Si un outil de nettoyage l’a supprimée, recréez‑la avec le script PowerShell ci‑dessus ou lancez UsoClient RestartDevice pour laisser Windows la régénérer.
Que se passe‑t‑il si un utilisateur reste connecté via RDP ?
Si la GPO No auto‑restart with logged‑on users est activée, Windows reporte le redémarrage jusqu’à la déconnexion ou jusqu’à la fin des heures d’activité, puis affiche un compte à rebours.
Comment identifier rapidement la mise à jour bloquante ?
Dism /Online /Cleanup-Image /AnalyzeComponentStore révèle la taille des paquets en attente. Le plus volumineux ou le plus récemment ajouté est souvent la cause.
Checklist opérationnelle avant validation de la fenêtre de maintenance
- 15 % d’espace libre sur C:
- Snapshots Hyper‑V/VMware pris, puis purgés après succès.
- Firmware/BIOS à jour pour éviter code d’erreur 0x800f0845.
- Exclusion antivirus sur
%windir%\SoftwareDistribution. - Journal d’exécution PSWindowsUpdate exporté (
Get-WindowsUpdateLog -Confirm:$false). - Notification Teams ou e‑mail via webhook pour indiquer « Patch + reboot OK ».
Conclusion
Grâce à l’observation de la tâche planifiée, à l’analyse des journaux CBS et à la maîtrise des scripts PowerShell, vous conservez un contrôle total sur le moment où un serveur Windows applique et finalise ses mises à jour, même après qu’un redémarrage différé a été choisi plusieurs jours à l’avance. En ajoutant de l’automatisation (CAU, PSWindowsUpdate, GPO) et des vérifications préalables (espace disque, cluster, antivirus), vous mettez fin aux redémarrages intempestifs et améliorez la disponibilité du service.