Windows Server Update Services (WSUS)

Оновлення Windows стають керованим процесом не тоді, коли адміністратор натискає Approve, а коли може відповісти на три запитання: які пристрої отримають пакет, коли вони перезавантажаться та як перевірити результат. Windows Server Update Services допомагає централізувати цей процес у локальній інфраструктурі, але потребує правильної організації груп, політик і обслуговування.

У цьому матеріалі розгорнемо окремий WSUS на Windows Server 2022 із Windows Internal Database, підключимо доменні клієнти та побудуємо поетапне розповсюдження оновлень. Приклад використовує сервер wsus01.ad.example.com, каталог D:\WSUS і захищене підключення до служби на порту 8531. Замініть ці значення відповідно до свого середовища.

Важливий контекст: Microsoft оголосила WSUS застарілою технологією, для якої не планується розвиток нових можливостей. Це не означає негайного видалення ролі: вона залишається доступною, зокрема у Windows Server 2025, а підтримка залежить від життєвого циклу відповідної ОС. Для нового середовища варто порівняти WSUS із сучасними засобами керування оновленнями, а для наявного — забезпечити передбачувану експлуатацію.

1. Сплануйте сервер, мережеві потоки та групи оновлення

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

Для невеликого середовища зручно почати з окремої віртуальної машини та WID. Розмістіть файли оновлень на окремому томі, контролюйте вільне місце й передбачте розширення сховища. Не встановлюйте WSUS на контролері домену без обґрунтованої потреби: поєднання ролей ускладнює обслуговування та збільшує наслідки помилок конфігурації.

Перед встановленням перевірте:

- стабільну IP-адресу, DNS-запис і синхронізацію часу; - вихідний доступ сервера до необхідних адрес Microsoft Update через HTTP/HTTPS відповідно до актуальних вимог Microsoft; - параметри проксі, якщо прямого доступу до інтернету немає; - доступ клієнтів до WSUS на портах 8531 і, за стандартної конфігурації, 8530; - наявність сертифіката та довіри клієнтів до центру сертифікації; - погоджені вікна обслуговування для робочих станцій і серверів.

Розділіть пристрої щонайменше на Pilot, Workstations і Servers. Пілотна група має містити не випадковий комп’ютер, а представників основних конфігурацій: різні версії ОС, драйвери, засоби захисту та прикладні програми. Сервери додатково групуйте за ролями та залежностями.

Такий розподіл є частиною системного адміністрування інфраструктури: без інвентаризації пристроїв і відповідальних за сервіси навіть правильно встановлена роль не забезпечить контрольованих оновлень.

2. Встановіть WSUS і підготуйте HTTPS

Запустіть Windows PowerShell від адміністратора на майбутньому сервері WSUS. Команда нижче встановлює службу, WID та засоби керування. Диск D: повинен існувати й мати достатньо вільного місця.

Install-WindowsFeature -Name UpdateServices-Services,UpdateServices-WidDB -IncludeManagementTools

New-Item -Path 'D:\WSUS' -ItemType Directory -Force

& "$env:ProgramFiles\Update Services\Tools\WsusUtil.exe" postinstall CONTENT_DIR=D:\WSUS

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

У консолі Windows Server Update Services запустіть майстер налаштування. Для автономного сервера виберіть синхронізацію з Microsoft Update. Якщо використовується проксі, внесіть його параметри до першої спроби з’єднання.

Вибирайте лише потрібні продукти та мови. Для початку зазвичай достатньо класифікацій Security Updates, Critical Updates і Update Rollups, але фактичний набір залежить від продуктів. Окремо оцініть Updates, Definition Updates та Upgrades. Класифікація сама по собі не визначає доречність пакета: перевіряйте його опис і застосовність. Не вмикайте Drivers без окремого сценарію тестування.

У параметрах файлів доцільно завантажувати вміст лише після схвалення оновлень. Це зменшує початкове навантаження на диск, але означає, що перед розгортанням потрібно дочекатися завершення завантаження схвалених пакетів.

Налаштування захищеного з’єднання

Отримайте сертифікат із призначенням Server Authentication та DNS-іменем wsus01.ad.example.com у SAN. Встановіть його разом із приватним ключем у сховище Local Computer. Клієнти повинні довіряти всьому ланцюжку сертифікації.

У IIS Manager знайдіть сайт WSUS Administration і налаштуйте HTTPS-прив’язку на порту 8531 із цим сертифікатом. У SSL Settings увімкніть Require SSL для віртуальних каталогів:

- ApiRemoting30; - ClientWebService; - DSSAuthWebService; - ServerSyncWebService; - SimpleAuthWebService.

Не вмикайте Require SSL на всьому сайті. Зокрема, не переносіть цю вимогу автоматично на Content і Selfupdate. У стандартній схемі WSUS використовує HTTPS для захищеного обміну метаданими, але файли оновлень можуть передаватися через HTTP. Тому наявність HTTPS не означає, що порт 8530 можна одразу закрити.

Після налаштування IIS повідомте WSUS його захищене ім’я:

& "$env:ProgramFiles\Update Services\Tools\WsusUtil.exe" configuressl wsus01.ad.example.com

Import-Module UpdateServices
Get-WsusServer -Name 'wsus01.ad.example.com' -PortNumber 8531 -UseSsl

Успішне виконання останньої команди підтверджує підключення адміністративного API, але не замінює перевірки клієнтського сканування та завантаження пакетів.

3. Підключіть доменні пристрої через групову політику

Спочатку створіть групи Pilot, Workstations і Servers у консолі WSUS. У розділі Options → Computers виберіть використання Group Policy або параметрів реєстру для призначення комп’ютерів до груп. Без цього клієнтське націлювання не працюватиме очікуваним чином.

У Group Policy Management створіть окрему GPO для пілотного OU. Не прив’язуйте початкову конфігурацію одразу до кореня домену. Це дозволить перевірити застосування політики, джерело оновлень і поведінку перезавантаження на обмеженій кількості пристроїв.

Параметри розташовані в Computer Configuration → Policies → Administrative Templates → Windows Components → Windows Update. Залежно від версії ADMX вони можуть бути рознесені між підрозділами керування джерелом оновлень і взаємодією користувача.

Налаштуйте такі політики:

1. Specify intranet Microsoft update service location — увімкніть і вкажіть https://wsus01.ad.example.com:8531 як адресу служби виявлення оновлень та сервера статистики. 2. Enable client-side targeting — увімкніть і задайте Pilot. Назва має відповідати створеній групі WSUS. 3. Configure Automatic Updates — визначте режим автоматичного встановлення, день і час відповідно до погодженого графіка. 4. Політики перезавантаження, активних годин і кінцевих термінів — налаштуйте окремо для робочих станцій та серверів.

Для сучасних клієнтів Windows перевірте політику Specify source service for specific classes of Windows Updates. Якщо вона доступна для вашої версії ОС, явно задайте потрібне джерело для відповідних класів оновлень. Не припускайте, що одна адреса WSUS автоматично усуває конфлікти з іншими політиками Windows Update або MDM.

На пілотному клієнті застосуйте політики та перевірте результат:

gpupdate /force
gpresult /scope computer /r

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' |
    Select-Object WUServer, WUStatusServer, TargetGroup, TargetGroupEnabled

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' |
    Select-Object UseWUServer, AUOptions

Test-NetConnection -ComputerName 'wsus01.ad.example.com' -Port 8531

Значення UseWUServer має бути 1, а адреси повинні відповідати конфігурації. Перевірка TCP-порту підтверджує лише мережеву доступність: вона не перевіряє довіру до сертифіката чи успішність протоколу Windows Update.

Запустіть пошук оновлень через штатний інтерфейс Windows Update на тестовому пристрої. Поява комп’ютера та статистики в консолі не завжди миттєва. Не використовуйте старі команди wuauclt як універсальний спосіб примусового сканування сучасних Windows.

Якщо пристрої отримують суперечливі параметри з кількох джерел, починайте з аналізу результуючих політик. У межах адміністрування серверів Windows і Linux важливо документувати не лише значення параметрів, а й систему, яка ними керує.

4. Побудуйте цикл схвалення, перевірки та обслуговування

Перша синхронізація завантажує метадані. Вона не означає, що всі пакети вже схвалені, завантажені на сервер або встановлені клієнтами. Перед розгортанням переконайтеся, що синхронізація завершилася успішно та сховище доступне.

Практичний цикл виглядає так:

1. Перегляньте нові оновлення, їхню застосовність, залежності та відомі проблеми. 2. Схваліть потрібні пакети лише для Pilot. 3. Дочекайтеся завантаження файлів, сканування клієнтів, встановлення та необхідного перезавантаження. 4. Перевірте роботу прикладних програм, віддаленого доступу, друку й засобів захисту. 5. Після визначеного періоду спостереження схваліть пакети для наступної групи. 6. Окремо перевірте пристрої з помилками та застарілими звітами.

