RCA — Panne infrastructure causée par un script SCCM sur le nœud de stockage actif
Analyse post-mortem d'une panne infrastructure complète causée par l'exécution d'un script SCCM redémarrant WMI sur le nœud de stockage SAN actif.
Table des matières
Une panne de 45 minutes affectant l’ensemble des VMs d’une infrastructure VMware. Cause : un script de remédiation SCCM s’exécutant sur le mauvais serveur. Retour d’expérience complet.
Toutes les VMs inaccessibles pendant 45 minutes. Le stockage iSCSI était indisponible — les VMs ne pouvaient ni lire ni écrire sur leurs datastores.
Chronologie
| Heure | Événement |
|---|---|
| H+00 | Premières alertes monitoring — VMs inaccessibles |
| H+02 | Constat : datastores VMware indisponibles |
| H+05 | Identification : nœud SAN actif en erreur |
| H+12 | Redémarrage manuel du service SAN |
| H+19 | Récupération progressive des datastores |
| H+45 | Toutes les VMs opérationnelles |
| H+90 | Début de l’investigation RCA |
Architecture
Nœud SAN ACTIF (Windows Server)
│ Miroir synchrone iSCSI
Nœud SAN PASSIF (Windows Server)
│
└── Datastores VMware (présentés via iSCSI)
└── ~80 VMs
Le SAN software utilise une architecture active/passive avec basculement automatique censé tolérer la panne d’un nœud.
Cause racine
Un script PowerShell déployé via SCCM pour la remédiation d’une politique de conformité a redémarré le service WMI et l’agent SCCM sur les serveurs Windows du parc.
Ce script s’est exécuté sur le nœud SAN actif :
# Script de remédiation SCCM — déployé en production sans exclusions
Stop-Service winmgmt -Force
Start-Sleep 5
Start-Service winmgmt
Restart-Service CcmExec
Cascade de défaillances :
- WMI redémarré → le service SAN perd sa capacité de monitoring interne
- Le SAN détecte une anomalie et tente un basculement vers le nœud passif
- Le basculement échoue (nœud passif pas prêt à prendre la main immédiatement)
- Les cibles iSCSI deviennent indisponibles
- VMware perd l’accès au stockage → toutes les VMs passent en état d’erreur
Investigation
# Corrélation temporelle dans les logs SCCM
Get-WinEvent -LogName "Microsoft-Windows-SoftwareCenter/Operational" |
Where-Object { $_.TimeCreated -gt (Get-Date).AddHours(-3) } |
Select-Object TimeCreated, Message |
Format-List
# Logs SAN autour de l'incident
Get-WinEvent -LogName "Application" |
Where-Object {
$_.TimeCreated -gt "2026-04-13 14:00" -and
$_.Source -like "*SAN*"
} |
Select-Object TimeCreated, LevelDisplayName, Message |
Format-Table -Wrap
Les logs confirment la corrélation exacte entre le redémarrage SCCM de WMI et la détection d’anomalie par le SAN.
Résolution immédiate
# Sur le nœud SAN — redémarrer le service SAN Executive
Restart-Service "SAN-Service-Name"
# Vérifier l'état des miroirs depuis la console SAN
# Forcer la resynchronisation si nécessaire
Côté VMware, les datastores se remontent automatiquement une fois le stockage disponible. Un rescan des HBA a été nécessaire sur certains hosts ESXi.
Mesures correctives
1. Exclusion des serveurs critiques du périmètre SCCM
Collection SCCM : "Serveurs Exclus — Infrastructure Critique"
Règle d'exclusion appliquée à tous les déploiements de remédiation
Membres :
- Nœuds SAN (actif + passif)
- Serveurs vCenter
- Hosts ESXi
- Contrôleurs de domaine
2. Procédure de validation avant déploiement
- Test sur VM isolée avant tout déploiement de remédiation
- Revue par un second administrateur pour les scripts touchant des services système
- Liste rouge des services interdits à redémarrer via SCCM sans validation :
winmgmt(WMI)CcmExec(agent SCCM)- Tout service de stockage/SAN
- Tout service de clustering
3. Monitoring renforcé
Alertes configurées sur :
- État des services SAN (seuil : indisponible > 30 secondes)
- Latence I/O iSCSI > 10ms
- État des miroirs SAN (synchronisé/désynchronisé)
4. Test de basculement trimestriel
Procédure de basculement SAN documentée et testée tous les trimestres en fenêtre de maintenance, pour valider que le nœud passif prend bien la main.
Leçons apprises
Tout script SCCM doit avoir une liste d’exclusions explicite. Ne jamais supposer qu’un script ‘sans danger’ ne touchera pas les serveurs d’infrastructure critique.
- La HA ne protège pas contre tout : un basculement simultané des deux nœuds (même involontaire) annule la haute disponibilité
- Les scripts de conformité sont dangereux : ils s’appliquent à toute la collection sans discrimination
- La corrélation temporelle est la clé du RCA : comparer les timestamps SCCM, SAN et VMware a permis l’identification en moins d’une heure
Conclusion
45 minutes de panne, plusieurs centaines d’utilisateurs impactés, causés par 4 lignes de PowerShell sans exclusions. Ce type d’incident est évitable avec une segmentation SCCM rigoureuse et une procédure de validation des scripts avant déploiement à grande échelle.
Comments