Установка и настройка WSUS на платформе Windows Server 2012 / 2012R2

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

1. Что, как, когда и зачем нужно обновлять?

Ставить все подряд обновления на все подряд ПК это плохая идея. Правильнее будет, если Вы сгруппируете ПК по определенным признакам (например департаменты или ПО которое используется на ПК) и в каждой группе создадите хотя бы одну тестовую машину.

Если обновления на нее легли “ровно” – все ПО работает, можно устанавливать обновления на рабочие станции в этой группе. Это не дает 100% уверенности, но и достаточно просто.

С серверами дело несколько сложнее – воссоздать в тестовой среде реальный продуктивный сервер задача сомнительная, да и полноценно проверить работу сервиса после установки обновлений не так уж просто. С другой стороны, серверов не так много как рабочих станций, и обновлять их в “ручном режиме” сделав предварительно резервную копию вполне нормальный вариант.

Рекомендую заиметь регламент, где эти процедуры будут описаны.

Приведу реальный пример – CU для Exchange и SharePoint распространяются через Mircosoft Download Center, а через Windows Update – нет. Это очень правильное решение, т.к. их установка должна быть плановой и обдуманной.

2. Подготовка и установка

Подготовку начнем с установки виртуальной машины, ОС (в моем случае это готовый шаблон WS 2012 R2 Datacenter) и ввода ее в домен.

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

Что касается архитектуры – я буду использовать единственный сервер. Если у Вас филиалы, то разумно разместить по отдельному WSUS серверу в каждом филиале, в котором более 10 сотрудников. У

правлять этими серверами можно централизованно, но также возможно делегировать права местным администраторам.

Если Вы обновляете WSUS, полезной будет эта информация.

Обратите внимание, один клиент может работать только с одним WSUS.

Что касается системных требований, то обычно говорят о требованиях, аналогичных требованиям ОС, но на практике, WSUS который использует WID и обслуживает несколько десятков клиентов, потребляет ~2Gb+ оперативной памяти.

Нагрузка на процессор и дисковую с-му минимальная. Тем не менее, WSUS и WID бывают “особо опасны”, например при синхронизации нового продукта или класса: 47

Проблема решается тем, что WSUS активен по ночам, и запросто может “отжирать” память и процессоры у других виртуалок.

Размещать роль WSUS на серверах с другими ролями не слишком хорошо, но в ряде сценариев это необходимый шаг (работает нормально).

Я не стану тратить свое и ваше время на описание добавления роли и прохождение Мастера, процесс достаточно интуитивен и комментировать там особо нечего. Единственное что я там указал – это для каких продуктов будем использовать обновления.

3. Настройка сервера Т.к. среда у меня тестовая и используется всего две ОС (2012 и 2012R2) я включу автоматическое одобрение для всех обновлений.

Еще раз хочу подчеркнуть, что в продуктивное среде делать подобное строго не рекомендуется.

37

Компьютеры будут настроены на использование WSUS с помощью групповой политики, укажем это в настройках:

31Одобрим предложенные обновления:

32 Теперь настроим электронную почту:

44 45

После этого, будем автоматически получать отчеты такого вида: 43 4. Настройка клиентов

Для настройки клиентов напишем и применим такую групповую политику (Computer Configuration – Policies – Administrative Templates – Windows Components – Windows Update):

34 35 При настройке политики советую внимательно ознакомиться с содержимым каждой опции и выбрать подходящие для Вашего случая.

В документации, расположение сервера рекомендуется указывать как http://server . Я всегда указывал здесь FQDN, т.к. использовал SSL. Сегодня, готовя материал для статьи в лабе, я столкнулся с тем, что если указать http://server или http://server.domain.name на клиентах сервис не работал и в логах были ошибки 0x80072ee2 и т.п.

Решить получилось указанием порта 8530. Примите к сведению, и можете в комментариях писать как работает в вашем случае.

Обновим политику на клиенте с помощью gpupdate /force и посмотрим результат с помощью rsop.msc и Панели управления (скриншот от моей прошлой статьи):

Чтобы принудительно запустить синхронизацию можем воспользоваться командой wuauclt , ее основные ключи, описание которых я давно нашел в интернетах:

/DetectNow – Запустить немедленный опрос сервера WSUS на наличие обновлений

/resetAuthorization – Сбросить авторизацию на сервере и клиенте. Фактически это новая регистрация на сервере WSUS. Полезна когда клиент подглюкивает, удаляем его на сервере и командой wuauclt /detectnow /resetAuthorization заново регистрируем на сервере с одновременным запросом списка обновлений

/reportnow Сбросить статистику на сервер

/ShowSettingsDialog – Показывает диалог настройки расписания установки обновлений

/ResetEulas – сбросить соглашение EULA для обновлений

/ShowWU – переход на сайт обновлений MS

/ShowWindowsUpdate – переход на сайт обновлений MS

/UpdateNow – Немедленно запускает процесс обновления, аналогичен клику кнопки в окне уведомлений о наличии обновлений

/DemoUI – Показывает значок в трее — диалог настройки расписания установки обновлений или установки в зависимости от статуса

На клиенте, есть весьма информативный лог C:WindowsWindowsUpdate.log

Обновления на клиенте качаются в папку  C:WindowsSoftwareDistributionDownload , имена – это значения хэшей, если что. Выглядит это дело примерно так: 33 Если так получилось что Ваш старый WSUS помер, и Вы подняли новый, то исправить работу клиентов поможет вот эта инфа.

Использование SSL: Возможно использование SSL с WSUS, для этого в IIS и нужно подписать сайт WSUS правильным сертификатом (скриншот от моей прошлой статьи):

Для подсайтов:

ApiRemoting30

ClientWebService

DSSAuthWebService

ServerSyncWebService

SimpleAuthWebService

.. нам нужно включить использование SSL и “игнорирование сертификата клиента”:

Затем применим изменения, перезапустим IIS. Используем WsusUtil.exe configuressl :

Теперь можно открыть консоль WSUS на другом ПК и убедиться что соединение работает по защищенному порту 8531 (при подключении указываем FQDN, если у сертификата нет альтернативного SAN):

36 В групповой политике поправим http на https и 8530 на 8531 а также пропишем в качестве имени FQDN: 38

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

Полезная информация: http://technet.microsoft.com/ru-ru/windowsserver/bb332157.aspx

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.