Управление обновлениями через ConfigMgr - часть 1

Введение

По моему опыту инженера поддержки в даже больших и зрелых компаниях администраторы пользуются WSUS для доставки обновлений ПО Microsoft при имеющейся инфраструктуре Configuration Manager (ConfigMgr). Причин этому много, но чаще всего называется простота управления WSUS. Это, разумеется, правда, однако ConfigMgr позволяет выстроить процесс развертывания обновлений более правильно с точки зрения ITIL/MOF, а также имеет более богатую отчётность. Например, ConfigMgr позволяет составлять и хранить списки обновлений в виде групп – а ведь именно список обновлений должен проходить цикл тестирования и внутреннего утверждения. Для WSUS список придётся держать отдельно, в лучшем случае это делается автоматизированно скриптами, в худшем – поддерживается вручную.

Кроме того, многие администраторы (и я когда-то был в их числе) попросту не понимают, как работает ConfigMgr в связке с WSUS – и я не видел ни одного достойного материала на эту тему, тем более на русском языке.

Чтобы облегчить переход на более правильную схему доставки и установки обновлений, я решил написать данный цикл статей. Помимо непосредственных руководств к действию я собрал в них многочисленные подводные камни, щедро разбросанные разработчиками из разных команд и почему-то никем ещё не собранные в одной статье. Версия ConfigMgr, о которой пойдет речь – не ниже ConfigMgr 2012 SP1. Удачного чтения!

Важный момент: в этих статьях не будет пошаговых инструкций как установить SUP или развернуть обновления – на эту тему материалов в Сети предостаточно, например в ConfigMgr Survival Guide.

Развертывание инфраструктуры SUP в ConfigMgr

Начнём мы с технической настройки серверной части и поговорим о том, как всё это работает

Кау устроены обновления

Перед тем, как переходить к описанию работы инфраструктуры, напомню две составляющих любого обновления:

1)      Собственно дистрибутив обновления: теоретически это может быть что угодно. На практике это .msu, .cab, .msp и .exe-файлы, однако теоретически ничего не мешает распространять любой скрипт. Дистрибутив должен быть подписан цифровой подписью, чтобы исключить его подмену во время закачки – обновления, выпущенные Microsoft, само собой, подписаны Microsoft, и клиенты доверяют им по умолчанию. Сторонние подписи по умолчанию не принимаются.

2)      Метаданные обновления: название, описание (на разных языках), номера статьи KB и бюллетеня безопасности и прочее, что вы можете увидеть в консолях WSUS или ConfigMgr, но самое важное - правила применимости (Installable Rules) и детектирования (Installed Rules) установки, командная строка на установку или хэндлер, а также правила замены (supersedence).

N.B. Те, кто работают с объектами Application в ConfigMgr легко узнают, откуда взят этот концепт.

Обновления делятся по:

1)      Продуктам

2)      Классификациям

3)      Языкам

С конкретным обновлением может произойти следующее:

1)      Release: выпуск обновления – добавление его метаданных в БД Microsoft Update и выкладывание дистрибутива для закачки.

2)      Revise: перевыпуск обновления – замена обновления под тем же номером KB (обычно происходит в результате обнаружения проблем после релиза).

3)      Supersede: замена обновления – релиз нового обновления, которое полностью заменяет старое.

4)      Expire: устаревание обновления – прекращение его распространения с последующим удалением (например, в случае обнаружения фундаментальной проблемы). Также автоматически устаревают старые ревизии обновлений – только последняя ревизия доступна для установки.

Важно также понимать, что обновление может быть устаревшим (expired) в локальной инфраструктуре и распространяться при этом в Microsoft Update. Более того, статус устаревания может быть разный в разных локальных системах.

Как работает инфраструктура обновлений

Одним из компонентов ОС Windows является Windows Update Agent (WUA). Работает данный компонент в одной из служб Windows и отвечает за все процессы установки обновлений.

