Trouver et supprimer les anciennes mises à jour Windows (en toute sécurité) avec PowerShell

Comment les mises à jour Windows consomment réellement de l’espace

Quand on dit « les mises à jour Windows prennent de la place », on veut généralement dire l’une des quatre choses suivantes :

• Le magasin de composants (WinSxS) : le vrai poids lourd. Il stocke des composants et plusieurs versions pour le servicing et le rollback. On ne peut pas le « supprimer » parce qu’il est intriqué avec le servicing stack.
• Le cache de mise à jour (généralement C:\Windows\SoftwareDistribution\Download) : téléchargements et staging transitoires. Généralement sûr à vider si vous arrêtez d’abord les services.
• Le cache Delivery Optimization : mise en cache pair-à-pair et locale pour le contenu Windows Update. Utile sur des flottes, pénible sur des serveurs uniques avec des volumes système petits.
• Les anciens artefacts d’OS comme Windows.old après des upgrades de fonctionnalité (plus orienté poste client, mais ça apparaît aussi sur des serveurs après des mises à niveau in-place).

La nuance opérationnelle clé : l’utilisation disque n’est pas la même chose que l’espace récupérable. WinSxS peut sembler énorme, mais une grosse partie est hardlinkée dans le système et les applications. Supprimer la « mauvaise » chose ne réduira pas l’utilisation — et peut casser le servicing.

Donc le flux de travail est : mesurer correctement, identifier le compartiment concerné, choisir le mécanisme de nettoyage le moins risqué (privilégier les outils de servicing intégrés), et valider avec les logs et un cycle de mise à jour post-nettoyage.

Playbook de diagnostic rapide

Quand le disque C: hurle et que vous avez besoin de réponses vite, n’allez pas fouiller à l’aveugle. Faites cette séquence :

1) Confirmer que le problème est réel et local

• Vérifiez l’espace libre et le taux de croissance. Si le disque est un LUN thin-provisioned, confirmez qu’il ne s’agit pas d’une panique côté stockage déguisée en « mises à jour Windows ».
• Confirmez quel volume est impacté : volume OS, volume de données, ou une partition de récupération minuscule à laquelle quelqu’un a attribué une lettre (oui, ça arrive).

2) Identifier le répertoire consommant le plus

• Est-ce WinSxS ? SoftwareDistribution ? Un dossier de dump ? Des logs ? Une application qui tourne sans contrôle ? Vous ne pouvez pas réparer ce que vous refusez de mesurer.

3) Décider de la voie de nettoyage

• Si WinSxS est volumineux : utilisez le nettoyage du magasin de composants DISM. Ne supprimez pas manuellement.
• Si SoftwareDistribution est gros : arrêtez les services, videz le cache, redémarrez les services.
• Si Delivery Optimization est volumineux : videz le cache DO et ajustez la stratégie.
• Si Windows.old existe : supprimez via des outils de nettoyage supportés, pas via l’Explorateur.

4) Valider la santé du servicing avant et après

• Exécutez des vérifications DISM. Si le magasin de composants est corrompu, le nettoyage ne se passera pas comme prévu.
• Après le nettoyage, lancez un cycle de détection/installation de mises à jour (ou au moins un scan) pour confirmer que vous n’avez pas cassé Windows Update.

Faits intéressants et contexte historique (pour arrêter de deviner)

1. WinSxS n’est pas un « cache ». C’est le magasin de composants de servicing introduit pour résoudre le « DLL hell » et permettre un servicing fiable. Il est destiné à être volumineux.
2. Explorer « ment » (en quelque sorte) sur la taille de WinSxS. Beaucoup de fichiers sont hardlinkés ; les compter séparément donne l’impression que le dossier est plus gros que la consommation réelle du disque.
3. DISM a remplacé les anciens outils de servicing. La montée de DISM reflète le passage de Windows à un servicing basé sur les composants à travers les éditions et rôles.
4. Les mises à jour cumulatives ont changé le jeu du nettoyage. Les rollups mensuels et les mises à jour cumulatives réduisent la fragmentation des correctifs, mais peuvent augmenter temporairement l’espace de staging et de rollback.
5. Les Servicing Stack Updates (SSU) existent parce que le servicing a besoin d’être maintenu. Si vous cassez le stack, les mises à jour deviennent peu fiables ou impossibles.
6. Windows Update utilise plusieurs services. Vider les caches sans arrêter les services laisse des fichiers verrouillés et des résultats incohérents — comme essayer de changer un pneu en roulant.
7. Delivery Optimization a été conçu pour l’efficacité de la bande passante. Sur un serveur unique, il se comporte souvent comme une taxe disque que vous n’avez pas approuvée.
8. Le nettoyage du magasin de composants peut supprimer la capacité de désinstallation. Certains modes de nettoyage suppriment volontairement les composants supersédés ; c’est une décision de risque, pas un bouton « espace libre ».
9. Les anciennes mises à jour persistent souvent pour garantir le rollback. Le système conserve ce dont il a besoin pour revenir sur un mauvais patch ou satisfaire les graphes de dépendances.

