WSUS - Управление клиентами с помощью Group Policy Preferences

imageЕсли вы имеете разветвлённую инфраструктуру WSUS с центральным сервером и некоторым количеством подчинённых серверов то, возможно, вы используете для централизации управления клиентами WSUS групповые политики. С появлением механизмов Group Policy Preferences (GPP) у нас появилась возможность вместо множества групповых политик настраивающих разные наборы клиентских компьютеров на ближайшие к ним WSUS сервера, - использовать одну групповую политику с рядом соответствующих настроек в зависимости от тех или иных условий. Рассмотрим пример создания такой единой групповой политики с следующими исходными данными:

  • Имеется головной сервер WSUS и несколько подчинённых ему серверов;
  • Все сервера расположены в разных физических локациях и обслуживают свой набор клиентских компьютеров, находящихся в разных IP диапазонах;
  • Один сервер WSUS может обслуживать несколько разных локаций, по каждой из которых необходимо иметь раздельную статусную информацию;
  • Есть необходимость разделения всех клиентов на всех WSUS серверах на логические категории для возможности разграничения процедур одобрения тех или иных наборов обновлений.

Для разграничения всех клиентов мы используем стандартный механизм создания групп компьютеров на сервере WSUS. Для примера создадим отдельные группы для каждой физической локации и дополнительно создадим две вспомогательные группы:

  • KOM-All-Test-New-Updates - для тестирования новых обновлений
  • KOM-All-Not-Install-IE9 – для настройки запрета установки IE9

image

Группы создаются на головном сервере и реплицируются с механизмом синхронизации на все подчинённые сервера.

Создание групп WSUS позволяет не только более гибко управлять одобрением/отклонением тех или иных обновлений но и получать сводную статусную информацию о результатах полноты установки обновлений в консоли WSUS

Итак, перейдём к настройке групповой политики. Для этого откроем консоль управления групповыми политиками (gpmc.msc) и создадим новый объект групповой политики, в котором сразу можно выключить настройки конфигурации пользователя, так как мы будем использовать только раздел конфигурации компьютера - Computer Configuration

В стандартных Административных шаблонах этой политики зададим основные параметры настройки клиента WSUS которые могут применяться ко всем без исключения клиентам WSUS. На скриншоте приведён пример настройки таких общих параметров:

image

Все остальные настройки, которые могут меняться в зависимости от условий, которые выдвигаются клиентами 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

image

Эти два параметра вынесены на верхний уровень настроек специально для наглядности и будут применяться ко всем компьютерам на которые будет действовать данная политика

Параметры сделаны отдельно для 32-битных (x86) и 64-битных (x64) систем, так как в зависимости от битности ОС используются разные ветки реестра. Для 64-битных клиентов WSUS во всех идущих далее по описанию ключах реестра добавляется дополнительное условие нацеливания Item-level targeting

image

Это условие построено на проверке наличия ветки реестра SOFTWAREWow6432Node в кусте HKEY_LOCAL_MACHINE, то есть, если эта ветка существует, значит обработка политики происходит на 64-битном клиенте

image

Помимо указанных двух параметров в корне настроек вы можете видеть группы, которые сделаны для того, чтобы отделить клиентов в зависимости от сервера WSUS к которому они должны принадлежать. Для наглядности эти группы именованы так же как и сами сервера WSUS. Для того чтобы отнести клиентов к той или иной группе настроек мы включаем нацеливание по диапазонам IP адресов клиентов. То есть вложенные в эту группу настройки будут применяться к клиентам только в том случае, если они входят в соответствующие IP диапазоны.

image

Теперь заглянем внутрь любой из таких серверных групп. Внутри каждой группы сделаны настройки на конкретный сервер для того, чтобы клиенты знали куда им ходить за обновлениями и куда отправлять статусную информацию. Это 2 параметра - 4 настройки ключей реестра (2 ключа для 32-битных клиентов и 2 ключа для 64-битных клиентов) со следующими настройками:

Куст реестра: HKEY_LOCAL_MACHINE

Ветки реестра
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate

Ключ реестра: WUServer REG_SZ = https://KOM-SRV-WSUS:8531
Ключ реестра: WUStatusServer REG_SZ = https://KOM-SRV-WSUS:8531

image

Внутри каждой группы уровня настроек серверов создаём подгруппы с помощью которых будут настроены параметры реестра для работы механизма WSUS client-side targeting, то есть для автоматического распределения клиентов по группам WSUS, о которых мы говорили в самом начале. В нашем случае нацеливание GPP выполнено опять-таки на IP адрес клиента, при этом надо понимать что IP диапазон который мы указываем в подгруппе должен входить в логику диапазонов группы верхнего уровня.

image