Агент имеет собственную папку в папке установки ОС (%Windir%\SoftwareDistribution), в которой располагается его БД Jet (\DataStore), а также прочие подпапки, описание которых выходит за рамки данной статьи. Также по умолчанию туда закачиваются дистрибутивы обновлений перед установкой (\Download).

Агент настраивается через реестр или групповые политики: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate и Computer Configuration\Administrative Templates\Windows Components\Windows Update

Не останавливаясь подробно на протоколе, по которому агент взаимодействует с сервером, и деталях происходящих в нём процессов, выделим два основных режима работы агента:

1)      Сканирование обновлений: инвентаризация установленных на клиенте продуктов и синхронизация БД агента с БД сервера – фактически выбор и закачка метаданных в локальную БД Jet, оценка правил применимости и детектирования.

2)      Установка обновлений: закачка найденных обновлений в кэш, исполнение правил установки, детектирование результата после установки.

Как работает «домашний» клиент

На личном компьютере политика, назначающая источник обновлений, обычно отсутствует. В этой ситуации агент WUA сканирует обновления непосредственно относительно Microsoft Update (MU) и оттуда же закачивает/устанавливает дистрибутивы.

Как работает клиент WSUS

В типичном сценарии использования инфраструктуры WSUS администратор групповой политикой назначает адрес сервера WSUS. Агенты WUA начинают сканировать обновления относительно этого источника, закачка (разумеется, с использованием BITS) и установка также идёт с него – как только администратор утвердит обновления в консоли. Кроме того, через ту же GPO можно настроить и отправку отчёта на сервер WSUS.

Как работает ConfigMgr/SUP

В этом случае всё заметно сложнее: ConfigMgr добавляет еще один слой управления (и точек отказа). Упрощенная схема процесса сканирования обновлений приведена на рисунке 1.

[caption id="attachment_835" align="alignnone" width="500"] Рисунок 1. Схема процесса сканирования обновлений[/caption]

После выполнения действий 1-4 (синхронизации обновлений на сервере ConfigMgr) в БД WSUS и ConfigMgr оказывается фактически часть метаданных облака Microsoft Update по выбранным администратором продуктам, языкам и классификациям.

На шагах 5-8 агент ConfigMgr определяет ближайший к нему сервер SUP/WSUS (по границам сайта) и вписывает его в локальную политику на клиенте: поэтому наличие доменной GPO, конфигурирующей адрес сервера обновлений, немедленно заблокирует сканирование обновлений.

Затем по заданному администратором расписанию агент инициирует сканирование обновлений относительно найденного WSUS в WUA, забирает результат и передаёт его в виде сообщений о состоянии на сервер ConfigMgr. После успешного выполнения шагов 9-13 как на клиенте, так и на сервере будет сформирован список обновлений, которые применимы на данном клиенте. Сервер на основании этих данных сможет построить отчёты и рассчитать соответствие для групп обновлений и каждого обновления в отдельности.

На рисунке 2 приведена упрощенная схема процесса установки обновлений.

[caption id="attachment_826" align="alignnone" width="500"] Рисунок 2. Схема процесса развертывания обновлений[/caption]

Администратор создаёт список обновлений на установку (группу обновлений), закачивает их в пакет обновлений и разворачивает группу (шаги 1-3). Клиент получает политику развертывания, сравнивает списки применимых и развёрнутых обновлений, выбирает и закачивает дистрибутивы только для нужных обновлений и передаёт их на установку WUA (шаги 4-7). Как и в случае сканирования, клиент собирает отчёт по установке от WUA и перенаправляет его на сервер в виде сообщений о состоянии (шаги 7-8). Итогом процесса является появление результатов развертывания в консоли и отчётах ConfigMgr.

Критичным является успешное выполнение обоих процессов: если не работает сканирование, то агент не сможет верно определить, какие обновления нужны. А без получения политики развёртывания установки и вовсе не произойдет.

P.S. Процесс переоценки обновлений после их установки (дельта-сканирование) опущен на схеме для простоты, однако подразумевает, что SUP/WSUS доступна клиентам во время установки обновлений.

Дизайн инфраструктуры