Un modèle de sécurité : ce qui est sûr à supprimer vs. ce qui ne l’est pas

Traçons une ligne entre « sûr avec procédure » et « limitant pour la carrière ».

Généralement sûr (si vous suivez les bonnes étapes)

• Cache de téléchargement SoftwareDistribution (arrêtez d’abord les services WU). Vous supprimez des installateurs téléchargés et du contenu temporaire, pas des mises à jour installées.
• Cache Delivery Optimization (vider via cmdlets/réglages supportés). Vous supprimez des payloads mis en cache, pas des composants système.
• Fichiers temporaires et logs CBS (avec politique de rétention). Les logs ne sont pas sacrés ; ils sont utiles tant qu’on peut encore en écrire de nouveaux.
• Windows.old (après avoir confirmé que vous ne ferez pas de rollback). Utilisez les outils de nettoyage pour éviter des problèmes d’autorisations et de reparse points.

Sûr uniquement via des outils de servicing (DISM), pas par suppression

• WinSxS/magasin de composants. Utilisez les opérations d’analyse/nettoyage de DISM. La suppression manuelle est la voie d’un système qui « fonctionne » jusqu’à la prochaine fenêtre de patch.

Ne touchez pas à moins d’aimer les pannes étranges

• C:\Windows\WinSxS élagage manuel. Non.
• C:\Windows\Installer nettoyage sans outil d’inventaire MSI. Supprimer des fichiers MSI/MSP au hasard casse la réparation/la désinstallation et parfois les upgrades.
• Bidouilles du registre pour « désactiver les mises à jour » comme stratégie d’espace. Ce n’est pas un nettoyage ; c’est de la dette technique.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : Tout échoue ; concevez et opérez comme si l’échec était la norme. Cela inclut vos scripts de nettoyage — supposez des interruptions, des redémarrages et des opérations à moitié finies.

Blague #1 : Supprimer des choses au hasard dans C:\Windows revient à « optimiser » un parachute en enlevant des sangles — techniquement plus léger, opérationnellement excitant.

Tâches pratiques (commandes, sorties, décisions)

Voici des tâches réelles que vous pouvez exécuter en administrateur. Chacune contient : une commande, ce que signifie la sortie, et la décision à prendre.

Remarque sur les blocs de code : Le format d’invite ci-dessous montre une étiquette ressemblant à une invite Linux, mais les commandes sont des commandes PowerShell Windows et s’exécuteront dans PowerShell. C’est une contrainte de format, pas un choix de style de vie.

Tâche 1 : Vérifier l’espace libre sur tous les volumes (baseline)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object DriveLetter | Select DriveLetter,FileSystemLabel,SizeRemaining,Size | Format-Table -Auto"
DriveLetter FileSystemLabel SizeRemaining        Size
----------- -------------- -------------        ----
C           OS             18.42 GB      127.99 GB
D           Data           512.10 GB     1023.99 GB

Ce que cela signifie : Confirme que la pression est sur C:, pas sur un volume de données. Vous savez aussi si vous avez « seulement 18 Go restants » (gérable) ou « 300 Mo restants » (triage urgent).

Décision : Si C: est en dessous de ~5–10 % libre, évitez les opérations longues qui créent des fichiers temporaires (y compris certaines installations de mises à jour) jusqu’à ce que vous récupériez de l’espace.

Tâche 2 : Identifier rapidement les plus gros consommateurs (sans outils tiers)

cr0x@server:~$ powershell -NoProfile -Command "$paths='C:\Windows\WinSxS','C:\Windows\SoftwareDistribution','C:\Windows\Temp','C:\Windows\Logs','C:\ProgramData\Microsoft\Windows\DeliveryOptimization'; foreach($p in $paths){ if(Test-Path $p){ $bytes=(Get-ChildItem $p -Force -ErrorAction SilentlyContinue -Recurse | Measure-Object -Property Length -Sum).Sum; [pscustomobject]@{Path=$p;GB=[math]::Round($bytes/1GB,2)} } } | Sort-Object GB -Descending | Format-Table -Auto"
Path                                                        GB
----                                                        --
C:\Windows\WinSxS                                          12.84
C:\Windows\SoftwareDistribution                             6.10
C:\ProgramData\Microsoft\Windows\DeliveryOptimization        3.45
C:\Windows\Logs                                             1.12
C:\Windows\Temp                                             0.78

