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

  • Article

Сегодня мы продолжаем тему распространения обновлений ОС и прочего ПО через Configuration Manager, фокусируясь непосредственно на работе по миграции клиентов. Предыдущая часть опубликована ранее в этом блоге, в этой части мы предполагаем, что серверная инфраструктура готова и работает нормально.

Как правило, в компании на момент появления там инженера поддержки уже есть какая-то инфраструктура распространения обновлений: как правило, это один или несколько серверов WSUS, гораздо реже - старая иерархия ConfigMgr или бесконтрольное обновление рабочих станций через Microsoft Update. По сути все эти случаи мало отличаются друг от друга, поэтому я буду исходить из первого сценария.

Переход на распространение обновлений через ConfigMgr

Итак, пусть в компании используется один или несколько серверов WSUS, а также развернута инфраструктура ConfigMgr. На серверах WSUS созданы некие группы машин, а в AD настроены групповые политики для указания клиентам адресов WSUS-серверов и настроек установки обновлений и привязки к группам. Также на серверах WSUS одобрены к распространению все или часть обновлений, дистрибутивы одобренных обновлений закачаны в папку WSUSContent.

Путь хорошего администратора всегда начинается с выделения пилотной группы (в данном случае машин). Я рекомендую создать выделенную группу безопасности в AD и добавить туда машины, над которыми не жалко будет поставить эксперимент (по странному стечению обстоятельств обычно таковыми оказываются машины сотрудников отдела ИТ).

Напомню, что клиент ConfigMgr прописывает URL SUP/WSUS в локальную политику на машине. Это означает, что если на машину назначена доменная политика с указанием (другого) адреса WSUS, то клиент ConfigMgr не сможет осуществить цикл сканирования. Однако и снимать доменную политику сразу нельзя: как только Windows Update Agent (WUA) обнаружит удаление политики, произойдет сканирование, закачка и установка обновлений с Microsoft Update (MU) - производитель Windows тем самым позаботился о максимальной защищённости машины. Это несёт риски как установки непроверенных обновлений (и непреднамеренных перезагрузок), так и перегрузки интернет-каналов.

Поэтому правильно будет создать отдельный объект групповой политики (GPO) и отключить автоматические обновления в нём: Computer Configuration\Administrative Templates\Windows Components\Windows Update\Configure Automatic Updates == Disabled. Это предупредит автоматические "общение" WUA с Microsoft Update на время миграции. Данную GPO разумно отфильтровать по ранее созданной группе безопасности и назначить на те же OU, что и "боевую" GPO для WSUS. В то же время у данной группы безопасности нужно отобрать права на чтение "боевой" GPO через тот же механизм Security Filtering.

Далее в консоли ConfigMgr необходимо создать новую Custom Device Client Setting со включённым управлением обновлениями: Software Updates, Enable Software Updates on Clients = Yes (и расписаниями сканирования/переоценки обновлений), а также коллекцию для пилотной группы машин - можно сформировать её по той же группе в AD (убедившись, что группа обнаруживается через AD Group Discovery). После назначения клиентской настройки на коллекцию и наполнения коллекции клиенты начнут получать новый адрес SUP/WSUS и немедленно начинать полное сканирование относительно нового источника.

N.B.

  1. Настройки, связанные с членством машины в группе AD, будут применены только после перезагрузки машины (или сброса кэша Kerberos). Поэтому позаботьтесь или о перезагрузке пилотных машин после добавления в группу, либо о развертывании минималистичного скрипта.
  2. Помните про трафик и нагрузку на сервер WSUS, связанные с полным сканированием: если пилотная группа окажется чересчур велика, то вы рискуете перегрузить каналы связи и/или пул приложения WSUS в IIS. Впрочем, при соблюдении лучших практик по настройке WSUS из предыдущей части последнее маловероятно.

С этого момента администратору можно откинуться на спинку кресла и начать ждать результатов сканирования. Удобным инструментом отслеживания результата является штатный отчет Software Updates - D Scan\Scan 1 - Last Scan States by Collection (вообще штатные отчёты по обновлениям на удивление хороши).

[caption id="attachment_885" align="alignnone" width="1024"] Рис. 1. Отчёт Last Scan States By Collection[/caption]

В идеальном мире администратору потребовалось бы только наслаждаться увеличением счётчика Scan Completed. Однако самое интересное обычно таится во вложенном отчёт Scan 3 - Clients of a collection reporting a specific state (secondary), в который можно попасть кликнув по линку Scan Failed. Напомню, что отчёт можно выгрузить в CSV и обработать в любимом табличном редакторе, чтобы отсортировать проблемы по частоте и лёгкости устранения.

[caption id="attachment_895" align="alignnone" width="1024"] Рис. 2. Отчёт по неудачным сканированиям обновлений (Clients of a Collection Reporting a Specific State)[/caption]

