Знаходження та безпечне видалення старих оновлень Windows за допомогою PowerShell

Як оновлення Windows фактично «з’їдають» диск

Коли кажуть «оновлення Windows займають місце», зазвичай мають на увазі одну з чотирьох речей:

• Сховище компонентів (WinSxS): реальна важка вага. Зберігає компоненти і кілька версій для сервісінгу й відкату. Просто «видалити» його не вийде, бо він переплетений із сервісінг-стеком.
• Кеш оновлень (звично C:\Windows\SoftwareDistribution\Download): тимчасові завантаження та підготовчі файли. Зазвичай безпечно очищати якщо спочатку зупинити сервіси.
• Кеш Delivery Optimization: p2p і локальне кешування контенту Windows Update. Корисно на флотах машин; дратує на одиночних серверах із маленькими системними томами.
• Старі артефакти ОС, як-от Windows.old після оновлень функцій (більше для клієнтів, але з’являється і на серверах при in-place оновленнях).

Ключова операційна нюанс: використання диска ≠ відновлюване місце. WinSxS може виглядати величезним, але значна частина файлів — це жорсткі посилання в ОС і додатках. Видалення «неправильної» речі не зменшить використання — і може поламати сервісінг.

Отже, робочий процес: виміряйте правильно, визначте, до якої категорії ви належите, оберіть найменш ризиковий механізм очищення (надавайте перевагу вбудованим інструментам сервісінгу) і перевірте логи та цикл оновлень після очищення.

Швидка діагностика — план дій

Коли диск C: кричить і вам потрібні швидкі відповіді, не лізьте в темні куточки. Виконайте цю послідовність:

1) Підтвердьте, що проблема реальна й локальна

• Перевірте вільне місце й швидкість зростання. Якщо диск — тонкопроєкований LUN, упевніться, що це не паніка на боці сховища, замаскована під «оновлення Windows».
• Підтвердьте, який том уражено: системний, даних чи дивний маленький розділ відновлення, якому призначили букву диска (таке трапляється).

2) Визначте директорію з найбільшим споживанням

• Чи це WinSxS? SoftwareDistribution? Папка дампів? Логи? Невгамовний додаток? Ви не зможете виправити те, що відмовляєтесь вимірювати.

3) Виберіть шлях очищення

• Якщо WinSxS великий: використовуйте очищення сховища компонентів через DISM. Не видаляйте вручну.
• Якщо SoftwareDistribution великий: зупиніть сервіси, очистіть кеш, перезапустіть сервіси.
• Якщо Delivery Optimization великий: очистіть кеш DO і налаштуйте політику.
• Якщо існує Windows.old: видаляйте через підтримувані інструменти очищення, а не через Провідник.

4) Перевірте здоров’я сервісінгу до і після

• Запустіть перевірки здоров’я DISM. Якщо сховище компонентів пошкоджене, очищення не пройде так, як ви очікуєте.
• Після очищення виконайте цикл виявлення/встановлення оновлень (або принаймні скан), щоб підтвердити, що ви не зламали Windows Update.

Цікаві факти та історичний контекст (щоб ви перестали гадати)

1. WinSxS — це не «кеш». Це сховище компонентів, введене для вирішення «DLL hell» і забезпечення надійного сервісінгу. Воно має право бути великим.
2. Провідник трохи брешe про розмір WinSxS. Багато файлів — це жорсткі посилання; рекурсивне підсумовування може рахувати ті самі дані кілька разів, тому папка виглядає більшою, ніж фактична зайнятість диска.
3. DISM замінив старі інструменти сервісінгу. Перехід до DISM відображає рух Windows до компонентно-орієнтованого сервісінгу.
4. Накопичувальні оновлення змінили правила гри для очищення. Щомісячні rollup та накопичувальні оновлення зменшують фрагментацію патчів, але можуть збільшити тимчасове місце для підготовки й відкату.
5. Існують Servicing Stack Updates (SSU), бо сервісінг сам потребує сервісінгу. Якщо ви зламаєте стек сервісінгу, оновлення стануть ненадійними або неможливими.
6. Windows Update використовує кілька сервісів. Очищення кешів без зупинки сервісів залишає файли заблокованими і дає непослідовні результати — як міняти шину в автомобілі, що їде.
7. Delivery Optimization створено для економії пропускної здатності. На одиночному сервері воно часто поводиться як «податок на диск», якого ви не затверджували.
8. Очищення сховища компонентів може видалити можливість деінсталяції. Деякі режими очищення навмисно відкидають замінені компоненти; це рішення про ризик, а не «кнопка для вільного місця».
9. Старі оновлення часто зберігаються заради гарантій відкату. Система зберігає те, що потрібно для відкату поганого патча або для задоволення графа залежностей.