Ce que cela signifie : Vous obtenez une vue directionnelle rapidement. Le chiffre WinSxS ici est une somme naïve (les hardlinks peuvent le gonfler), mais SoftwareDistribution/DO sont plus proches du « réel ».

Décision : Si SoftwareDistribution et DO sont volumineux, vous pouvez souvent récupérer de l’espace avec un risque minimal avant de toucher au nettoyage du magasin de composants.

Tâche 3 : Obtenir la vraie taille récupérable du magasin de composants (analyse DISM)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /AnalyzeComponentStore"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
Component Store (WinSxS) information:

Windows Explorer Reported Size of Component Store : 12.8 GB
Actual Size of Component Store : 8.9 GB
Shared with Windows : 6.7 GB
Backups and Disabled Features : 1.9 GB
Cache and Temporary Data : 0.3 GB

Date of Last Cleanup : 2025-12-02 03:12:44
Number of Reclaimable Packages : 4
Component Store Cleanup Recommended : Yes
The operation completed successfully.

Ce que cela signifie : « Actual Size » est plus proche de la consommation réelle du disque. « Number of Reclaimable Packages » et « Cleanup Recommended » vous indiquent si DISM anticipe des gains significatifs.

Décision : Si le nettoyage est recommandé, planifiez un nettoyage du magasin de composants pendant une fenêtre de maintenance, car cela peut être intensif en CPU/disque et demander un redémarrage.

Tâche 4 : Valider que le magasin de composants est sain avant nettoyage (scan DISM)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /ScanHealth"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
No component store corruption detected.
The operation completed successfully.

Ce que cela signifie : Vous êtes moins susceptible de rencontrer des échecs bizarres pendant le nettoyage ou les mises à jour futures.

Décision : Si une corruption est détectée, priorisez la réparation (/RestoreHealth) avant de commencer à supprimer des caches. Corruption + nettoyage = machines impossibles à patcher.

Tâche 5 : Réparer le servicing si nécessaire (DISM restore health)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /RestoreHealth"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
The restore operation completed successfully.
The operation completed successfully.

Ce que cela signifie : DISM a réparé le magasin de composants en utilisant des sources locales ou Windows Update.

Décision : Si DISM ne trouve pas de sources, vous aurez besoin d’une source alternative (ISO monté ou source de réparation configurée). Ne procédez pas au « nettoyage » si le magasin est cassé ; vous ne ferez qu’aggraver la prochaine mise à jour.

Tâche 6 : Effectuer un nettoyage sûr du magasin de composants (mode recommandé)

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /StartComponentCleanup"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
The operation completed successfully.

Ce que cela signifie : Supprime les composants supersédés lorsque c’est sûr. C’est le mode de nettoyage « normal » qui garde le système supportable.

Décision : Utilisez cela en premier. C’est le meilleur compromis entre espace récupérable et maintien des chemins de rollback pour les mises à jour récentes.

Tâche 7 : Le mode agressif (avec conséquences) : reset base

cr0x@server:~$ powershell -NoProfile -Command "dism.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase"
Deployment Image Servicing and Management tool
Version: 10.0.17763.1

Image Version: 10.0.17763.5329

[===========================100.0%===========================]
The operation completed successfully.

Ce que cela signifie : Supprime la possibilité de désinstaller les mises à jour supersédées. Vous vous engagez sur la base actuelle.

Décision : Ne faites cela que lorsque (a) vous avez une forte confiance dans la stabilité des patches, (b) vous avez testé les plans de rollback (snapshots VM, images ou rebuild rapide), et (c) la pression disque est chronique. Ce n’est pas une activité « vendredi après-midi ».

Tâche 8 : Vérifier s’il y a un redémarrage en attente (avant d’interpréter les résultats)

cr0x@server:~$ powershell -NoProfile -Command "$p=@(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
); $p | ForEach-Object { [pscustomobject]@{Key=$_;Exists=Test-Path $_} } | Format-Table -Auto"
Key                                                                                               Exists
---                                                                                               ------
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending           False
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired         True

Ce que cela signifie : Un redémarrage en attente peut empêcher le nettoyage de se finaliser et garder l’espace disque captif.

