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

  • Article

Сегодняшняя статья будет посвящена особенностям распространения обновлений через ConfigMgr. Чтобы не повторять написанное в предыдущих частях (часть 1, часть 2), я буду предполагать, что инфраструктура доставки обновлений настроена корректно, а клиенты успешно выполняют циклы сканирования обновлений относительно ConfigMgr SUP. Также, как и ранее, не будут описаны конкретные действия в консоли: пошаговых описаний с картинками в интернете достаточно.

Особенности распространения обновлений через ConfigMgr

Статусы соответствия сканирования обновлений

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

Соответствует (Compliant) Установлено (Installed) Обновление применимо и установлено
Неприменимо (Not Required) Нет обновляемого продукта или не выполнены пререквизиты
Не соответствует (Non-compliant) Требуется (Required) Обновление применимо и не установлено
Неизвестно (Unknown): Нет отчёта о состоянии соответствия Машина выключена
Не работает цикл сканирования или отчётности

В консоли суммаризированные данные по соответствию конкретных обновлений отображаются прямо в ноде All Software Updates, а по соответствию групп - в Software Update Groups.

Кроме того, детальные данные из БД можно получить в отчётах по соответствию обновлениям (Software Updates - A. Compliance), однако всегда надо понимать, относительно чего рассчитано состояние соответствия в каждом отчёте. Ведь вариантов не так уж мало: расположим их в порядке уменьшения числа обновлений в источнике.

  1. Относительно MS Update, то есть всех обновлений в облаке. В ConfigMgr это не реализуется, однако может рассчитываться сторонним ПО, например, сканерами уязвимостей.
  2. Относительно БД SUP/WSUS, то есть синхронизированных обновлений. Таков, например, отчёт Compliance 5 - Specific computer.
  3. Относительно группы обновлений (Software Update Group) , то есть списка, определённого администратором. Пример отчёта:  Compliance 3 - Update group (per update).
  4. Относительно конкретного обновления. Пример отчёта: Compliance 2 - Specific software update. 

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

Также надо быть осторожнее с процентом соответствия, в консоли он рассчитывается от числа клиентов ConfigMgr: и в реальном окружении вряд ли будет составлять 100%. В отчётах процент может считаться относительно другого множества машин, например относительно коллекции.

Развёртывание обновлений

После получения информации состояния обновлений следующим шагом является планирование и осуществление развёртывания. Кратко напомню основные задействованные объекты в консоли:

Группа обновлений Software Update Group (SUG) Список обновлений на установку, определяемый администратором
Пакет обновлений Software Update Package (SUPkg) Объект контента для хранения дистрибутивов.*
Коллекция Collection Определяемый администратором список целевых машин для развёртывания, c окном обслуживания или без
Развёртывание Deployment привязка SUG к коллекции, после создания которой начинается распространение обновлений
Правило автоматического развёртывания Automated Deployment Rule (ADR) Робот, автоматизирующий создание SUG, загрузку обновлений в SUPkg и развёртывание