Модель безпеки: що безпечно видаляти, а що — ні

Проведемо межу між «безпечно за процедурою» і «ризик для кар’єри».

Зазвичай безпечно (якщо виконувати правильні кроки)

• Кеш завантажень SoftwareDistribution (спочатку зупиніть сервіси WU). Ви видаляєте завантажені інсталятори та тимчасовий контент, а не встановлені оновлення.
• Кеш Delivery Optimization (очищуйте через підтримувані cmdlet/налаштування). Ви видаляєте кешовані пакети, а не системні компоненти.
• Тимчасові файли та логи CBS (зі встановленою політикою збереження). Логи не святі; вони корисні, якщо можна створювати нові.
• Windows.old (після впевненості, що відкат не потрібен). Використовуйте інструменти очищення, щоб права доступу й reparse-пункти не заважали.

Безпечно лише через інструменти сервісінгу (DISM), не вручну

• WinSxS/сховище компонентів. Використовуйте операції аналізу/очищення DISM. Ручне видалення — це шлях до машини, що «працює» до наступного вікна оновлень.

Не чіпайте, якщо не любите дивних простоїв

• Ручна обрізка C:\Windows\WinSxS. Ні.
• Очищення C:\Windows\Installer без інструментарію інвентаризації MSI. Видалення випадкових MSI/MSP ламає ремонт/деінсталяцію і іноді оновлення.
• Забави з реєстром, щоб «вимкнути оновлення» як стратегія звільнення місця. Це не очищення; це накопичення боргу.

Перефразована думка Вернера Вогельса (технічний директор Amazon): Все відмовляє; проєктуйте й експлуатуйте так, ніби відмова — це норма. Це стосується й ваших скриптів очищення — передбачайте переривання, перезавантаження та напівзавершені операції.

Жарт №1: Видаляти випадкові речі в C:\Windows — це як «оптимізувати» парашут, відрізавши ремені: технічно легше, оперативно — захопливо.

Практичні завдання (команди, виводи, рішення)

Ось реальні завдання, які можна виконати як адміністратор. Кожне містить: команду, що означає вивід, і рішення, яке ви приймаєте.

Примітка щодо блоків коду: У форматі нижче позначки виглядають як Linux-підказка, але команди — це Windows PowerShell і виконуються в PowerShell. Це обмеження форматування, не стиль життя.

Завдання 1: Перевірка вільного місця на всіх томах (база)

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

Що це означає: Підтверджує, що тиск на C:, а не на том даних. Також показує, чи маємо «лише 18 ГБ вільних» (керовано) проти «300 МБ» (потрібна термінова триаж).

Рішення: Якщо на C: менше ~5–10% вільного, уникайте довготривалих операцій, які можуть створювати тимчасові файли (включно з деякими інсталяціями оновлень), доки не звільните місце.

Завдання 2: Швидко визначити найбільших споживачів диска (без сторонніх інструментів)

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

Що це означає: Ви швидко отримуєте орієнтир. Число WinSxS тут — наївна сума (жорсткі посилання можуть його завищувати), але SoftwareDistribution/DO ближчі до «реальності».

Рішення: Якщо SoftwareDistribution і DO великі, часто можна безпечно повернути місце до того, як торкатися очищення сховища компонентів.

