Налаштування клієнтів WSUS за допомогою групових політик

В одній з попередніх статей ми докладно описали процедуру установки сервера WSUS на базі Windows Server 2012 R2 / 2016. Після того, як ви налаштували сервер, потрібно налаштувати Windows-клієнтів (сервера і робочі станції) на використання сервера WSUS для отримання оновлень, щоб клієнти отримували поновлення з внутрішнього сервера оновлень, а не з серверів Microsoft Update через Інтернет. У цій статті ми розглянемо процедуру настройки клієнтів на використання сервера WSUS за допомогою групових політик домену Active Directory.

зміст:

  • Групова політика WSUS для серверів Windows
  • Політика установки оновлень WSUS для робочих станцій
  • Призначаємо політики WSUS на OU Active Directory

Групові політики AD дозволяють адміністратору автоматично призначити комп'ютери в різні групи WSUS, позбавляючи його від необхідності ручного переміщення комп'ютерів між групами в консолі WSUS і підтримки цих груп в актуальному стані. Призначення клієнтів до різних цільових груп WSUS грунтується на мітці в реєстрі на клієнті (мітки задаються груповою політикою або прямим редагуванням реєстру). Такий тип співвіднесення клієнтів до груп WSUS називається client side targeting (Орієнтування на стороні клієнта).

Передбачається, що в нашій мережі будуть використовуватися дві різні політики поновлення - окрема політика установки оновлень для серверів (Servers) І для робочих станцій (Workstations). Ці дві групи потрібно створити в консолі WSUS в секції All Computers.

Порада. Політика використання сервера оновлень WSUS клієнтами багато в чому залежить від організаційної структури OU в Active Directory і правил установки оновлення в організації. У цій статті ми розглянемо лише окремий випадок, що дозволяє зрозуміти базові принципи використання політик AD для установки оновлень Windows.

В першу чергу необхідно вказати правило угруповання комп'ютерів в консолі WSUS (targeting). За замовчуванням в консолі WSUS комп'ютери розподіляються адміністратором по групах вручну (server side targeting). Нас це не влаштовує, тому вкажемо, що комп'ютери розподіляються в групи на основі client side targeting (за певним ключу в реєстрі клієнта). Для цього в консолі WSUS перейдіть в розділ Options і відкрийте параметр Computers. Поміняйте значення на Use Group Policy or registry setting on computers (Використовувати на комп'ютерах групову політику або параметри реєстру). 

Тепер можна створити GPO для настройки клієнтів WSUS. Відкрийте доменну консоль управління груповими політиками (Group Policy Management) і створіть дві нові групові політики: ServerWSUSPolicy і WorkstationWSUSPolicy.

Групова політика WSUS для серверів Windows

Почнемо з опису серверної політики ServerWSUSPolicy.

