Objectif
Rétablir une marge de sécurité sur le disque système d’un serveur Windows tout en préservant les composants nécessaires au système et aux applications, puis corriger la cause structurelle afin d’éviter une nouvelle saturation.
Prérequis
- Accès administrateur et accès console si des services critiques risquent de s’arrêter.
- Identification des applications stockant des données sur C:.
- Sauvegarde récente ou copie des fichiers qui pourraient être déplacés/supprimés.
- Seuil de marge à retrouver défini, par exemple plusieurs Go ou un pourcentage adapté au serveur.
- Fenêtre de maintenance si un nettoyage de composants ou déplacement de données est nécessaire.
Procédure pas à pas
Mesurer l’espace libre et l’urgence
Commencez par relever la taille et l’espace restant sur tous les volumes. Notez si C: est sous un seuil critique et si la consommation continue d’augmenter. Un disque à 99 % avec croissance active doit être traité différemment d’un disque stable à 85 %. Relevez aussi l’heure des erreurs applicatives ou VSS apparues pendant la saturation.
Get-Volume | Select DriveLetter,FileSystemLabel,Size,SizeRemaining,HealthStatus
Get-PSDrive -PSProvider FileSystem | Select Name,Used,Free
- Le niveau de criticité et la marge à récupérer sont chiffrés.
Identifier les gros répertoires sans lancer un scan destructif
Analysez d’abord les emplacements classiques : profils, WindowsTemp, dumps, logs applicatifs, SoftwareDistribution, caches de produits, répertoires de sauvegarde ou exports. Utilisez un outil de taille adapté ou un inventaire PowerShell ciblé ; évitez une récursion massive sur un serveur très chargé. Pour les fichiers très volumineux, cherchez par seuil afin d’identifier rapidement les candidats.
Get-ChildItem C: -File -Force -ErrorAction SilentlyContinue | Sort Length -Descending | Select -First 20 FullName,Length
Get-ChildItem C:WindowsTemp -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum
- Les principaux consommateurs sont rattachés à un composant ou une application avant suppression.
Analyser le magasin de composants
Utilisez DISM pour mesurer le Component Store au lieu de supprimer WinSxS. AnalyzeComponentStore indique notamment si un nettoyage est recommandé. Si le serveur possède une sauvegarde et qu’aucune maintenance concurrente n’est en cours, StartComponentCleanup peut supprimer des versions remplacées de composants de manière supportée. N’utilisez pas /ResetBase sans comprendre qu’il empêche la désinstallation des mises à jour remplacées.
DISM /Online /Cleanup-Image /AnalyzeComponentStore
DISM /Online /Cleanup-Image /StartComponentCleanup
- Le magasin de composants est nettoyé uniquement par DISM et le système reste maintenable.
Utiliser le Nettoyage de disque lorsque disponible
Sur les versions supportées, Disk Cleanup peut supprimer des catégories prévues par Windows. Utilisez l’interface pour vérifier les catégories ou une exécution contrôlée. Ne cochez pas mécaniquement tous les éléments sur un serveur où des dumps et logs sont nécessaires à une investigation en cours. Conservez les preuves d’incident avant purge.
cleanmgr /d C: /LOWDISK
- Les fichiers temporaires pris en charge sont supprimés sans toucher manuellement aux composants système.
Contrôler Windows Update et les fichiers temporaires
Vérifiez si une maintenance Windows Update est bloquée ou si un téléchargement est en cours. N’effacez pas SoftwareDistribution pendant une installation active. Si une procédure de dépannage Update justifie une réinitialisation du cache, suivez la méthode Microsoft correspondante après avoir arrêté les services concernés. Pour un simple manque d’espace, préférez le nettoyage supporté et un redémarrage de maintenance.
Get-Service wuauserv,bits | Select Name,Status,StartType
Get-ChildItem C:WindowsSoftwareDistribution -Force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum
- Le cache Update n’est pas supprimé arbitrairement et les services restent cohérents.
Vérifier VSS et les shadow copies
Les shadow copies peuvent consommer une partie significative du volume. Utilisez vssadmin pour voir les associations et l’espace utilisé avant de supprimer quoi que ce soit. Une saturation VSS peut être liée à un logiciel de sauvegarde ou à une politique de clichés. Ne lancez pas delete shadows /all comme action standard : vous pourriez supprimer des points de restauration ou des snapshots utiles.
vssadmin list shadowstorage
vssadmin list shadows
- La consommation VSS est connue et toute action éventuelle est liée à une politique de sauvegarde validée.
Traiter logs, dumps et profils avec leur propriétaire
Les logs IIS, applications, antivirus/EDR, agents de sauvegarde et dumps peuvent grossir rapidement. Identifiez leur propriétaire et appliquez la rotation supportée. Pour IIS, compressez ou archivez les anciens journaux hors du volume système si la politique l’autorise. Pour les profils, utilisez la procédure de suppression de profil et non un simple rm du dossier. Déplacez les données durables vers un volume prévu.
- Les fichiers supprimés ou déplacés ont une règle de rétention claire et ne sont pas des preuves encore nécessaires.
Étendre le volume ou déplacer durablement les données
Si C: est sous-dimensionné structurellement, le nettoyage seul ne résout pas le problème. Lorsque l’infrastructure le permet, augmentez le disque virtuel puis étendez la partition, ou déplacez logs/data/cache vers un volume dédié selon les recommandations de l’application. Vérifiez sauvegarde et support éditeur avant de déplacer une base ou un répertoire système.
Get-Partition -DriveLetter C | Get-Volume
Get-Disk | Select Number,FriendlyName,Size,PartitionStyle
- Le serveur dispose d’une marge durable et les données à croissance forte ne restent pas par défaut sur C:.
Mettre en place la supervision de capacité
Après correction, définissez des seuils d’alerte et une tendance de croissance. Documentez la cause : logs sans rotation, C: trop petit, snapshots, profils, update ou fichiers temporaires. Une alerte doit laisser assez de temps pour intervenir avant 95–100 %. Ajoutez le contrôle de l’espace libre aux vérifications de sauvegarde et de patching.
- La croissance future déclenche une alerte avant que les services ne soient impactés.
Validation
La procédure est validée lorsque :
- Le volume système retrouve une marge suffisante et stable après observation.
- Windows Update, VSS et les services critiques ne signalent plus d’erreur liée à l’espace.
- Aucun fichier système critique n’a été supprimé manuellement.
- La cause de la croissance et la supervision préventive sont documentées.
Retour arrière
- Restaurer les fichiers déplacés si l’application ne fonctionne plus et si le chemin n’a pas été reconfiguré correctement.
- Ne tentez pas de restaurer manuellement des composants WinSxS supprimés hors DISM ; utilisez DISM/SFC ou la sauvegarde système.
- Si une extension de volume échoue, arrêter la modification et vérifier le stockage sous-jacent avant toute opération de partition.
- Réactiver les politiques de logs ou services désactivés temporairement dès la fin du nettoyage.
Dépannage / erreurs fréquentes
- L’espace se remplit à nouveau immédiatement : rechercher un fichier/log en croissance active avec son processus propriétaire.
- DISM cleanup échoue : contrôler l’intégrité du magasin, les opérations en attente et l’espace minimal disponible.
- VSS utilise beaucoup d’espace : identifier le logiciel qui crée les clichés avant de les purger.
- Cleanmgr libère peu d’espace : le vrai consommateur est probablement applicatif, profil, dump ou données hors catégories Windows.
- Le serveur est déjà à 100 % et les services tombent : libérer d’abord un petit volume de fichiers non critiques clairement identifiés, puis appliquer la procédure normale.