Привязка серверов WSUS к различным сайтам Active Directory

В том случае, если все компьютеры в организации расположены на одной площадке, сервер обновлений 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 (позволяет определить сайт, в котором зарегистрирован компьютер).