Налаштування групових політик, що відповідають за роботу служби оновлень Windows, знаходяться в розділі GPO: Computer Configuration -> Policies-> Administrative templates-> Windows Component-> Windows Update (Конфігурація комп'ютера -> Адміністративні шаблони -> Компоненти Windows -> Windows Update).

В нашій організації ми припускаємо використовувати дану політику для установки оновлень WSUS на сервера Windows. Передбачається, що всі потрапляють під цю політику комп'ютери будуть віднесені до групи Servers в консолі WSUS. Крім того, ми хочемо заборонити автоматичну установку оновлень на серверах при їх отриманні. Клієнт WSUS повинен просто завантажити доступні оновлення на диск, відобразити сповіщення про наявність нових оновлень в системному треї і очікувати запуску установки адміністратором (ручний або віддаленої за допомогою модуля PSWindowsUpdate) для початку установки. Це означає, що продуктивні серверу не будуть автоматично встановлювати оновлення і перезавантажуватися без підтвердження адміністратора (зазвичай ці роботи виконуються системним адміністратором в рамках щомісячних планових регламентних робіт). Для реалізації такої схеми задамо наступні політики:

  • Configure Automatic Updates (Автоматичне оновлення): Enable. 3 - Auto download and notify for install (Автоматично завантажувати оновлення і повідомляти про їх готовність до установки) - клієнт автоматично завантажує нові оновлень і оповіщає про їхню появу;
  • Specify Intranet Microsoft update service location (Вказати розміщення служби оновлень Майкрософт в інтрамережі): Enable.  Set the intranet update service for detecting updates (Вкажіть службу оновлень в інтрамережі для пошуку оновлень): http://srv-wsus.winitpro.ru:8530, Set the intranet statistics server (Вкажіть сервер статистики в інтрамережі): http://srv-wsus.winitpro.ru:8530 - тут потрібно вказати адресу вашого сервера WSUS і сервера статистики (зазвичай вони збігаються);
  • No auto-restart with logged on users for scheduled automatic updates installations (Не виконувати автоматичну перезавантаження при автоматичній установці оновлень, якщо в системі працюють користувача): Enable - заборонити автоматичну перезавантаження при наявності сесії користувача;
  • Enable client-side targeting (Дозволити клієнту приєднання до цільової групи): Enable. Target group name for this computer (Ім'я цільової групи для даного комп'ютера): Servers - в консолі WSUS віднести клієнти до групи Servers.
Примітка. Під час налаштування політики поновлення радимо уважно ознайомитися з усіма параметрами, доступними в кожній з опцій розділу GPO Windows Update і задати відповідні для вашої інфраструктури і організації параметри.

Політика установки оновлень WSUS для робочих станцій

Ми припускаємо, що поновлення на клієнтські робочі станції, на відміну від серверної політики, будуть встановлюватися автоматично вночі відразу після отримання оновлень. Комп'ютери після установки оновлень повинні перезавантажуватися автоматично (попереджаючи користувача за 5 хвилин).

У даній GPO (WorkstationWSUSPolicy) ми вказуємо:

  • Allow Automatic Updates immediate installation (Дозволити негайну установку автоматичних оновлень): Disabled - заборона на негайну установку оновлень при їх отриманні;
  • Allow non-administrators to receive update notifications (Дозволити користувачам, які не є адміністраторами, отримувати повідомлення про оновлення): Enabled - відображається не-адміністраторам попередження про появу нових оновлень і дозволити їх ручну установку;
  • Configure Automatic Updates: Enabled.   Configure automatic updating: 4 - Auto download and schedule the install. Scheduled install day: 0 - Every day. Scheduled install time: 5:00 - при отриманні нових оновлень клієнт скачує в локлаьний кеш і планує їх автоматичну установку на 5:00 ранку;
  • Target group name for this computer: Workstations - в консолі WSUS віднести клієнта до групи Workstations;
  • No auto-restart with logged on users for scheduled automatic updates installations: Disabled - система автоматично перезавантажиться через 5 хвилин після закінчення установки оновлень;
  • Specify Intranet Microsoft update service location: Enable. Set the intranet update service for detecting updates: http://srv-wsus.winitpro.ru:8530, Set the intranet statistics server: http://srv-wsus.winitpro.ru:8530 -адреса корпоративного WSUS сервера.

У Windows 10 1607 і вище, не дивлячись на те, що ви вказали їм отримувати оновлення з внутрішнього WSUS, все ще можуть намагатися звертатися до серверів Windows Update в інтернеті. Ця "фіча" називається Dual Scan. Для відключення отримання оновлень з інтернету потрібно додатково включати політику Do not allow update deferral policies to cause scans against Windows Update (посилання).

Порада. Щоб поліпшити "рівень пропатченний" комп'ютерів в організації, в обох політиків можна налаштувати примусовий запуск служби оновлень (wuauserv) на клієнтах. Для цього в розділі Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services знайдіть службу Windows Update і задайте для неї автоматичний запуск (Automatic).

Призначаємо політики WSUS на OU Active Directory

Наступний крок - призначити створені політики на відповідні контейнери (OU) Active Directory. У нашому прикладі структура OU в домені AD максимально проста: є два контейнери - Servers (в ньому містяться всі сервера організації, крім контролерів домену) і WKS (Workstations -Комп'ютери користувачів).

Порада. Ми розглядаємо лише один досить простий варіант прив'язки політик WSUS до клієнтів. У реальних організаціях можливо прив'язати одну політику WSUS на всі комп'ютери домену (GPO з настройками WSUS вішається на корінь домена), рознести різні види клієнтів з різних OU (як в нашому прикладі - ми створили різні політики WSUS для серверів і робочих станцій), у великих розподілених доменах можна прив'язувати різні WSUS сервера до сайтів AD, або ж призначати GPO на підставі фільтрів WMI, або скомбінувати перераховані способи.

Щоб призначити політику на OU, клацніть в консолі управління груповими політиками за потрібною OU, виберіть пункт меню Link as Existing GPO і виберіть відповідну політику.

Порада. Не забудьте про окрему OU з контролерами домену (Domain Controllers), в більшості випадків на цей контейнер слід прив'язати "серверну" політику WSUS.

Точно таким же способом потрібно призначити політику WorkstationWSUSPolicy на контейнер AD WKS, в якому знаходяться робочі станції Windows.

Залишилося відновити групові політики на клієнтах для прив'язки клієнта до сервера WSUS:

gpupdate / force

Всі настройки системи оновлень Windows, які ми поставили груповими політиками повинні з'явиться в реєстрі клієнта в гілці HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ WindowsUpdate.

Даний reg файл можна використовувати для перенесення налаштувань WSUS на інші комп'ютери, на яких не вдається налаштувати параметри оновлень за допомогою GPO (комп'ютери в робочій групі, ізольованих сегментах, DMZ і т.д.)

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ WindowsUpdate]
"WUServer" = "http://srv-wsus.winitpro.ru:8530"
"WUStatusServer" = "http://srv-wsus.winitpro.ru:8530"
"UpdateServiceUrlAlternate" = ""
"TargetGroupEnabled" = dword: 00000001
"TargetGroup" = "Servers"
"ElevateNonAdmins" = dword: 00000000
[HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ WindowsUpdate \ AU]
"NoAutoUpdate" = dword: 00000000 -
"AUOptions" = dword: 00000003
"ScheduledInstallDay" = dword: 00000000
"ScheduledInstallTime" = dword: 00000003
"ScheduledInstallEveryWeek" = dword: 00000001
"UseWUServer" = dword: 00000001
"NoAutoRebootWithLoggedOnUsers" = dword: 00000001

