Якщо ви маєте розгалужену інфраструктуру WSUS з центральним сервером і деякою кількістю підлеглих серверів то, можливо, ви використовуєте для централізації управління клієнтами WSUS групові політики. З появою механізмів Group Policy Preferences (GPP) у нас з'явилася можливість замість безлічі групових політик налаштовують різні набори клієнтських комп'ютерів на найближчі до них WSUS сервера, - використовувати одну групову політику з низкою відповідних налаштувань в залежності від тих чи інших умов. Розглянемо приклад створення такої єдиної групової політики з наступними вихідними даними:
Для розмежування всіх клієнтів ми використовуємо стандартний механізм створення груп комп'ютерів на сервері WSUS. Для прикладу створимо окремі групи для кожної фізичної локації і додатково створимо дві допоміжні групи:
- KOM-All-Test-New-Updates - для тестування нових оновлень
- KOM-All-Not-Install-IE9 - для настройки заборони установки IE9
Групи створюються на головному сервері і реплікуються з механізмом синхронізації на все підлеглі сервера.
Створення груп WSUS дозволяє не тільки більш гнучко управляти схваленням / відхиленням тих чи інших оновлень але і отримувати зведену статусну інформацію про результати повноти установки оновлень в консолі WSUS
Отже, перейдемо до налаштування групової політики. Для цього відкриємо консоль управління груповими політиками (gpmc.msc) і створимо новий об'єкт групової політики, в якому відразу можна вимкнути налаштування конфігурації користувача, так як ми будемо використовувати тільки розділ конфігурації комп'ютера - Computer Configuration
У стандартних Адміністративних шаблонах цієї політики задамо основні параметри налаштування клієнта WSUS які можуть застосовуватися до всіх без винятку клієнтам WSUS. На скріншоті наведено приклад налаштування таких загальних параметрів:
Всі інші настройки, які можуть змінюватися в залежності від умов, які висуваються клієнтами WSUS, ми вносимо в GPP в розділ настройок Preferences> Windows Settings> Registry
Створимо в корені дерева цих налаштувань 2 параметра - 4 налаштування ключів реєстру (2 ключа для 32-бітових клієнтів і 2 ключа для 64-бітових клієнтів) з наступними настройками:
Кущ реєстру: HKEY_LOCAL_MACHINE
гілки реєстру
для x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
для x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Ключ реєстру: TargetGroupEnabled REG_DWORD = 1
гілки реєстру
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdateAU
Ключ реєстру: UseWUServer REG_DWORD = 1
Ці два параметри винесені на верхній рівень налаштувань спеціально для наочності та будуть застосовуватися до всіх комп'ютерів на які діятиме дана політика
Параметри зроблені окремо для 32-бітових (x86) і 64-бітових (x64) систем, так як в залежності від битности ОС використовуються різні гілки реєстру. Для 64-бітних клієнтів WSUS у всіх, хто йде далі за описом ключах реєстру додається додаткова умова націлювання Item-level targeting
Ця умова побудовано на перевірці наявності гілки реєстру SOFTWAREWow6432Node в кущі HKEY_LOCAL_MACHINE. тобто, якщо ця гілка існує, значить обробка політики відбувається на 64-бітному клієнта
Тепер заглянемо всередину будь-якої з таких серверних груп. Усередині кожної групи зроблені настройки на конкретний сервер для того, щоб клієнти знали куди їм ходити за оновленнями і куди відправляти статусну інформацію. Це 2 параметра - 4 налаштування ключів реєстру (2 ключа для 32-бітових клієнтів і 2 ключа для 64-бітових клієнтів) з наступними настройками:
Кущ реєстру: HKEY_LOCAL_MACHINE
гілки реєстру
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Усередині підгрупи створюємо параметри для WSUS client-side targeting:
Кущ реєстру: HKEY_LOCAL_MACHINE
гілки реєстру
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Ключ реєстру: TargetGroup REG_SZ = KOM-AD01
Ключ реєстру: TargetGroup REG_SZ = KOM-AD01; KOM-All-Test-New-Updates
Ключ реєстру: TargetGroup REG_SZ = KOM-AD01; KOM-All-Not-Install-IE9
Якщо клієнт повинен входити в кілька груп, то їх назви перераховуються в значенні через крапку з комою. При цьому якщо групи WSUS мають вкладену структуру, вказується кінцеве ім'я групи (без інформації про ієрархію). Цю особливість необхідно враховувати в процесі планування і створення структури груп WSUS.
Важливо також пам'ятати, що порядок застосування GPP (Order) теж має своє визначальне значення.
На цьому рівні в нашому прикладі ми комбінуємо різні варіанти значення одного і того ж параметра реєстру в залежності від різних умов. Наприклад, за додаткову умову взято членство облікового запису комп'ютера в доменній групі безпеки. Тобто в даному випадку значення ключа TargetGroup буде встановлено в "KOM-AD01; KOM-All-Test-New-Updates" за умови, якщо комп'ютер має 64-бітну ОС і входить до відповідної групи тестових комп'ютерів в домені.
Зверніть увагу на, то що при вказівці доменної групи безпеки краще не вводити її назву прямо в поле Group, а користуватися кнопкою огляду, щоб Tardeting Editor коректно визначив SID цієї групи.
На цьому настройку GPP можна вважати закінченою і для того, щоб параметри реєстру для механізму авто-призначення в групи WSUS застосувати на клієнтських комп'ютерах почали працювати, - необхідно переключити сервер WSUS в режим управління груповими політиками. Для цього в консолі WSUS - Параметри> Комп'ютери (Options> Computers) включимо відповідні налаштування:
Зверніть увагу, на те що це налаштування потрібно змінити на всіх серверах WSUS.
wuauclt / resetauthorization / detectnow
Не забувайте так само про те, що для того щоб створена нами групова політика успішно працювала, - клієнти повинні вміти працювати з GPP, особливо це стосується вже застарілих на сьогодні систем типу Windows XP.
Може виникнути ситуація, коли буде потрібно окреме налаштування параметра групової політики Allow non-administrators to receive update notifications зі складу Адміністративних шаблонів (в розділі Computer Configuration> Administrative Templates> Windows Components> Windows Update). Цей параметр позначає можливість бачити непривілейованих користувачам оповіщення клієнта WSUS про доступність нових оновлень і ініціювати процес установки оновлень. Для робочих станцій це нормальна ситуація, а ось на термінальних серверах це може стати справжнім головним болем і тому для серверів цей параметр краще вимикати. Тобто можна в Адміністративних шаблонах цей параметр залишити ненастроєного, а налаштовувати його ключем реєстру через вищеописаний механізм GPP:
Кущ реєстру: HKEY_LOCAL_MACHINE
гілки реєстру
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Ключ реєстру: ElevateNonAdmins REG_DWORD 1 або 0
Можливі значення ключа:
- 1 - Включено. Користувачі отримують оповіщення клієнта WSUS про доступність свіжих оновлень і можуть ініціювати процес установки оновлень
- 0 - Виключено. Його користувачі не бачать сповіщень і тільки адміністратори можуть керувати процесом установки оновлень.
Таким чином можна створити відповідні правила обробки GPP з націлюванням наприклад на версію ОС (серверна / НЕ серверна) ну або наприклад на ім'я комп'ютера якщо у вашій організації діють якісь жорсткі стандарти іменування комп'ютерів. Тут вже все залежить від вашої фантазії.
У своєму випадку я вирішив цю проблему трохи інакше - для термінальних серверів у мене налаштована окрема групова політика з замиканням обробки параметрів на себе, тобто її параметри завжди будуть перекривати параметри загальної політики WSUS. І вже в цій спеціальній політиці цей параметр у мене вимкнений і користувачам термінального сервера не докучають оповіщення клієнта WSUS.
Як епілог, передбачаючи репліки типу "Все гнучкіше робиться в SCCM", зазначу відразу те, що ця замітка розрахована на тих, хто з якихось причин не може використовувати подібні рішення. Як бачите, все настройки зроблені в рамках стандартних функціональних можливостей Windows Server.
Поділитися посиланням на цю запис:
Завжди вважав, що якщо комп'ютери розкидані по ОУ і до кожного прілінкованние політика з TargetGroup, то при переміщенні компа з одного ОУ в інший він потрапить і в іншу групу на WSUS - це помилка?
Відмінний огляд застосування Item-level targeting GPP!
Дякую!
Як вирішується така проблема? Поділіться досвідом впровадження викладеного в статті ..
Розгортання ОС у нас проводиться з заздалегідь підготовленого образу, з системою в яку дане оновлення встановлено. Якщо ж ви робите установку ОС вручну, то зрозуміло, для того щоб GPP заробили - потрібно встановити необхідне для цього оновлення вручну.
Спасибі, даний варіант зрозумілий ..