Как только процент успешно отсканировавших обновления машин достигнет некого целевого значения (например, 90%), то можно переходить к пилотному развёртыванию обновлений. Помните, что без успешного завершения цикла сканирования машина никогда не начнёт цикл установки обновлений, поэтому устранение проблем сканирования является критичным для продолжения!

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

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

Устранение многочисленных проблем на этапе сканирования является критичным, поэтому подробно рассмотрим самые частые варианты.

Group Policy Conflict

Данную ошибку можно наблюдать как в отчёте, так и в логе Scanagent.log на клиенте при попытке сканирования. В 90% случаев она значит именно то, что написано: есть групповая политика, которая указывает адрес WSUS, и она назначена на проблемную машину. Найти "виновника" можно как со стороны сервера (через Group Policy Modeling Wizard), так и со стороны клиента (в отчёте gpresult или RSOP.msc).

В редких случаях выясняется, что доменной групповой политики не назначено, но ошибка сохраняется. В таких случаях имеет смысл забэкапить и удалить файл %Windir%\system32\GroupPolicy\Machine\Registry.pol, а затем обновить групповую политику и запустить цикл сканирования.

Сетевые проблемы

В общее описание входят все проблемы на сетевом уровне:

  1. Файрволлы
  2. DNS
  3. Прокси (да, агент WUA умеет читать пользовательские настройки)
  4. …

Такие проблемы хорошо детектируются по логам Scanagent.log/WindowsUpdate.log и отчётам Configuration Manager, однако их решение зачастую находится за пределами зоны ответственности администратора ConfigMgr.

Проблемы Windows Update Agent

Windows Update Agent является частью операционной системы, поэтому обновления и исправления для него включены в таковые для ОС. Это иногда приводит к патовой ситуации: агент не работает, потому что не обновлён, а обновиться не может, потому что не работает. Классическим примером является WUA в Windows 7 SP1 без обновлений, который де-факто практически неработоспособен в современных окружениях. Поэтому позаботьтесь о том, чтобы в вашей инфраструктуре новые машины имели последнее кумулятивное обновление для ОС, а если уже случилось и нашлись необновлённые машины с ОС Windows 7, 8.1 или Windows 10 1607 - чтобы обновление, исправляющее функционал WUA было установлено на такую машину через механизм Software Distribution в ConfigMgr (мы рекомендуем, естественно, использовать Application).

Последние релизы WUA вне кумулятивного обновления для старых ОС приведены ниже:

  1. Windows 7 и 2008 R2: https://support.microsoft.com/en-us/help/3138612/windows-update-client-for-windows-7-and-windows-server-2008-r2-march-2
  2. Windows 8.1 и 2012 R2: https://support.microsoft.com/en-us/help/3138615/windows-update-client-for-windows-8-1-and-windows-server-2012-r2-march

Команды на установку описаны в статье базы знаний, я рекомендую распаковать MSU-файл и использовать PkgMgr для того, чтобы избежать использования API WUA. Типовой скрипт для детектирования наличия обновления проще всего написать на PS:

 $KB = 'KB3138612'
If(Get-WmiObject -Namespace 'root/cimv2' -Class 'Win32_QuickFixEngineering' -Filter "HotFixId = '$KB'"){Write-Output "$KB is installed"; Exit}
Else {Exit}

Также иногда оказывается повреждённой БД Jet агента WUA (что приводит к неспецифичным ошибкам в отчётах ConfigMgr или ошибке 0x8024400D в логе WindowsUpdate.log). В этом случае поможет классический рецепт с удалением БД вместе с папкой \SoftwareDistribution после остановки службы WUA. Последующий перезапуск создаст БД заново и вызовет незамедлительное полное сканирование относительно указанного в политике WSUS.

Всевозможные проблемы на уровне ОС

Нехватка памяти, дискового пространства, утечки ресурсов обычно приводят к неспецифичным ошибкам сканирования: такие случаи требуют индивидуального подхода и изучения логов Scanagent.log ConfigMgr и WindowsUpdate.log WUA (напомню, в Windows 10 лог ведётся в формате ETL, и для его чтения нужно повозиться). Классические сообщения в отчёте: "Not enough storage is available to complete this operation.", "Insufficient system resources exist to complete the requested service." и тому подобные.

Ошибка "Exceeded max server round trips: 0x80244010" при первичном сканировании

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

Плохим временным решением может быть исправление максимального размера XML в БД WSUS (200 kb по умолчанию) через запрос SQL:

USE SUSDB
GO
UPDATE tbConfigurationC SET MaxXMLPerRequest = 5000000

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

В следующей части мы поговорим про типичные проблемы развёртывания обновлений и их устранение. Следите за обновлениями!