Одно из ключевых отличий инфраструктуры ConfigMgr/SUP от WSUS – это управление контентом. Именно из-за размеров дистрибутивов администраторам приходится размещать по серверу WSUS в каждой удалённой сети, и поддерживать репликацию – в результате образуются огромные иерархии серверов WSUS, иногда насчитывающие десятки серверов. В случае ConfigMgr для закачки дистрибутивов используются точки распространения (Distribution Point, DP) – зачастую их количество не уступает иерархии WSUS, а то и превышает её в разы. Однако DP – это очень простой сервер (IIS + ISAPI-фильтр + WMI-провайдер + папка с дистрибутивами), и поддерживать его гораздо проще.

Поскольку WSUS в составе SUP отвечает только за сканирование, то количество WSUS можно сильно ограничить. Дело в том, что трафик, порождаемый сканированием, обычно невелик и составляет сотни килобайт. Исключение составляет начальное сканирование, порождаемый которым трафик может достигать 10 Мб при обилии продуктов Microsoft, установленных на машине.

Именно поэтому поддерживается до 25 000 клиентов на точку управления обновлениями (SUP), если она совмещена с сайт-сервером, и до до 150 000 клиентов, если SUP установлена на удалённой машине.. Тем самым большинству инфраструктур будет достаточно одной точки на сайт, тем более первичный сайт на момент написания статей поддерживал аж до 150 000 клиентов (кстати поэтому сейчас мы обычно не рекомендуем создание центрального сайта администрирования CAS). Кроме того, начиная с версии ConfigMgr 1702 поддерживается SUP Affinity: привязка SUP к группам границ, что позволяет создавать SUP-ы в удаленных локациях в рамках одного сайта.

Настройки SUP/WSUS

SUP сама по себе представляет набор DLL, загружаемых в треды процесса службы SMS_Executive, которые используют API WSUS для управления последним – поэтому установка SUP поверх WSUS занимает считанные минуты и тривиальна. Установка WSUS также не представляет большой сложности, однако невнимательный администратор наверняка пропустит шаг, на котором можно выбрать установку БД WSUS не на Windows Internal Database (и установку самой WID). Поскольку с ConfigMgr поставляется полноценный SQL Server Standard, то БД WSUS имеет смысл разместить там, и не занимать ресурсы ОС вторым экземпляром SQL. Хорошей идеей также будет увеличить размер файлов БД хотя бы до 5 Гб и настроить фиксированный прирост (autogrowth) по 1 Гб до первой синхронизации – почему-то разработчики при создании БД решили задавать ей размер в 1 Мб с приростом 1%.

В больших инфраструктурах также имеет смысл соблюсти лучшие практики по настройке БД SQL и перенести файлы данных и логи БД WSUS на отдельные диски.

Однако после установки необходимо тщательно отнестись к подбору продуктов и классификаций: напомню, делать это надо НЕ в консоли WSUS, а в настройках SUP. До первой синхронизации вы увидите неактуальный список продуктов – он будет обновлён только когда она завершится. Снимите все галочки перед первой синхронизацией! Затем не поленитесь пройти по списку и поставить галочки только у тех продуктов, которые используются в вашей инфраструктуре (и да, это повод уменьшить их разнообразие). Кроме того, я не рекомендую ставить галочки у продуктов наподобие “Windows 10 Drivers” или “Windows Server 2012 Dynamic Setup” – клиенты ConfigMgr всё равно не «умеют» использовать ни то, ни другое. Хорошая расшифровка названий продуктов есть здесь.

Отдельная головная боль – это языки. С самого начала надо убедиться, что вы не синхронизируете «лишние» языки (а по умолчанию вы обнаружите довольно богатый набор) и убрать их. Дело в том, что после начальной синхронизации вы галочки языков уберёте, а метаданные для этих языков в БД не исчезнут – и впредь для многих обновлений вам придется закачивать ненужные языки.

Ещё один важнейший момент - это настройки IIS на WSUS по умолчанию: они больше подходят для небольших компаний. Поэтому если в вашей инфраструктуре планируется более 1 000 клиентов, то позаботьтесь о следующих настройках пула приложений (Application Pool) WSUSPool в IIS:

