У тому випадку, якщо всі комп'ютери в організації розташовані на одному майданчику, сервер оновлень WSUS призначається елементарно за допомогою групової політики. Якщо ж ІТ-інфраструктура копанні досить розподілена і для зниження навантаження на канали зв'язку використовуються кілька філіальних WSUS серверів, ситуація з призначенням WSUS сервера ускладнюється.
Найпростішим і логічним рішенням було б розбити всі комп'ютери організації на різні групи (зазвичай за територіальним / регіональному) ознакою, і сформувати з них окремі OU (контейнери) Active Directory. У цьому випадку на кожен OU можна призначити індивідуальну групову політику, яка вказує регіональний WSUS сервер, з якого необхідно закачувати оновлення. Така методика прив'язки до WSUS серверів використовується в більшості великих організації. Однак в компаніях, бізнес-процеси яких передбачають досить мобільний характер роботи співробітників, які прямують територіальними підрозділами зі своїми ноутбуками, у такої схеми роботи є свої мінуси. Адже в тому випадку, якщо користувач перемістився в іншу підмережа, його комп'ютер продовжує качати оновлення зі "свого" сервера WSUS, навантажуючи зайвим трафіком досить дорогі WAN-канали.
Примітка. Ми не розглядаємо варіант переміщення мобільних комп'ютерів між OU в силу своєї трудомісткості.Набагато більш елегантне рішення - прив'язати політику оновлень WSUS ні до OU, а до сайтів Active Directory, які за своєю природою враховують топологію мережі організації. В цьому випадку при переміщенні будь-якого комп'ютера в іншу підмережа (сайт), комп'ютер автоматично переходить і починає використовувати найближчий WSUS сервер.
У цій статті ми розглянемо методику призначень WSUS сервера через групові політики, ґрунтуючись на сайтах Active Directory.
В першу чергу необхідно переконатися, що сайти Active Directory заведені і до них прив'язані відповідні їм IP підмережі. Після конфігурації сайтів AD, комп'ютери при реєстрації в будь-який описаної підмережі будуть автоматично прив'язуватися до потрібного сайту.
Порада. Налаштування сайтів і підмереж виконується за допомогою mmc оснащення Active Directory Sites and Services.Наступний етап - створення групових політик, які задають параметри оновлення з серверів WSUS. Було б логічно створити єдину політику (наприклад, з ім'ям WSUS_Clients) з наступними настройками в розділі Computer Confuguration -> Administrative Templates -> Windows Components-> Windows Update. Ця політика містить типові настройки WSUS, однакові для всіх ПК організації.
- Allow auto installation: True
- Configure auto updates: 4 (Auto download & schedule install)
- Enable client side targeting: Computers
Далі для кожного сайту (або WSUS) сервера створимо окрему політику, яка вказує на конкретний WSUS сервер. Наприклад, політика GPO для регіону Irkutsk (з ім'ям Irkutsk_WSUS) буде виглядати так:
Specify intranet Microsoft update service location: Enabled
- Set the intranet update service for detecting updates: http: // IrkutskWSUS: 8530
- Set the intranet statistics server: http: // IrkutskWSUS: 8530
І, нарешті, потрібно призначити створені політики відповідним сайтам. За замовчуванням в консолі Group Policy management сайти AD не відображаються. Щоб відобразити їх, перейдіть в дереві GPM на рівень сайтів (Sites), і в контекстному меню Show Sites виберіть сайти, які потрібно показати в консолі.
Після того, як сайти Active Directory з'являться в консолі, клацніть ПКП за потрібною сайту, виберіть меню Link an Existing GPO і у вікні вкажіть групову політику, яку потрібно прив'язати до цього сайту. 
Таким чином можна організувати систему автоматичної прив'язки клієнтів до WSUS сервера, грунтуючись на сайті AD, в якому в даний момент знаходиться комп'ютер.
Порада. У тому випадку, якщо щось не буде працювати як очікується, діагностику можна провести за допомогою rsop.msc (Перевірка призначених політик) і команди nltest / dsgetsite (Дозволяє визначити сайт, в якому зареєстрований комп'ютер).