Не налаштовуйте загальне автоматичне схвалення всіх класифікацій для всіх комп’ютерів. Особливо обережно працюйте з оновленнями компонентів ОС і драйверами. Автоматизація корисна, коли повторює перевірене правило, а не прибирає контроль.

Для серверів однієї відмовостійкої системи використовуйте почергові вікна обслуговування. WSUS не керує залежностями застосунків і не гарантує, що одночасне перезавантаження вузлів буде безпечним. Як і під час побудови HA Kubernetes кластера, резервування потрібно перевіряти разом зі сценарієм втрати окремого вузла.

Перевірка стану

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

На клієнті перегляньте журнал Windows Update:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-WindowsUpdateClient/Operational'
    StartTime = (Get-Date).AddDays(-2)
} -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

На сервері запустіть перевірку стану WSUS:

& "$env:ProgramFiles\Update Services\Tools\WsusUtil.exe" checkhealth

Результати перевіряйте в журналі Application за подіями Windows Server Update Services. Додатково контролюйте IIS, стан пулу WsusPool, вільне місце та результати синхронізації.

Регулярне очищення

Перед обслуговуванням підготуйте резервну копію SUSDB за процедурою для вашого типу бази та зафіксуйте конфігурацію сервера. Для WID потрібна окрема підтримувана процедура резервування; не підміняйте її копіюванням відкритих файлів бази.

Приклад обмеженого очищення:

Import-Module UpdateServices

$wsus = Get-WsusServer -Name 'wsus01.ad.example.com' -PortNumber 8531 -UseSsl

$wsus | Invoke-WsusServerCleanup `
    -CleanupObsoleteComputers `
    -CleanupUnneededContentFiles `
    -DeclineExpiredUpdates

На давно необслуговуваному сервері навіть очищення може тривати довго або завершуватися тайм-аутом. Плануйте його поетапно, поза періодом активного розгортання. Відхилення замінених оновлень потребує окремої оцінки застосовності та стану клієнтів. Для великих інсталяцій також потрібне регулярне обслуговування індексів і статистики SUSDB за актуальною процедурою Microsoft.

5. Типові помилки

Комп’ютер не з’являється у WSUS. Перевірте застосування GPO, DNS, доступність портів, сертифікат і результуюче джерело оновлень. Для клонованих систем перевірте коректність підготовки образу та унікальність ідентичності клієнтів. Не видаляйте параметри реєстру навмання на всіх пристроях.

Клієнт бачить оновлення, але не завантажує файли. Перевірте, чи завершене завантаження на WSUS, чи доступний каталог вмісту та чи не заблокований HTTP-порт 8530. Помилкова вимога SSL для всього сайту IIS також може порушити роботу.

Оновлення схвалене, але не встановлюється. Схвалення не дорівнює негайному запуску. Перевірте членство в групі, застосовність пакета, графік, стан завантаження, очікуване перезавантаження та журнал клієнта.

Після ввімкнення HTTPS з’явилися помилки з’єднання. Зіставте ім’я в URL з SAN сертифіката, перевірте строк дії, довірені кореневі й проміжні сертифікати та правильність IIS-прив’язки. Не вимикайте перевірку сертифікатів як постійне рішення.

Сервер повертає HTTP 503. Перевірте WsusPool і події IIS. Причиною може бути зупинка пулу, нестача ресурсів або навантаження під час масового сканування. Не встановлюйте необмежені ліміти пам’яті без оцінки доступної RAM і причин зростання споживання.

Диск заповнився після синхронізацій. Перегляньте вибрані продукти, мови та класифікації. Не видаляйте вручну випадкові файли з WSUSContent: це створює розбіжності між базою та сховищем. Використовуйте штатне очищення й перевіряйте причини накопичення даних.

Потрібно повернути попередній стан після проблемного пакета. Відхилення оновлення у WSUS не видаляє його з клієнтів. Можливість і спосіб видалення залежать від конкретного пакета. До розгортання визначте процедуру відновлення та переконайтеся, що резервні копії придатні для повернення сервісу.

6. Висновок

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

Критерій готовності простий: тестовий пристрій отримує визначене оновлення саме з очікуваного джерела, встановлює його у погоджений час і повертає зрозумілий результат. Доповніть це регулярним очищенням, обслуговуванням бази, контролем сертифіката та перевіркою резервних копій. З огляду на статус WSUS як застарілої технології паралельно підтримуйте план переходу на інший засіб керування оновленнями — без втрати інвентаризації, пілотних груп і дисципліни розгортання.