1)      Увеличьте размер очереди (Queue Length) до 2000

2)      Увеличьте лимит использования памяти (Private Memory limit) как минимум до 4 Гб, а лучше больше. Делать как в документации 0 (безлимитно), на мой взгляд, довольно опасно (если, конечно, для SUP у вас не используется уберсервер 😊).

Замечу, что для SUP на CAS это делать не требуется – клиенты в норме туда не обращаются.

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

Подводные камни

Как и в случае с WDS, мы не рекомендуем лишний раз «залезать» в консоль WSUS, который управляется ConfigMgr, и уж точно не рекомендуем утверждать (approve) обновления (за исключением, м.б. SCEP). Однако, по мнению разработчиков, это не должно останавливать вас от выполнения задач обслуживания WSUS: а именно очистки БД от замененных, отклонённых и устаревших обновлений, а также реиндексации БД SQL! Поэтому позаботьтесь, чтобы в вашей инфраструктуре были реализованы рекомендации отдельной большой статьи в блоге. Отдельно надо упомянуть, что встроенный мастер очистки WSUS (Cleanup Wizard) удаляет метаданные заменённых обновлений, если они не были утверждены за последние 30 дней (а в случае ConfigMgr подавляющая часть обновлений в консоли WSUS остаётся неутверждённой) и не нужны клиентам (что в норме также выполняется, т.к. клиенты ConfigMgr по умолчанию не отчитываются WSUS). Поэтому заменённые обновления лучше отклонять вручную - и в статье есть ссылка на соответствующий скрипт. Кроме того, ничего не мешает отклонять и ненужные на ваш взгляд обновления: например, для архитектуры ia64 (Itanium) - это уменьшит размер БД WSUS и ускорит процесс сканирования обновлений.

Еще один важный момент, про который мало кто знает до первой прогулки по этим граблям: при деинсталляции последней SUP сайта все обновления в БД ConfigMgr помечаются как устаревшие (то же самое происходит и при снятии галочки категории или продукта – но для части обновлений). Проблема в том, что это массовое изменение CI (а обновления в БД хранятся именно так) в базе данных ConfigMgr вызовет появление тысяч файлов в инбоксе ObjReplMgr.box и будет долго обрабатываться – а если вы используете мультисайтовую иерархию и удалите SUP на высшем уровне, то это произойдет ещё и на всех сайтах. Поэтому я рекомендую всячески избегать деинсталляции SUP, тем более сама по себе "ломается" она редко.

С другой стороны WSUS можно достаточно безопасно переустановить даже не сохраняя БД: ведь при следующем цикле SUP заново пропишет все настройки и запустит синхронизацию. Разумеется, на время отсутствия WSUS вы получите некоторое количество сообщений об ошибках в логах и статусах компонентов SUP WSyncMgr, WCM, WSUSCtrl, а также со стороны клиентов. Кроме того, если Вы не сохраните БД, то клиенты будут вынуждены сделать полное сканирование (помните про 10 Мб трафика на клиента) - но этот вал запросов можно пережить.

Неожиданный момент в ConfigMgr версии до 1806: когда вы удаляете продукт или классификацию в настройках SUP, то соответствующие обновления в консоли ConfigMgr помечаются как истёкшие (expired) и удаляются автоматически - но на WSUS этого не происходит! Поэтому в том случае, когда вы выводите из эксплуатации тот или иной продукт (Windows XP или уже скоро Windows 7),  уделите время и отклоните вручную или скриптом соответствующие обновления в БД WSUS. Будьте осторожны - некоторые обновления применимы к нескольким продуктам! В ConfigMgr 1806 это поведение было исправлено, теперь обновления, удаляемые в ConfigMgr, автоматически отклоняются и на WSUS.

Продолжение следует

В следующей части мы поговорим о том, как правильно перевести клиентов на получение обновлений с ConfigMgr/SUP. Следите за пополнением записей в этом блоге и спасибо за внимание!