Завдання 3: Отримати реальний розмір, який можна звільнити в сховищі компонентів (аналіз 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.

Що це означає: «Actual Size» ближче до фактичного споживання диска. «Reclaimable Packages» і «Cleanup Recommended» кажуть, чи очікує DISM значного звільнення.

Рішення: Якщо рекомендовано очищення, заплануйте його під час вікна обслуговування, бо це може сильно навантажувати ЦП/диск і іноді вимагати перезавантаження.

Завдання 4: Переконатися, що сховище компонентів здорове перед очищенням (DISM ScanHealth)

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.

Що це означає: Менше ймовірності дивних збоїв під час очищення або майбутніх оновлень.

Рішення: Якщо виявлено корупцію, віддайте пріоритет ремонту (/RestoreHealth) перед видаленням кешів. Корупція плюс очищення — це шлях до непатчабельних машин.

Завдання 5: Відновити сервісінг за потреби (DISM RestoreHealth)

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.

Що це означає: DISM відремонтував сховище компонентів, використовуючи локальні джерела або Windows Update.

Рішення: Якщо DISM не знаходить джерела, потрібне альтернативне джерело (монтуваний ISO або налаштований repair source). Не продовжуйте з «очищенням», якщо сховище пошкоджене — ви лише погіршите наступне оновлення.

Завдання 6: Безпечне очищення сховища компонентів (рекомендований режим)

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.

Що це означає: Видаляє замінені компоненти, коли це безпечно. Це «нормальний» режим очищення, який зберігає підтримуваність системи.

Рішення: Використовуйте це першим. Це найкращий баланс між звільненням місця і збереженням шляхів відкату для останніх оновлень.

Завдання 7: Агресивний режим (з наслідками): 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.

Що це означає: Відкидає можливість деінсталяції замінених оновлень. Ви фіксуєтеся на поточному базовому стані.

Рішення: Виконуйте це лише коли (a) ви впевнені в стабільності патчів, (b) маєте протестовані плани відкату (знімки VM, образи або швидке відновлення), і (c) тиск диска хронічний. Це не операція «в п’ятницю ввечері».

Завдання 8: Перевірити, чи очікується перезавантаження (перед інтерпретацією результатів)

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

Що це означає: Очікуване перезавантаження може не дати очищенню завершитись остаточно і тримати місце зайнятим.

Рішення: Якщо перезавантаження очікується, заплануйте його. Багато скарг «очищення не спрацювало» насправді означають «очищення чекає на перезавантаження».

Завдання 9: Виміряти розмір кешу SoftwareDistribution і вирішити, чи варто очищати

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

Що це означає: Зазвичай це відновлюване місце, особливо якщо файли старі й оновлення вже встановлені.

Рішення: Якщо це кілька ГБ і вам терміново потрібно місце, очистіть безпечно (наступне завдання). Очікуйте, що Windows Update заново завантажить потрібний контент пізніше.

Завдання 10: Безпечно очистити SoftwareDistribution (зупинити сервіси, видалити, запустити)

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

Що це означає: Сервіси перезапущені, кеш завантажень очищено. Якщо файли були заблоковані, деякі можуть залишитись; це нормально, якщо більшість зникла.

Рішення: Повторно перевірте вільне місце. Якщо його стало достатньо — зупиніться тут. Не накопичуйте ризикових операцій, коли просте рішення спрацювало.

Завдання 11: Перевірити кеш Delivery Optimization і очистити його

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

Що це означає: Статус прямо не показує розмір кешу; він більше про поточні передачі. Для розміру кешу виміряйте директорію або використайте налаштування очищення.

Рішення: Якщо папка DO велика і ви не отримуєте вигоди від peer-кешування на серверах, очистіть її і встановіть політику обмеження.

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

Що це означає: Кеш видалено. Він відновиться, якщо DO увімкнено і відбудуться оновлення.

Рішення: Якщо кеш постійно відновлюється, встановіть політику-обмеження замість щоденного видалення, що протистоїть ОС.

Завдання 12: Знайти встановлені оновлення та дати їх інсталяції (для рішень про відкат)

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

Що це означає: Швидкий огляд останньої активності патчів. Не ідеально для всіх типів оновлень, але корисно для оператора.

Рішення: Якщо останній патч дуже свіжий і ви в «періоді моніторингу», уникайте /ResetBase, поки не впевнитесь, що не знадобиться деінсталяція.

Завдання 13: Переконатися, що сервіси Windows Update не «скачуть» (очищення може маскувати реальні проблеми)

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

Що це означає: Сервіси в очікуваних станах. Якщо вони Disabled, хтось «вирішив» проблему з оновленнями, відключивши їх.

Рішення: Якщо несподівано вимкнено, виправте політику/налаштування. Очищення кешів не допоможе, якщо механізм оновлень мертвий.

Завдання 14: Перевірка системних файлів (SFC), коли оновлення поводяться дивно

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.

Що це означає: Цілісність добра. Якщо повідомляє про виправлення, це може пояснити невдачі оновлень і дивний диск-чурн.

Рішення: Якщо SFC постійно знаходить корупцію, у вас глибша проблема (сховище, антивірус, поганий образ). Не маскуйте її скриптами очищення.

Завдання 15: Вимірювати «до/після» й логувати дельту (бо люди забувають)

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

Що це означає: Очищення звільнило місце зараз, не «можливо пізніше». Якщо нічого не звільнилося, ви дізналися без гадань.

Рішення: Використайте дельту, щоб обрати наступні кроки: очистити кеші, перемістити логи, розширити диск або змінити графік патчінгу.

Три міні-історії з корпоративного світу (і їхні уроки)

Міні-історія 1: Інцидент через неправильне припущення

Великий внутрішній LOB-додаток почав падати після Patch Tuesday. Він не впав «жорстко»; він був «переважно доступний», а це найвитратніший тип зламу. Деякі вузли пулу були в порядку, інші — застрягали в циклі перезавантаження під час обслуговування, і on-call спостерігав, як балансувальник поступово втрачає здорові цілі.

Корінь проблеми не був у самому оновленні. Це було очищення: інженер припустив, що папка WinSxS — «лише старі оновлення», і запустив скриптоване видалення «великих підпапок під C:\Windows», щоб звільнити місце. Воно спрацювало на кількох некритичних серверах, і це стало «стандартом». Потім воно вдарило по системах під час сервісінгу.

Машини не померли відразу. Це була пастка. Вони працювали до наступного накопичувального оновлення, яке намагалося підготувати компоненти й узгодити залежності. Сервісінг зазнав невдачі, відкат застосовувався частково, і вузли опинилися з різними станами компонентів. Цикл перезавантаження не був класичним BSOD; це був Windows, що намагався завершити невдалі операції сервісінгу й програвав бій.

Виправлення не було хитрим: відновлення з відомо робочих снапшотів для найгірших вузлів, а для тих, що можна було врятувати — ремонт сховища компонентів за допомогою DISM і повторне застосування оновлень у контрольованому вікні. Політика «очищення» була замінена на нудне правило: якщо хочеш зменшити WinSxS — використовуй DISM, або взагалі не чіпай.

Урок: Неправильне припущення зазвичай стосується того, що представляє папка. У сервісінгу Windows папки — це не просто папки. Це контракти.

Міні-історія 2: Оптимізація, що обернулась проти

Інша компанія мала флот Windows Server VM з маленькими системними дисками. Хтось вирішив бути проактивним і створив таск: щоночі він зупиняв сервіси Windows Update, очищав SoftwareDistribution, очищав кеш Delivery Optimization, запускав DISM cleanup, потім перезавантажував. Графіки диска стали красивими. Інженера похвалили за «підтримку порядку».

Потім почала падати відповідність патчам. Оновлення стали ставитись довше. Деякі сервери пропускали вікна обслуговування, бо проводили першу половину часу на повторному завантаженні контенту, який щойно викинули. Пропускна здатність на WAN зросла в ті ж ночі, коли працювали щоденні таски. WAN-команда підключилася — а це не весела зустріч.

Наслідки були тонкими: нічне щоденне очищення видалило корисний локальний контент і змусило постійні повторні завантаження. DISM cleanup щодня конкурував із іншими важкими завданнями диска, як-от бекапи й ротація логів, розтягуючи вікна обслуговування. І форсований перезапуск іноді наштовхувався на пакетні завдання додатків, які очікували іншого графіку перезавантажень.

Новий підхід був повільнішим, безпечнішим і дешевшим: очищати SoftwareDistribution лише коли він перевищує поріг або коли оновлення падають; обмежити Delivery Optimization політикою; запускати DISM cleanup щомісяця після верифікації патчів; перезавантажувати лише коли є очікуваний pending. Диск залишився здоровим, патчінг прискорився, і WAN-графіки перестали нагадувати сейсмограф.

Урок: Надмірна автоматизація — це все ще автоматизація. Якщо ви автоматизуєте неправильну поведінку, ви масштабуватимете біль.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Під час аварійної ситуації з безпекою команда мала оновити пачку серверів з майже нульовим вільним місцем. Системи були стабільні, але тугі — маленькі ОС-диски, агресивне логування і місяці «поправимо потім». Всі чекали довгої ночі.

Один інженер мав нудну звичку: кожного місяця після патчінгу він знімав базову статистику використання диска — WinSxS (через DISM analyze), розмір SoftwareDistribution, розмір DO-кешу та загальне вільне місце — і зберігав це з записом зміни. Нічого фантастичного, лише маленький CSV і запис.

Тя ця історія дозволила діяти швидко. Вони бачили, що WinSxS не має надто багато для очищення, але SoftwareDistribution роздмухався після невдалого циклу оновлення два тижні тому. Вони безпечно очистили кеш завантажень, отримали достатньо простору для екстреного патча і уникнули агресивних /ResetBase-ходів, які б видалили шляхи відкату під час ризикового патчування.

Після надзвичайної ситуації вони виправили реальну проблему: неправильно налаштоване джерело оновлень, що викликало повторні завантаження й збої. «Нудна» практика базування не лише врятувала диск — вона зекономила час прийняття рішень, коли час був дефіцитом.

Урок: Базові знімки здаються бюрократією, доки не стануть найкоротшим шляхом до правильного рішення.

Поширені помилки: симптом → корінь → виправлення

1) «WinSxS — 20 ГБ, тож я його видалю»