Décision : Si un redémarrage est en attente, planifiez-le. Beaucoup de plaintes « le nettoyage n’a pas fonctionné » signifient en réalité « le nettoyage attend un redémarrage ».

Tâche 9 : Mesurer la taille du cache SoftwareDistribution et décider s’il faut le vider

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\Windows\SoftwareDistribution\Download'; $bytes=(Get-ChildItem $p -Force -ErrorAction SilentlyContinue -Recurse | Measure-Object Length -Sum).Sum; [pscustomobject]@{Path=$p;GB=[math]::Round($bytes/1GB,2);Files=(Get-ChildItem $p -Force -Recurse -ErrorAction SilentlyContinue | Measure-Object).Count} | Format-List"
Path  : C:\Windows\SoftwareDistribution\Download
GB    : 5.86
Files : 1432

Ce que cela signifie : C’est généralement récupérable, surtout si les fichiers sont anciens et que les mises à jour sont déjà installées.

Décision : Si c’est plusieurs Go et que vous avez besoin d’espace maintenant, videz-le en toute sécurité (tâche suivante). Attendez-vous à ce que Windows retélécharge ce dont il a besoin par la suite.

Tâche 10 : Vider SoftwareDistribution en toute sécurité (arrêter services, supprimer, démarrer)

cr0x@server:~$ powershell -NoProfile -Command "Stop-Service wuauserv,bits,cryptsvc -Force; Start-Sleep 2; Remove-Item 'C:\Windows\SoftwareDistribution\Download\*' -Recurse -Force -ErrorAction SilentlyContinue; Start-Service cryptsvc,bits,wuauserv; Get-Service wuauserv,bits,cryptsvc | Select Name,Status | Format-Table -Auto"
Name      Status
----      ------
wuauserv   Running
bits      Running
cryptsvc  Running

Ce que cela signifie : Les services sont redémarrés et le cache de téléchargement est vidé. Si des fichiers étaient verrouillés, certains peuvent rester ; c’est acceptable si le gros a disparu.

Décision : Re-vérifiez l’espace libre. Si vous avez récupéré suffisamment, arrêtez-vous ici. N’enchaînez pas des opérations risquées si la victoire facile a résolu le problème.

Tâche 11 : Inspecter le cache Delivery Optimization et le vider

cr0x@server:~$ powershell -NoProfile -Command "Get-DeliveryOptimizationStatus | Select-Object -First 3 | Format-List"
SourceURL            : 
FileSize             : 0
BytesFromCacheServer : 0
BytesFromPeers       : 0
BytesFromHttp        : 0
Status               : Idle

Ce que cela signifie : Le statut n’affiche pas directement la taille du cache ; il concerne plutôt les transferts en cours. Pour la taille du cache, mesurez le répertoire et/ou utilisez les paramètres de nettoyage.

Décision : Si le dossier DO est volumineux et que vous ne tirez pas parti du peer caching sur des serveurs, videz-le et envisagez de limiter via la stratégie.

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache'; if(Test-Path $p){ $bytes=(Get-ChildItem $p -Force -ErrorAction SilentlyContinue -Recurse | Measure-Object Length -Sum).Sum; [pscustomobject]@{Path=$p;GB=[math]::Round($bytes/1GB,2)} } | Format-List"
Path : C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache
GB   : 3.31

cr0x@server:~$ powershell -NoProfile -Command "Remove-Item 'C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache\*' -Recurse -Force -ErrorAction SilentlyContinue; 'cache-cleared'"
cache-cleared

Ce que cela signifie : Le cache est supprimé. Il se re-remplira si DO reste activé et que des mises à jour ont lieu.

Décision : Si cela revient sans cesse, imposez un plafond par politique plutôt que d’exécuter un job de suppression quotidien qui se battra contre l’OS.

Tâche 12 : Trouver les mises à jour installées et leurs dates d’installation (pour les décisions de rollback)

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID,InstalledOn,Description | Format-Table -Auto"
HotFixID  InstalledOn Description
--------  ----------- -----------
KB5034121 12/12/2025  Update
KB5033371 11/15/2025  Security Update
KB5032007 10/10/2025  Security Update

Ce que cela signifie : Vue rapide de l’activité de patch récente. Pas parfaite pour tous les types de mises à jour, mais utile comme lentille opérateur.

Décision : Si le dernier patch est très récent et que vous êtes en période de « monitoring », évitez /ResetBase jusqu’à ce que vous soyez sûr de ne pas avoir besoin d’un chemin de désinstallation.