Приведу некоторые не совсем очевидные лучшие практики по формированию данных объектов:

  1. Развёрнутая SUG не должна быть большой. В документации описан лимит в 1000 обновлений, по моему же персональному мнению стоит избегать групп из 100+ обновлений. Причина этого проста: развёрнутая группа - это политика, которая должна быть закачана и обработана клиентом. Чем она больше - чем больше нагрузка на машины, ведь клиент ConfigMgr должен фактически сравнить два списка - требуемых и развёрнутых в группе обновлений - и выбрать общую часть.
  2. Даже не развёрнутая SUG не должна быть большой, ну и самих SUG не должно быть чересчур много. Серверу необходимо будет рассчитывать и суммаризировать состояния соответствия для каждой, чем больше групп и обновлений в группе, тем больше нагрузка на SQL.
  3. SUPkg не должна быть большой. Клиенты выберут то, что им нужно скачать из пакета, поэтому для них размер пакета не имеет значения, однако серверная часть будет делать новые снепшоты пакета, сжимать его и рассылать на DP и другие сайты  каждый раз, когда пакет обновляется. А обновляются SUPkg часто и, иногда, без ведома администратора: например, при удалении истёкших (expired) обновлений из БД они удаляются и из SUPkg.
  4. SUPkg надо собирать аккуратно, их имеет смысл распространить на все или большинство DP. Разбирательство на тему "почему клиент X не смог закачать и установить обновление Y" требуют выяснения всех развертываний данного обновления на данном клиенте, изучения их настроек, а также поиска всех пакетов, в которое входит данное обновление, и их расположения на DP. Поскольку найти в какие пакеты закачано обновление Y из консоли весьма нетривиально без прокликивания всех пакетов, то такие расследования доставляют крайне мало удовольствия.
  5. Коллекция для развёртывания не должна быть большой. Во-первых, правильно всё-таки распространять обновления волнами (или, как теперь модно называть, кольцами, update rings), чтобы нивелировать риски распространения обновления, которое "всё поломает", на все машины компании. Во-вторых, в очень больших окружениях генерация политики на множество клиентов может занять существенное время и нагрузить SQL. В третьих, напомню, что политики будут применены клиентами в течение часа (по умолчанию), а значит все клиенты начнут работу с обновлениями как раз в этот промежуток времени - и в больших окружениях могут изрядно нагрузить серверную часть закачками и отчётностью.
  6. Настройки развёртывания и окон обслуживания должны быть щадящими. Про это мы немного поговорим ниже.
  7. ADR должен закачивать минимально нужное количество обновлений. Тут всё просто, ради экономии трафика, времени и места на диске.

Если вы ещё не совсем устали, читая список выше, приведу еще парочку - но на этот раз касательно развёртывания обновлений. Напомню картинку из прошлого поста - чтобы клиент установил развёрнутое обновление, нужно пройти ряд стадий, которые традиционно выполняются по расписаниям. Я приведу их ниже с указанием типовых настроек клиента.

  1. Клиент получит политику развёртывания: в течение 60 минут.
  2. Сразу после получения политики клиент запустит оценку применимости развёрнутых обновлений - сравнит два списка - и соберёт список на установку. Здесь есть два нюанса:
    1. Разумеется, при выполнении цикла сканирования WUA кэширует его результаты и при повторном сканировании не обращается к SUP/WSUS (делает offline scan). Однако у этого кэша есть TTL, и он составляет 24 часа. Если TTL истёк, то будет выполнена попытка просканировать обновления (non-forced online scan).
    2. Клиент отчитается о результатах оценки на сервер в виде сообщения о состоянии (state message): в течение 15 минут.
  3. Клиент обработает политику, и выберет время доступности развёртывания (Available Time):
    1. Именно в это время начнётся закачка обновлений из списка установки с DP в кэш - но только в том случае, если развёртывание обязательное (Purpose = Required).
    2. Пользователю будет отправлена нотификация о том, что ему доступно новое ПО - или не отправлена, если так указано в развёртывании.
  4. Клиент выберет время для установки обновлений на базе настроек развёртывания и окон обслуживания.
    1. Перед установкой клиент на всякий случай снова отсканирует обновления, если TTL истёк.
    2. Еще один повод не делать большие SUG: если клиент получит список на установку в рамках одного развёртывания дольше, чем окно обслуживания на коллекции, то установка будет ждать более долгого окна. По умолчанию обычные обновления требуют 10 минут, кумулятивные - 60 - посмотреть это можно в настройках индивидуального обновления.
  5. В момент Х клиент начнёт установку обновлений и перезагрузит машину при необходимости, не забывая отчитываться о каждом шаге на сервер в виде сообщения о состоянии.
    1. Если на момент Х обновления были вытеснены из кэша другим ПО, то они будут закачаны заново. Это повод сделать кэш побольше.
    2. Сразу после установки или после перезагрузки клиент делает оффлайн сканирование (forced offline scan) по умолчанию, об этом надо заботиться отдельно.
  6. Сервер обработает сообщения о состоянии и рассчитает состояние соответствия развёртывания, о котором мы также поговорим ниже.
  7. Поскольку для развёртываний обновлений (как и приложений) нельзя указать время истечения (Expiration time), то целевая конфигурация будет проверяться и, при необходимости, применяться до удаления развёртывания - по расписанию переоценки обновлений (Software Update Re-Evaluation Cycle).