Симптом: Помилки сервісінгу, накопичувальні оновлення не вдаються, машини застрягають «налаштовують оновлення» під час перезавантаження.

Корінь: Ручне видалення ламає жорсткі посилання та маніфести компонентів.

Виправлення: Припиніть ручне очищення. Відновіть через DISM /RestoreHealth, потім використайте /StartComponentCleanup. Відновіть з снапшоту, якщо сервісінг невідновлюваний.

2) «Я очистив SoftwareDistribution, але місце не повернулося»

Симптом: Директорія все ще велика, або вільне місце не змінилося.

Корінь: Сервіси ще працювали; файли були заблоковані. Або тиск диска в іншому місці (логи, дампи, дані додатків).

Виправлення: Зупиніть wuauserv, bits та cryptsvc спочатку; видаляйте лише вміст підпапки Download; знову виміряйте топ-споживачів.

3) «DISM очистив, але нічого не змінилося»

Симптом: WinSxS досі великий, кількість reclaimable packages не змінилася або місце не звільнилося.

Корінь: Очищення вже виконувалося нещодавно; нічого звільняти. Або очікуване перезавантаження перешкоджає завершенню.

Виправлення: Запустіть /AnalyzeComponentStore і перевірте «Date of Last Cleanup» і reclaimable packages. Перевірте ключі pending reboot; перезавантажте в вікні й перевірте знову.