Tâche 13 : Confirmer que les services Windows Update ne se répètent pas (le nettoyage peut masquer de vrais problèmes)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service wuauserv,bits,DoSvc | Select Name,StartType,Status | Format-Table -Auto"
Name    StartType Status
----    --------- ------
wuauserv Manual    Running
bits    Manual    Running
DoSvc   Manual    Running

Ce que cela signifie : Les services sont dans des états attendus. S’ils sont Disabled, quelqu’un a « résolu » les mises à jour en les désactivant.

Décision : Si Disabled de manière inattendue, corrigez la politique/le paramètre. Vider les caches n’aidera pas si le moteur de mise à jour est mort.

Tâche 14 : Valider les fichiers système (SFC) lorsque les mises à jour se comportent de façon étrange

cr0x@server:~$ powershell -NoProfile -Command "sfc.exe /scannow"
Beginning system scan.  This process will take some time.
Beginning verification phase of system scan.
Verification 100% complete.
Windows Resource Protection did not find any integrity violations.

Ce que cela signifie : L’intégrité est bonne. S’il rapporte des réparations, cela peut expliquer des échecs de mise à jour et des variations d’activité disque.

Décision : Si SFC trouve des corruptions de façon répétée, vous avez un problème plus profond (stockage, AV, pipeline d’image défectueux). Ne camouflez pas ça avec des scripts de nettoyage.

Tâche 15 : Mesurer avant/après et consigner le delta (parce que les humains oublient)

cr0x@server:~$ powershell -NoProfile -Command "$before=(Get-Volume -DriveLetter C).SizeRemaining; dism.exe /Online /Cleanup-Image /StartComponentCleanup | Out-Null; $after=(Get-Volume -DriveLetter C).SizeRemaining; [pscustomobject]@{BeforeGB=[math]::Round($before/1GB,2);AfterGB=[math]::Round($after/1GB,2);FreedGB=[math]::Round(($after-$before)/1GB,2)} | Format-List"
BeforeGB : 18.42
AfterGB  : 21.07
FreedGB  : 2.65

Ce que cela signifie : Le nettoyage a récupéré de l’espace maintenant, pas « peut-être plus tard ». S’il n’a rien libéré, vous avez appris quelque chose sans deviner.

Décision : Utilisez le delta pour choisir les actions suivantes : vider des caches, déplacer des logs, étendre le disque, ou changer le rythme de patching.

Trois mini-histoires du monde corporate (et leurs enseignements)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une grande application métier interne a commencé à échouer aux contrôles de santé après le Patch Tuesday. Elle n’était pas complètement tombée ; elle était « en partie fonctionnelle », ce qui est le type de panne le plus long à résoudre. Certains nœuds de la pool allaient bien, d’autres étaient en boucle de redémarrage pendant la maintenance, et l’on-call voyait le load balancer s’appauvrir lentement en cibles saines.

La cause racine n’était pas la mise à jour elle-même. C’était le nettoyage : un ingénieur a supposé que le dossier WinSxS était « juste de vieilles mises à jour » et a poussé un script supprimant « de grands sous-dossiers sous C:\Windows » pour récupérer de l’espace. Ça a marché sur quelques serveurs non critiques, donc c’est devenu la « norme ». Puis ça a frappé des systèmes en plein servicing.

Les machines ne sont pas mortes immédiatement. Là est le piège. Elles ont tourné jusqu’à ce que la prochaine mise à jour cumulative tente de mettre en scène des composants et de concilier les dépendances. Le servicing a échoué, les rollbacks se sont appliqués partiellement, et les nœuds avaient maintenant des états de composants désynchronisés. La boucle de redémarrage n’était pas un écran bleu classique ; c’était Windows essayant de terminer des opérations de servicing échouées et perdant le combat.

La réparation n’a pas été sophistiquée : restauration depuis des snapshots connus bons pour les pires nœuds, et pour les sauvables, réparation du magasin de composants avec DISM et réapplication des mises à jour dans une fenêtre contrôlée. La politique de « nettoyage » a été remplacée par une règle ennuyeuse : si vous voulez réduire WinSxS, vous utilisez DISM, ou vous ne le touchez pas.

Leçon : La mauvaise hypothèse porte généralement sur ce que représente un répertoire. Dans le servicing Windows, les dossiers ne sont pas que des dossiers. Ce sont des contrats.

Mini-histoire 2 : L’optimisation qui s’est retournée contre son auteur