Из этого процесса и следуют лучшие практики для развёртывания:

  1. При планировании развёртывания, а также циклов сканирования и переоценки обновлений, учитывайте TTL кэша и сопутствующую активность клиента WUA: SUP/WSUS должен быть доступен.
  2. Назначайте Available Time не "прямо сейчас" : дайте время для того, чтобы обновлённый SUPkg дошёл до назначенных DP.
  3. Делайте Required-развёртывания. Во-первых, развёртывание в режиме Available даёт 90% гарантию того, что обновления установлены не будут :). Во-вторых, режим Available не позволяет заранее поместить дистрибутивы в кэш, а это, напомню, иногда гигабайты. Компромиссный вариант - Required-развёртывание с дедлайном в далёком будущем.
  4. Назначайте Deadline не "прямо сейчас". а лучше через неделю. Это даст возможность пользователю, если таковой за машиной сидит, установить обновления тогда, когда ему будет это удобно.
  5. Не делайте развертывания "втихую" в режиме Hide all notifications. Пользователю вряд ли понравится получить внезапные (для него) замедление работы машины с последующей перезагрузкой. Также при этом он не сможет поставить обновления добровольно.
  6. Не подавляйте перезапуск, кроме критичных систем: это также 90% гарантия того, что обновления не будут поставлены месяцами, а следующий релиз WannaCry/NotPetya найдёт чем поживиться в вашем окружении.

Статусы соответствия развёртывания обновлений

После осуществления развёртывания наступает стадия оценки его результатов. Поскольку развёртывания приложений, обновлений и шаблонов конфигурации являются State-based, то снова возникает понятие соответствия - в данном случае, соответствия требуемой конфигурации в виде развёрнутой группы обновлений. Снова классифицируем возможные результаты для машины:

Соответствует (Compliant) Установлено (Installed) Обновление установлено (неважно, через ConfigMgr или нет)
Неприменимо (Not Required) Нет обновляемого продукта или не выполнены пререквизиты
В процессе (In Progress) Идёт закачка (Downloading) Задача на закачку дистрибутивов началась и ещё не завершилась
Идёт установка (Installing) Задача на установку началась и ещё не завершилась
Ожидаем окно обслуживания (Waiting for Maintenance Window) Задача на установку ждёт доступного окна обслуживания
Ожидаем перезагрузку (Waiting for Restart) Обновления установлены, ожидается перезапуск ОС
… …
Ошибка (Error) Не удалось закачать обновления (Failed to download updates) Клиент вне границ, в которых доступен SUPkg, закрыт порт и т.п.
Не удалось установить обновления (Failed to install updates) Не хватило места на диске, или установка обновляемого ПО повреждена, и т.п.
… …
Неизвестно (Unknown): Нет отчёта о состоянии соответствия Машина выключена
Не работает цикл доставки политик или отчётности

В консоли состояние соответствия развёртывания видно там же, где и статистика по прочим развёртываниям во вкладке мониторинга.

Про решение типовых проблем мы поговорим чуть позже, а пока же необходимо подчеркнуть, что прямой связи между состояниями соответствия сканирования и развёртывания нет. Первое измеряется на основе определенных производителями ПО правил применимости обновлений, второе же - на основе применения целевой конфигурации, заданной администратором - и это различие нужно чётко осознавать при анализе данных соответствия и подготовке отчётности.