4) «Після /ResetBase ми не можемо деінсталювати погане оновлення»

Симптом: Опції деінсталяції зникли, відкат заблоковано.

Корінь: /ResetBase навмисно відкидає замінені компоненти та шляхи деінсталяції.

Виправлення: Не використовуйте /ResetBase, якщо ваша стратегія відкату — «деінсталювати останнє оновлення». Короткостроково — відновіть з снапшоту/образу або пом’якшіть конфігурацією.

5) «Скрипти очищення сповільнюють патчінг»

Симптом: Оновлення завантажуються повторно; вікно обслуговування переростає.

Корінь: Забагато агресивного очищення кешів змушує повторні завантаження та перевірки.

Виправлення: Додайте пороги і очищення за тригером збоїв; зберігайте кеші, якщо вони не проблема.

6) «Диск швидко знову заповнюється після очищення»

Симптом: Ви звільняєте простір, а потім він зникає за години/дні.

Корінь: Повторні спроби оновлень, невдалі патчі, відновлення DO-кешу, дампи збоїв або неконтрольовані логи.

Виправлення: Визначте джерело зростання за плановими вимірюваннями; виправте збої оновлень; обмежте DO; налаштуйте збереження логів; перемістіть дампи/логи на том даних, якщо це доцільно.

Чек-листи / покроковий план