Une autre entreprise avait une flotte de VM Windows Server avec de petits disques système. Quelqu’un a été proactif et a créé une tâche planifiée : chaque nuit, elle arrêtait les services Windows Update, vidait SoftwareDistribution, vidait le cache Delivery Optimization, exécutait DISM cleanup, puis redémarrait. Les graphiques disques semblaient magnifiques. L’ingénieur a été félicité pour « garder les serveurs propres ».

Puis la conformité aux patches a commencé à chuter. Les mises à jour prenaient plus de temps. Certains serveurs rataient leur fenêtre de maintenance parce qu’ils passaient la première moitié à retélécharger du contenu qu’ils venaient de jeter. La bande passante sur quelques sites a explosé juste au moment où les jobs nocturnes s’exécutaient. L’équipe WAN est intervenue, ce qui n’est jamais une réunion amusante.

Le retour de bâton était subtil : vider les caches chaque nuit supprimait du contenu local utile et forçait des retéléchargements répétés. Exécuter DISM cleanup chaque nuit concurrençait aussi d’autres tâches lourdes en disque comme les backups et rotations de logs, étirant les fenêtres de maintenance. Et le redémarrage forcé — destiné à « finaliser le nettoyage » — entrait parfois en collision avec des jobs batch applicatifs programmés selon un autre rythme de redémarrage.

L’approche retenue était plus lente, plus sûre et moins coûteuse : vider SoftwareDistribution seulement s’il dépasse un seuil ou en cas d’échec des mises à jour ; limiter Delivery Optimization via politique ; exécuter DISM cleanup mensuellement après vérification des patches ; redémarrer seulement si c’est en attente. Le disque est resté sain, le patching est devenu plus rapide, et le graphe WAN a cessé de ressembler à un sismographe.

Leçon : L’automatisation excessive reste de l’automatisation. Si vous automatisez le mauvais comportement, vous scalez la douleur.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Pendant une urgence de sécurité, une équipe devait patcher un lot de serveurs avec presque pas d’espace libre. Les systèmes étaient stables mais serrés — petits volumes OS, logs agressifs, et des mois de « on réparera ça plus tard ». Tout le monde s’attendait à une longue nuit.

Un ingénieur avait l’habitude ennuyeuse suivante : chaque mois, après les patchs, il capturait une baseline de l’utilisation disque par compartiment — WinSxS (via DISM analyze), taille de SoftwareDistribution, taille du cache DO, et espace libre total — puis l’archivait avec le ticket de changement. Rien de compliqué, juste un petit CSV et une note.

Cette historique leur a permis d’agir rapidement. Ils ont vu que WinSxS n’était pas exceptionnellement récupérable, mais que SoftwareDistribution avait explosé après un cycle de mise à jour raté deux semaines plus tôt. Ils ont vidé le cache de téléchargement en toute sécurité, obtenu suffisamment d’espace pour installer le patch d’urgence, et évité des mouvements agressifs /ResetBase qui auraient supprimé les options de rollback pendant un patch risqué.

Après l’urgence, ils ont corrigé le vrai problème : une source de mise à jour mal configurée qui provoquait des téléchargements et échecs répétés. La pratique « ennuyeuse » de baseline n’a pas seulement sauvé de l’espace — elle a fait gagner du temps de décision quand le temps était la ressource rare.

Leçon : Les baselines paraissent bureaucratiques jusqu’à ce qu’elles deviennent le chemin le plus court vers la bonne décision.

Erreurs courantes : symptôme → cause racine → correction

1) « WinSxS fait 20 Go, donc je vais le supprimer »

Symptôme : Échecs de servicing, échecs de mises à jour cumulatives, machines bloquées sur « configuration des mises à jour » au redémarrage.

Cause racine : La suppression manuelle casse les hardlinks et les manifests de composants.

Correction : Arrêtez les nettoyages manuels. Réparez avec DISM /RestoreHealth, puis utilisez /StartComponentCleanup. Restaurez depuis un snapshot si le servicing est irrécupérable.

2) « J’ai vidé SoftwareDistribution mais je n’ai pas récupéré d’espace »

Symptôme : Le dossier reste volumineux, ou l’espace libre n’a pas changé.

Cause racine : Les services tournaient encore ; fichiers verrouillés. Ou la pression disque se situe ailleurs (logs, dumps, données applicatives).

Correction : Arrêtez wuauserv, bits et cryptsvc d’abord ; supprimez seulement le contenu du sous-dossier Download ; re-mesurez les plus gros consommateurs.