Типичные проблемы

Развёртывание обновлений остаётся в состоянии Unknown даже если клиент активен/онлайн в консоли

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

Обновления не закачиваются

Опять же, возможных причин очень много, приведу банальные:

  1. Обновление отсутствует в пакете, который распространён на DP в группе границ клиента
  2. Что-то мешает закачке и проверке хеша: сетевое оборудование (ох уж эти оптимизаторы WAN-линков!), антивирусное ПО
  3. Нет места на диске или кэше: скорее всего первое, если вы не злоупотребляете галочкой "Persist content in client cache"

Обновления устанавливаются с ошибками

Снова список самых частых проблем:

  1. Недостаток ресурсов: памяти, места на диске - а также "железные" проблемы любого сорта
  2. Повреждена установка обновляемого продукта: самое частое - хранилище компонентов  ОС Windows (CBS Store), установка MSI-версий Office.

К сожалению, в отличие от ошибок сканирования, проблемы установки редко поддаются массовому исправлению - "волшебных пуль" здесь нет. Для некоторых обновлений есть известные проблемы, если вы видите, что какое-то обновление массово не устанавливается - не поленитесь проверить статью KB.

По моему опыту, "лечить" хранилище компонентов Windows массово практически нереально: одно из немногих доступных решений - это CheckSUR/DISM, однако оправданно это только для серверов или критичных рабочих станций. Похожая ситуация складывается и с продуктами на базе MSI (Office, Silverlight). В основном же стоит рассчитывать на переустановку ОС: это обычно быстрее и надёжнее.

Клиенты вечно ждут окна обслуживания

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

  1. Неповторяющееся окно в прошлом или далёком будущем. Это ошибка администратора, которую может быть нетривиально решить, если коллекций и окон обслуживания на них много. Напомню, что есть штатный отчёт по окнам обслуживания, доступным конкретному клиенту, ну и порекомендую не злоупотреблять неповторяющимися окнами.
  2. Если на клиента назначено хотя бы одно окно обслуживания только для обновлений (Software Updates/Type=4), то он не будет устанавливать обновления в окно для всех развёртываний (All Deployments, Type=1). Это поведение будет рано или поздно исправлено, пока же я рекомендую учитывать его при развёртываниях.

Развёртывание обновлений успешно, однако некоторые обновления не установлены

Обманчивое "зелёное" состояние "Соответствует"/Compliant в консоли успокаивает администратора до той поры, пока кто-то из отдела информационной безопасности не найдёт большое количество незапатченных машин, или, хуже того, их не найдет злоумышленник или вирус. Важный момент кроется в том, что у обновлений бывают пререквизиты: и пока они не установлены, то обновление будет попадать в состояние "Не требуется"/Not Required, а следовательно - "Соответствует"/Compliant. Как только пререквизит будет установлен - машинам может потребоваться сразу большой список обновлений, выпущенных после пререквизита.

В пределах одного месяца релиза таких обновлений практически не случается, однако на более долгих промежутках времени шансы есть. Классическим случаем пререквизита являются всевозможные Сервисные пакеты (Service Packs): как правило, они включают в себя все предыдущие обновления, и являются пререквизитом для следующих. В ту же категорию попадают большие пакеты обновлений для Windows 8.1/2012 R2 (KB2919355 и более поздние).

Поэтому я рекомендую внимательно изучать отчёты по сканированию машин, такие как Management 2 - Updates required but not deployed, а также своевременно добавлять новые продукты в настройках SUP. Кроме того, по возможности, необходимо развёртывать обновления в ежемесячном цикле, а операционные системы и ПО - сразу с интегрированными обновлениями.

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

На этом технический обзор механизма развёртывания обновлений через Configuration Manager завершён. Я надеюсь, что он получился не слишком долгим и занудным, и не отвратит вас от использования ConfigMgr как средства доставки обновлений.

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