Чек-лист A: Невідкладно «C: майже заповнений» (15–30 хвилин)

1. Виміряйте вільне місце (Завдання 1). Визначте, чи потрібне негайне місце, щоб уникнути впливу на сервіс.
2. Виміряйте великі кошики (Завдання 2). Не припускайте, що це оновлення.
3. Очистіть кеш завантажень SoftwareDistribution (Завдання 10), якщо він великий. Це зазвичай найшвидший безпечний спосіб.
4. Очистіть кеш Delivery Optimization, якщо він величезний і вам не потрібен (Завдання 11).
5. Повторно виміряйте і зупиніться, якщо ви повернулись вище вашого операційного порога (Завдання 15).

Чек-лист B: Планове очищення у вікні обслуговування (безпечніше, глибше)

1. Перевірте очікуване перезавантаження (Завдання 8). Якщо воно є, перезавантажте спочатку або заплануйте перезавантаження після.
2. Проаналізуйте сховище компонентів (Завдання 3). Підтвердіть рекомендацію очищення.
3. Проскануйте здоров’я (Завдання 4). Відремонтуйте за потреби (Завдання 5).
4. Запустіть /StartComponentCleanup (Завдання 6).
5. Тільки за обґрунтуванням: розгляньте /ResetBase (Завдання 7), коли стратегія відкату — відновлення/перебудова.
6. Після перевірки: знову запустіть аналіз і виміряйте вільне місце; підтвердіть, що скан/встановлення Windows Update працює.

Чек-лист C: Постійний контроль (щоб припинити пожежогасіння)

1. Встановіть пороги для очищення кешів (наприклад, SoftwareDistribution > 5 ГБ тригерить очищення).
2. Знімайте базу фактичного розміру WinSxS і кількості reclaimable packages щомісяця (зберігайте вивід Завдання 3).
3. Розмір системних дисків підбирайте реалістично: накопичувальні оновлення, відкат і логи потребують запасу. Якщо ваші ОС-диски малі за звичкою — це неправильна традиція.
4. Зробіть патчінг нудним: стабільний графік, стабільні перезавантаження, стабільна верифікація.

Жарт №2: Найшвидший спосіб змусити Windows-сервер закінчитися місцем — запланувати зустріч під назвою «Нам точно треба виправити використання диска».

Часті запитання

1) Чи можна видаляти файли всередині C:\Windows\WinSxS щоб звільнити місце?

Ні. Зменшувати розмір сховища компонентів потрібно через DISM, що розуміє залежності компонентів і жорсткі посилання. Ручне видалення ламає сервісінг і може спричинити помилки майбутніх оновлень.

2) Чому WinSxS виглядає більшим, ніж «фактично»?