3) « DISM cleanup a tourné, mais rien n’a changé »

Symptôme : WinSxS toujours volumineux, paquets récupérables encore affichés, ou espace non libéré.

Cause racine : Le nettoyage a déjà été effectué récemment ; rien n’est récupérable. Ou un redémarrage en attente empêche la finalisation.

Correction : Exécutez /AnalyzeComponentStore et vérifiez la « Date of Last Cleanup » et les paquets récupérables. Vérifiez les clés de redémarrage en attente ; redémarrez pendant une fenêtre et re-vérifiez.

4) « Après /ResetBase nous ne pouvons plus désinstaller la mauvaise mise à jour »

Symptôme : Options de désinstallation manquantes, rollback bloqué.

Cause racine : /ResetBase supprime volontairement les composants supersédés et les chemins de désinstallation.

Correction : N’utilisez pas /ResetBase sauf si votre stratégie de rollback est « restaurer/reconstruire ». À court terme, restaurez depuis un snapshot/image ou atténuez via un changement de configuration.

5) « Les scripts de nettoyage ralentissent le patching »

Symptôme : Les mises à jour se téléchargent à répétition ; la fenêtre de maintenance dépasse.

Cause racine : Vider trop agressivement les caches force le retéléchargement et la revalidation.

Correction : Ajoutez des seuils et des nettoyages déclenchés par des échecs ; conservez les caches sauf s’ils posent problème.

6) « Le disque se remplit à nouveau peu après le nettoyage »

Symptôme : Vous libérez de l’espace, puis il disparaît en heures/jours.

Cause racine : Retentatives de mise à jour, patches échoués, repopulation du cache DO, dumps de crash, ou logs incontrôlés.

Correction : Identifiez la source de croissance avec des mesures planifiées ; corrigez les échecs de mise à jour ; plafonnez DO ; ajustez la rétention des logs ; déplacez dumps/logs sur un volume de données si approprié.

Checklists / plan étape par étape

Checklist A : Urgence « C: est presque plein » (15–30 minutes)

1. Mesurer l’espace libre (Tâche 1). Décidez si vous avez besoin d’espace immédiat pour éviter un impact de service.
2. Mesurer les gros compartiments (Tâche 2). Ne présumez pas que ce sont les mises à jour.
3. Vider le cache de téléchargement SoftwareDistribution (Tâche 10) s’il est volumineux. C’est généralement la récupération la plus rapide et sûre.
4. Vider le cache Delivery Optimization s’il est énorme et que vous n’en tirez pas d’avantage (Tâche 11).
5. Re-mesurer et arrêtez si vous êtes repassé au-dessus de votre seuil opérationnel (Tâche 15).

Checklist B : Nettoyage planifié pendant une fenêtre de maintenance (plus sûr, plus profond)

1. Vérifier le redémarrage en attente (Tâche 8). Si en attente, redémarrez d’abord ou planifiez le redémarrage après.
2. Analyser le magasin de composants (Tâche 3). Confirmez que le nettoyage est recommandé.
3. Scanner la santé (Tâche 4). Réparez si nécessaire (Tâche 5).
4. Exécuter /StartComponentCleanup (Tâche 6).
5. Seulement si justifié : envisagez /ResetBase (Tâche 7) lorsque la stratégie de rollback est restore/rebuild.
6. Post-vérification : relancez l’analyse et mesurez l’espace libre ; confirmez que le scan/install Windows Update fonctionne.

Checklist C : Contrôle continu (pour arrêter d’éteindre des incendies)

1. Définir des seuils pour le nettoyage des caches (par ex. SoftwareDistribution > 5 Go déclenche un nettoyage).
2. Baseliner la taille réelle de WinSxS et les paquets récupérables mensuellement (stocker la sortie de la Tâche 3).
3. Dimensionnez les disques OS comme des adultes : les mises à jour cumulatives, le rollback et les logs ont besoin d’espace. Si vos disques OS sont ridiculement petits par tradition, la tradition a tort.
4. Rendez le patching ennuyeux : cadence cohérente, redémarrages cohérents, vérification cohérente.

Blague #2 : Le moyen le plus rapide de faire manquer d’espace disque à un serveur Windows est de programmer une réunion intitulée « On devrait vraiment réparer l’utilisation disque ».

FAQ

1) Puis-je supprimer des fichiers dans C:\Windows\WinSxS pour libérer de l’espace ?

Non. Vous pouvez réduire la taille du magasin de composants avec DISM, qui comprend les dépendances de composants et les hardlinks. La suppression manuelle casse le servicing et peut provoquer des échecs de mises à jour futures.