Також зручно контролювати застосовані настройки WSUS на клієнтах за допомогою rsop.msc.

І через деякий час (залежить від кількості оновлень і пропускної здатності каналу до сервера WSUS) потрібно перевірити в треї наявність спливаючого сповіщень про наявність нових оновлень. В консолі WSUS у відповідних групах повинні з'явитися клієнти (в табличному вигляді відображається ім'я клієнта, IP, ОС, відсоток їх "пропатченний" і дата останнього оновлення статусу). Оскільки ми політиками прив'язали комп'ютери і сервери до різних груп WSUS, вони будуть отримувати тільки оновлення, схвалені до установки на відповідні групи WSUS.

Примітка. Якщо на клієнті оновлення не з'являються, рекомендується уважно вивчити на проблемному клієнта лог служби оновлень Windows (C: \ Windows \ WindowsUpdate.log). Зверніть увагу, що в Windows 10 (Windows Server 2016) використовується інший формат журналу оновлень WindowsUpdate.log. Клієнт викачує поновлення в локальну папку C: \ Windows \ SoftwareDistribution \ Download. Щоб запустити пошук нових оновлень на WSUS сервері, потрібно виконати команду:

wuauclt / detectnow

Також іноді доводиться примусово перереєструвати клієнта на сервері WSUS:

wuauclt / detectnow / resetAuthorization

В особливо складних випадках можна спробувати полагодити службу wuauserv так. При виникненні помилки 0x80244010 при отриманні оновлень на клієнтах, спробуйте змінити частоту перевірки оновлень на сервері WSUS за допомогою політики Automatic Update detection frequency.

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