Тому що Windows використовує жорсткі посилання. Провідник і наївні рекурсивні підсумування можуть рахувати ті самі дані кілька разів. Вивід аналізу DISM — правильний погляд на відновлюваність.

3) Чи безпечно видаляти C:\Windows\SoftwareDistribution\Download?

Так, якщо ви спершу зупините сервіси, пов’язані з Windows Update. Ви видаляєте кешовані завантаження, а не встановлені патчі. Windows пізніше завантажить те, що знадобиться.

4) Чи зламає очищення SoftwareDistribution Windows Update?

Зазвичай ні, але це може скинути локальний стан завантаження. Якщо ви видалите більше, ніж вміст каталогу Download (або видалите поки сервіси працюють), можна отримати помилки оновлень, які потребуватимуть кроків ремонту.

5) У чому різниця між /StartComponentCleanup та /ResetBase?

/StartComponentCleanup видаляє замінені компоненти, коли це безпечно, і зазвичай зберігає можливість деінсталяції для деяких оновлень. /ResetBase — агресивніший і видаляє можливість деінсталювати замінені оновлення.

6) Скільки місця тримати вільним на диску ОС?

Для серверів прагніть стабільного буфера: достатньо для накопичувального оновлення, підготовки, логів і можливості відкату. Практично зберігайте принаймні 10–20 ГБ вільних (або ~10–15%) — це уникне багатьох проблем, але великі флоти з інтенсивним патчінгом можуть потребувати більше.

7) Чи можна робити ці очищення віддалено на багатьох серверах?

Так. Використовуйте PowerShell Remoting, щоб запускати ті самі кроки DISM і очищення кешів, але додайте запобіжники: зафіксуйте до/після, перевірте очікуване перезавантаження і уникайте агресивних режимів, якщо сервер не в відомо робочому стані.

8) Чому вільне місце не зростає одразу після DISM очистки?

Іноді очищення завершується після перезавантаження, або місце зайняте очікуваними операціями. Також ваше «велике» вимірювання папки може бути завищене через жорсткі посилання. Використайте аналіз DISM і перевірте статус pending reboot.

9) Чи варто очищувати кеш Delivery Optimization на серверах?

Якщо ви не отримуєте вигоди від peer-кешування і маєте обмеження місця — так, очистіть і обмежте його політикою. Якщо ви маєте багато машин у сайті, DO може бути корисним — керуйте ним замість щоденного видалення.

10) Що робити, якщо DISM не вдається з помилками джерела під час /RestoreHealth?

Тоді ваше джерело відновлення недоступне. Потрібно надати відомо робоче джерело (зазвичай змонтований ISO, що відповідає збірці ОС) або налаштувати repair source. Не переходьте до агресивного очищення, коли сховище не можна відремонтувати.

Наступні кроки, які ви можете виконати вже цього тижня

• Виберіть три сервери, що хронічно мало вільного на C:, і запустіть DISM analyze (Завдання 3). Зафіксуйте «Actual size», «Reclaimable packages» та «Last cleanup». Це ваша базова лінія.
• Реалізуйте очищення кешу за порогом для SoftwareDistribution (Завдання 9 + Завдання 10). Не запускайте його щодня за замовчуванням; виконувати коли він справді великий або коли оновлення падають.
• Визначте вашу позицію щодо відкату перед використанням /ResetBase. Якщо ваш відкат — «деінсталювати останнє оновлення», уникайте цього. Якщо ваш відкат — «відновити з снапшоту/перебудувати», це може бути прийнятно.
• Розмір системних томів як доросла людина: плануйте місце для накопичувальних оновлень і операцій обслуговування. Сховище дешевше за простій.
• Після будь-якого очищення, запустіть скан/інсталяцію оновлень у вашому звичайному інструменті. Очищення, яке ламає патчінг — це не очищення; це саботаж із додатковими кроками.

Якщо ви візьмете лише одну звичку: вимірюйте за допомогою DISM, очищуйте за допомогою DISM і ставтеся до видалення кешів як до скальпеля — а не до бензопили.