2) Pourquoi WinSxS semble-t-il plus grand qu’il ne l’est « réellement » ?

Parce que Windows utilise des hardlinks. Explorer et des sommes récursives naïves peuvent compter les mêmes données sous-jacentes plusieurs fois. La sortie d’analyse de DISM est la bonne lentille pour l’estimation de récupérabilité.

3) Est-il sûr de supprimer C:\Windows\SoftwareDistribution\Download ?

Oui, quand vous arrêtez d’abord les services liés à Windows Update. Vous supprimez des téléchargements mis en cache, pas des patches installés. Windows retéléchargera ce dont il a besoin.

4) Vider SoftwareDistribution cassera-t-il Windows Update ?

Généralement non, mais cela peut réinitialiser l’état local des téléchargements. Si vous supprimez plus que le contenu du dossier Download (ou supprimez pendant que les services tournent), vous pouvez créer des erreurs de mise à jour qui nécessitent des étapes de réparation.

5) Quelle est la différence entre /StartComponentCleanup et /ResetBase ?

/StartComponentCleanup supprime les composants supersédés quand c’est sûr et tend à préserver la capacité de désinstallation pour certaines mises à jour. /ResetBase est plus agressif et supprime la possibilité de désinstaller les mises à jour supersédées.

6) Combien d’espace libre dois-je garder sur le lecteur OS ?

Pour les serveurs, visez une marge stable : assez pour une mise à jour cumulative, le staging, les logs et une fenêtre de rollback. Pratiquement, garder au moins 10–20 Go libres (ou ~10–15 %) évite beaucoup de problèmes, mais des flottes avec patching intensif peuvent nécessiter plus.

7) Puis-je faire ces nettoyages à distance sur de nombreux serveurs ?

Oui. Utilisez PowerShell remoting pour exécuter les mêmes étapes DISM et de nettoyage de cache, mais ajoutez des garde-fous : capturez le avant/après, vérifiez le redémarrage en attente, et évitez les modes agressifs sauf si le serveur est dans un état connu bon.

8) Pourquoi l’espace libre n’augmente-t-il pas immédiatement après un nettoyage DISM ?

Parfois le nettoyage se finalise au redémarrage, ou l’espace est lié à des opérations en attente. Aussi, votre mesure « gros dossier » peut être gonflée par des hardlinks. Utilisez l’analyse DISM et vérifiez le statut de redémarrage en attente.

9) Dois-je vider le cache Delivery Optimization sur les serveurs ?

Si vous ne bénéficiez pas du peer caching et que vous êtes à court d’espace, oui — videz-le et imposez une limite via la politique. Si vous exécutez de nombreuses machines sur un site, DO peut être bénéfique ; gérez-le plutôt que de le supprimer chaque nuit.

10) Que faire si DISM échoue avec des erreurs de source pendant /RestoreHealth ?

Alors votre source de réparation n’est pas disponible. Vous devrez fournir une source connue bonne (souvent une ISO montée correspondant à la build OS) ou configurer une source de réparation. Ne procédez pas à un nettoyage agressif quand le magasin ne peut pas être réparé.

Prochaines étapes que vous pouvez réellement faire cette semaine

• Choisissez trois serveurs qui manquent chroniquement d’espace sur C: et exécutez DISM analyze (Tâche 3). Enregistrez « Actual size », « Reclaimable packages » et « Last cleanup ». C’est votre baseline.
• Implémentez un nettoyage de cache basé sur des seuils pour SoftwareDistribution (Tâche 9 + Tâche 10). Ne l’exécutez pas chaque nuit par défaut ; lancez-le quand il est réellement gros ou quand les mises à jour échouent.
• Décidez de votre posture de rollback avant d’utiliser /ResetBase. Si votre rollback est « désinstaller la dernière mise à jour », évitez-le. Si votre rollback est « restaurer un snapshot/rebuild », cela peut être acceptable.
• Dimensionnez les volumes OS comme un adulte : prévoyez de l’espace pour les mises à jour cumulatives et les opérations de maintenance. Le stockage est moins cher que le downtime.
• Après tout nettoyage, lancez un cycle de scan/install de mises à jour via vos outils habituels. Un nettoyage qui casse le patching n’est pas un nettoyage ; c’est du sabotage avec des étapes en plus.

Si vous ne prenez qu’une habitude : mesurez avec DISM, nettoyez avec DISM, et traitez la suppression de cache comme un scalpel — pas une tronçonneuse.