Внутри подгруппы создаём параметры для 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) тоже имеет своё определяющее значение.
image

На этом уровне в нашем примере мы комбинируем разные варианты значения одного и того же параметра реестра в зависимости от разных условий. Например, за дополнительное условие взято членство учетной записи компьютера в доменной группе безопасности. То есть в данном случае значение ключа TargetGroup будет установлено в “KOM-AD01;KOM-All-Test-New-Updates” при условии, если компьютер имеет 64-битную ОС и входит в соответствующую группу тестовых компьютеров в домене.  

image

Обратите внимание на, то что при указании доменной группы безопасности лучше не вводить её название прямо в поле Group, а пользоваться кнопкой обзора, чтобы Tardeting Editor корректно определил SID этой группы.

На этом настройку GPP можно считать законченной и для того, чтобы параметры реестра для механизма авто-назначения в группы WSUS применившись на клиентских компьютерах начали работать, – необходимо переключить сервер WSUS в режим управления групповыми политиками. Для этого в консоли WSUS - Параметры > Компьютеры (Options > Computers) включим соответствующую настройку:

image

Обратите внимание, на то что эту настройку нужно изменить на всех серверах WSUS.

Результат в консоли WSUS мы сможем увидеть далеко не сразу, так как для вступления новых параметров реестра на клиентах в силу требуется как минимум перезапуск клиентской службы Windows Update (wuauserv), что например, на рабочих станциях достигается элементарным циклом выключения/включения компьютера пользователями. Возможно также на некоторых “непослушных” клиентах потребуется сбросить авторизацию на сервере WSUS

wuauclt /resetauthorization /detectnow

Не забывайте так же про то, что для того чтобы созданная нами групповая политика успешно работала, – клиенты должны уметь работать с GPP, особенно это касается уже устаревших на сегодня систем типа Windows XP.

Update 21.10.2001

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

Источники информации:

Всего комментариев: 13 Комментировать

  1. Андрей /

    Супиргуд, начинаем мероприятия на след неделе АГМП

  2. Стас /

    как то слишком много манипуляций с реестром,

    чем плох встроенный механизм wsus, c целевыми группами?

    1. Алексей Максимов /

      Он плох тем, что состав групп постоянно надо поддерживать в ручную если добавляются новые компьютеры или делается сброс авторизации некоторых компьютеров. Как всем известно, WSUS не имеет нормальных функций делегирования административных действий, и в условиях, когда один сервер используется для обслуживания нескольких локаций, поддержание состава групп в ручную может стать головной болью для администратора. Если для вас это не очевидно, вы просто никогда не сталкивались с такой инфраструктурой WSUS.

      1. Ivan /

        Всегда считал, что если компы раскиданы по ОУ и к каждому прилинкована политика с TargetGroup, то при перемещении компа из одного ОУ в другой он попадет и в другую группу на WSUS - это заблуждение?

  3. UnZipych /

    Отличный обзор применения Item-level targeting GPP!
    Благодарю!

  4. equinox (@equinoxnet) /

    Спасибо за замечательную статью! Планирую развернуть подобное в доменной сети. Начну тестировать на виртуальных репликах WSUS уже сегодня.

  5. equinoxnet /

    "Update 21.10.2001" - наверно, имелось в виду 21.10.2011?

    1. Алексей Максимов /

      Да. Так оно и бЫло :)

  6. Алексей Максимов /

    Ivan, читайте первый абзац заметки. Если вам надо сделать 15 групп то по вашей методике вам понадобится 15 объектов GPO. С использованием GPP всё делается с помощью одного объекта GPO.

  7. dougine /

    А как быть со свежеустановленными XP, на которых еще нет КВ943729 (чтобы он умел понимать GPP)? Все так то здорово и по уму, но вот адрес WSUS сервера задается здесь именно через GPP, соответственно, клиент не заносит себе адрес WSUS-а, и все - windowsupdate.log показывает, что клиент пытается обновиться через инет, там закрыто и т.д.
    По идее, надо через GPO первым делом воткнуть именно этот апдейт, только вот не факт, что он не потребует еще какого-нибудь предварительно установленного..

    Как решается такая проблема? Поделитесь опытом внедрения изложенного в статье..

    1. Алексей Максимов /

      Развертывание ОС у нас производится с заранее подготовленного образа, с системой в которую данное обновление предустановлено. Если же вы производите установку ОС вручную, то разумеется, для того чтобы GPP заработали - нужно установить требуемое для этого обновление вручную.

  8. dougine /

    Спасибо, данный вариант понятен..

  9. equinoxnet /

    Из текста статьи неясно, какая применяется иерархическая структура WSUS серверов? Подчиненные (автономные) или же режим реплики?

Добавить комментарий