sccm-logo

SCCM: управление обновлениями клиентов

Единственно верной и абсолютно правильной стратегии развёртывания обновлений не существует. Каждая организация имеет свои требования, поэтому правильная стратегия — та, которая выполняет свои задачи в конкретной инфраструктуре. В данной статье мы рассмотрим один из типовых вариантов организации процесса управления обновлениями, который вы можете использовать как отправную точку, для создания своей собственной стратегии. Для целей данного руководства мы будем рассматривать только обновление рабочих станций. Процесс развёртывания описаний для Endpoint Protection здесь мы рассматривать не будем. Предполагается также, что у вас уже развёрнута и настроена точка обновления программного обеспечения (Software Update Point (SUP). Для написания статьи использовался SCCM Current Branch 1706. Также см. статью Обновление Windows 10 с помощью планов обслуживания Configuration Manager.

Рекомендую ознакомится с бесплатной книгой по Update Management от Microsoft:  Microsoft System Center Software Update Management Field Experience. Или с официального сайта: https://mva.microsoft.com/ebooks#9780735695849. Хотя некоторые подходы к управлению обновлениями изменились после октября 2016 и с выходом Windows 10, в целом же, руководство содержит много полезной информации.
Статья на русском о том, как работает связка WSUS — Software Update Point — Windows Update Agent: https://blogs.technet.microsoft.com/scpferublog/2017/11/22/configmgr-update-management-part-1/

Обзор процесса обновления

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

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

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

Первая тестовая группа машин получит обновления на следующий день после выхода исправлений. Напомню, что обновления выходят каждый второй вторник месяца (среда по Москве), однако критически важные обновления могут быть выпущены внепланово, поэтому для таких обновлений мы создадим отдельное правило автоматического развёртывания. Тестовая группа содержит компьютеры из группы Active Directory, в которую мы добавляем машины вручную. Целесообразно в эту группу включать компьютеры IT отдела, тестовые компьютеры, а также добровольцев из числа рядовых пользователей. На основе членства в этой группе у нас создаётся коллекция «Update — Tests» в SCCM.

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

Вторая группа компьютеров будет использоваться для исключения из процесса обновления. Эта группа не будет получать обновления через SCCM. Назовём её Update — Exclusions. Компьютеры этой группы будут входить в группу AD, на основе которой будет создаваться коллекция Update — Exclusions в SCCM. Эта группа машин представляют собой особо важные компьютеры, установка обновлений на которых будет выполнятся вручную.

Третья группа компьютеров представляет собой основную массу рабочих машин, на которую мы будем разворачивать обновления в последнюю неделю месяца, после обкатки обновлений тестовой группой. Назовём её Update — Production. Эта группа будет состоять из всех рабочих станций, кроме тех, которые входят в группу Update — Exclusions.

Визуально календарный процесс обновления будет выглядеть следующим образом:

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

Коллекции

Как было описано ранее, у нас будет создано 3 коллекции:

  • Update — Tests
  • Update — Production
  • Update — Exclusions

Предварительно создаём 2 группы в Active Directory:

Создаём коллекции следующим образом:

Update — Tests — ограничиваем коллекцией All Workstations или ей подобной. Создаём правило запроса (Query Rule):

где DOMAIN — имя домена.

Update — Exclusions — ограничиваем также коллекцией All Workstations или ей подобной. Создаём правило запроса:

где DOMAIN — имя домена.

Update — Production — также ограничиваем коллекцией All Workstations или ей подобной. Исключаем коллекцию Update — Exclusions и Update — Tests и включаем коллекцию All Workstations:

Периоды обслуживания — Maintenance Windows

Периоды или окна обслуживания могут использоваться на коллекциях, чтобы предотвратить установку обновлений в рабочие часы. Добавим периоды обслуживания на созданные коллекции с 22 часов до 5. Подробнее о периодах обслуживания см. в статье Использование периодов обслуживания в System Center Configuration Manager.

Открываем свойства коллекции:

На вкладке Maintenance Windows создаём новый период обслуживания:

Указываем требуемое расписание. Слишком короткий интервал может привести к тому, что обновления не будут устанавливаться. Желательно задавать период более 2 часов:

Такой же период обслуживания создаём для коллекции Update — Tests, чтобы видеть результаты работы этого периода во время тестирования.

Пользователь, со своей стороны, также может указать желаемый период обслуживания в центре программного обеспечения (Software Center):

Как же взаимодействуют между собой периоды обслуживания, которые настроил администратор на коллекциях и рабочие часы, которые настроил пользователь? На самом деле всё просто. Эти два периода нужно рассматривать как способ прийти к согласию с пользователями о времени установки обновлений после истечения крайнего срока установки. Configuration Manager не даст пользователю выставить рабочие часы 24 часа в сутки 7 дней в неделю. Если он попытается это сделать, то получит соответствующее предупреждение:

Настройки клиента, которые необходимо выполнить

Задержка принудительной установки ПО и обновлений

В SCCM 1706 доступен новый механизм задержки принудительной установки обязательного ПО и обновлений до следующего периода обслуживания клиента. Создано это для решения ситуаций, когда вернувшийся из отпуска сотрудник включает свой компьютер и попадает на длительную установку с перезагрузками всех просроченных обязательных развёртываний ПО и обновлений. Чтобы этого не происходило в настройках клиента в разделе \Administration\Overview\Client Settings задаём интервал Grace period for enforcement after deployment deadline (hours) в диапазоне от 1 до 120 часов. На русский это можно перевести как «Льготный период для принудительного применения после крайнего срока развертывания (ч)»:

Grace period for enforcement after deployment deadline

Теперь при создании развёртываний или правил автоматического развёртывания мы можем установить флажок Delay enforcement of this deployment according to user preferences, up to the grace period defined in client settings, что на русский можно перевести как «Отложить применение этого развертывания в соответствии с пользовательскими предпочтениями вплоть до окончания льготного периода, определенного в настройках клиента.».  При достижении крайнего срока установки (Installation Deadline) приложений или обновлений они будут установлены в первом нерабочем периоде, настроенном пользователем, в течение такого льготного периода (Grace period for enforcement after deployment deadline (hours)). По истечении льготного периода режим принудительного применения возвращается к нормальному поведению для просроченных развертываний.

Обновление ПО (Software Updates)

Проверяем включен ли главный параметр Enable software updates on clients. Если он отключен, то обновления не будут устанавливаться. Проверяем расписания.

Подробную информацию о параметрах этого раздела см. в документации: https://docs.microsoft.com/ru-ru/sccm/core/clients/deploy/about-client-settings#software-updates

Перезагрузка компьютера (Computer Restart)

Подробную информацию о параметрах см. в документации: https://docs.microsoft.com/ru-ru/sccm/core/clients/deploy/about-client-settings#computer-restart

Настройка уведомлений

Если вы хотите, чтобы пользователь получал уведомления о развёртываниях, то в разделе Computer Agent необходимо настроить соответствующие параметры. Подробнее в https://docs.microsoft.com/ru-ru/sccm/core/clients/deploy/about-client-settings#computer-agent

Файлы экспресс-установки для обновления Windows 10

Файлы экспресс-установки позволяют выкачивать только разницу между накопительным пакетом обновления за текущий месяц и обновлением за предыдущий месяц.

Начиная с версии 1702 Configuration Manager поддерживает файлы экспресс-установки для обновлений Windows 10. В самой же Windows 10 поддержка файлов экспресс-установки появилась начиная с версии 1607 с установленным кумулятивным обновлением от апреля 2017.

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

Включение поддержки экспресс-файлов на SUP

В разделе \Administration\Overview\Site Configuration\Sites открываем параметры точки обновления (Software Update Point):

На вкладке Update files выбираем соответствующий пункт:

Включение поддержки экспресс-файлов со стороны клиентов

Переходим в раздел \Administration\Overview\Client Settings:

В разделе Software Updates включаем поддержку файлов экспресс-установки:

Настройка правил замены обновлений (Supersedence Rules)

Для того, чтобы наш цикл развёртывания обновлений работал, нам нужно настроить  срок действия заменяемых обновлений. Для этого в свойствах точки обновления ПО указываем срок действия обновлений если для них вышло заменяющее.
Открываем раздел \Administration\Overview\Site Configuration\Sites, правым щелчком на нужном сайте выбираем меню настройки компонент сайта:

На вкладке Supersedence Rules настраиваем срок действия заменённых обновлений:

Группы обновлений — Software update groups (SUG)

Группы обновлений используются для организации обновлений и представляют собой логический контейнер, в который мы можем добавлять обновления автоматически с помощью правил автоматического развертывания (ADR) или вручную. После развёртывания группы обновлений мы можем добавлять в неё новые обновления и Configuration Manager автоматически их развернёт. В одном развёртывании может быть не более 1000 обновлений, соответственно, если группа имеет свой Deployment, то в неё нельзя включать больше 1000 обновлений. Если же группа не развёрнута, то такого ограничения нет. Группы без развёртываний могут быть полезны для отчёта о соответствии клиентов.

В рассматриваемом сценарии мы будем создавать новую группу обновлений каждый месяц с помощью правила автоматического развёртывания (ADR) и Baseline группы для продуктов не поддерживающих кумулятивный сценарий обновления.

Создание Baseline групп

Перед началом создания групп убедитесь, что необходимые продукты выбраны в параметрах точки обновления ПО (SUP) для синхронизации. И синхронизации проходят успешно.

Мы должны создать Baseline группы для каждого обновляемого продукта, который не поддерживает кумулятивную модель обновлений. В рассматриваемом сценарии мы создадим  Baseline группы перед началом процесса обновления для Office 2016, и одну общую группу для Silverlight, Skype for WIndows.
Переходим в раздел \Software Library\Overview\Software Updates\All Software Updates для поиска обновлений по следующим критериям:
Product = Office 2016
AND Superseded = No
Выбираем все найденные обновления Ctrl+A, правый клик -> Create Software Update Group (Создать группу обновлений ПО):

Отдельную общую группу можно создать для таких продуктов как Silverlight, Skype for Windows, Visual Studio и т.п.

Скачиваем Baseline SUG

Переходим в раздел \Software Library\Overview\Software Updates\Software Update Groups -> правый клик на нужной SUG -> Download:

Создаём новый пакет развёртывания. Создаём для него отдельную папку с тем же именем в общей папке:

Выбираем точки распространения, на которые будет загружен контент:

В разделе Distribution Settings выбираем параметры в соответствии с вашими требованиями:

Скачиваем обновления из интернет или, если есть, из папки в локальной сети:

Выбираем требуемые языки:

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

После завершения загрузки проверяем все ли обновления успешно скачались:

Аналогичным образом создаём Baseline SUG для других продуктов, если необходимо.

Разворачиваем Baseline группы

Сначала мы развернём эту группу на коллекцию Update — Tests

Имя развёртывания укажем такое же, как и имя группы и назначим на коллекцию Update — Tests

Тип развёртывания — обязательное:

В расписание развёртывания выбираем время доступности и крайний срок установки как можно скорее (As soon as possible). Не забываем выставить флажок Delay enforcement of this deployment according to user preferences, up to the grace period defined in client settings. Это позволит произвести установку в следующий интервал обслуживания. Льготный период (grace period) мы настроили ранее в параметрах клиента.

В разделе User Experience выбираем параметры уведомления пользователей, поведение при достижении крайнего срока и параметры перезагрузки систем. Не забываем выставить флажок Software updates deployment re-evaluation behavior upon restart (Поведение цикла повторной оценки для развертывания обновлений после перезапуска). Этот параметр доступен начиная с версии Configuration Manager 1606. Устанавливаем флажок, чтобы клиенты выполняли проверку соответствия обновлений ПО сразу после установки обновлений и перезапуска. Это позволяет клиенту выполнить проверку наличия дополнительных обновлений программного обеспечения, которые стали применимыми после перезагрузки клиента, и которые также можно установить в тот же период обслуживания.

В разделе Alerts выбираем параметры генерации предупреждений, если необходимо и жмём далее.

В разделе Download Settings выбираем параметры скачивания обновлений в различных границах:

Выбираем пакет развёртывания, который мы создали на этапе загрузки обновлений:

На странице Download Location выбираем вариант скачать из Интернет, несмотря на то, что они у нас уже загружены. Мастер проверит пакет на наличие загруженных обновлений и не будет повторно их выкачивать.

Затем выбираем те же языки и проверяем страницу Summary.

После проверки обновлений и режимов установки на тестовой коллекции повторяем шаги развёртывания Baseline группы на коллекцию Update — Production. В результате для группы обновлений должно быть создано 2 развёртывания:

Повторяем эти шаги для всех Baseline групп, которые нам необходимо создать.

Правила автоматического развертывания (ADR)

После создания и развёртывания Baseline групп мы переходим к настройке будущих обновлений для наших систем.

Большая часть процесса управления обновлениями может быть выполнен вручную или автоматически (начиная с SCCM 2012) с помощью Automatic Deployment Rules (ADR). ADR автоматически создают необходимые группы обновлений (SUG), пакеты развёртывания (Deployment Packages) и развёртывания (Deployments).
В рассматриваемом нами сценарии мы создадим одно правило ADR, которое мы будем запускать вручную. Можно, конечно, автоматизировать процесс полностью, но в таком ответственном деле, как развёртывание обновлений, всё же желательно иметь контроль.

Создание ADR

Наше правило ADR создавать SUG и разворачивать её на коллекцию Update — Tests и Update — Production. Для коллекции Update — Production обновления будут доступны с задержкой в 16 дней, которые необходимы для прохождения всех этапов тестирования на коллекции Update — Tests.

В рассматриваемом примере, мы не будем разделять группы обновлений и правила ADR по продуктам. Ещё со времён SCCM 2012 Microsoft рекомендовала создавать группы обновлений на хронологической основе (ежемесячные, ежеквартальные, ежегодные). С введением новой концепции накопительных обновлений эта рекомендация стала носить более здравый смысл. Напомню, что с октября 2016 года Microsoft изменила концепцию обновления ОС Windows 7 SP1, Windows 8.1, Windows Server 2008 R2, Windows Server 2012/2012 R2. Теперь MS выпускает единый ежемесячный накопительный пакет обновлений для Windows, который включает как обновления безопасности, так и обновления, относящиеся к стабильности и надежности работы ОС. Накопительный пакет текущего месяца заменяет накопительный пакет предыдущего месяца, так что необходима установка единственного обновления Windows, чтобы привести вашу систему в актуальное состояние. Таким образом, модель обновления указанных ОС приведена к модели обновления Windows 10. Подробнее об этом см. в https://blogs.technet.microsoft.com/securityrus/2016/09/26/windowsrollup/.
Смешивание в одной группе обновления патчей для разных ОС и продуктов не сказывается на их установке. Клиенты «сами решают» какие обновления к ним применимы. К тому же есть категории обновлений, которые необходимо назначать на все компьютеры независимо от ОС, например для продуктов MS Office.
Разделение правил и групп по продуктам может понадобится вам в случае большого количества обновляемых продуктов, которые не поддерживают кумулятивные обновления. Например несколько версий Office, Windows 7, Windows Server 2008 и др. 

Переходим в раздел \Software Library\Overview\Software Updates\Automatic Deployment Rules

Указываем имя ADR, коллекцию, на которую оно будет распространяться. Выбираем пункт Create a new Software Update Group, чтобы при каждом запуске правила создавалась отдельная группа с месячными обновлениями.

Создание отдельной группы SUG каждый месяц необходимо для того, чтобы не превышать предельное количество в 1000 обновлений на одно развёртывание. Использовать одну и ту же группу SUG имеет смысл только если вы создаёте ADR для развёртывания сигнатур Endpoint Protection.

Также выбираем опцию Enable the deployment after this rule is run, которая позволяет автоматически создавать развёртывание группы обновлений при запуске правила. Можно выбрать шаблон Patch Tuesday, чтобы посмотреть, какие параметры предлагают разработчики SCCM для ежемесячных обновлений.

В разделе Deployment Settings мастера оставляем всё по умолчанию:

В разделе Software Update настраиваем требуемые опции. В нашем случае мы будем обновлять Windows 10, Windows 10 LTSB, Office 2016, Skype for Windows, Silverlight в русском и английском языках. Также указываем дату релиза — за последний месяц. В классификации обновлений указываем требуемые параметры. Напомню, что класс Upgrades применим к Windows 10 и под этим классом выпускаются обновления по переходу на следующий релиз Windows 10. Здесь мы не будем скачивать их, т.к. в нашем случае используются планы обслуживания WIndows 10 (подробнее см. Обновление Windows 10 с помощью планов обслуживания Configuration Manager). Подробнее о классификации обновлений см. в документации https://docs.microsoft.com/en-us/sccm/sum/get-started/configure-classifications-and-products.

Здесь же можно исключать обновления, например по Article ID, добавив перед номером знак -. Для Windows 7, Windows Server 2008 выходят обновления Preview of Monthly Quality Rollup, которые выходят неделю спустя после дня выхода основных обновлений. Установка в организации таких предварительных исправлений противопоказана. Здесь также можно настроить фильтр для таких обновлений, выбрав фильтр Title и указав в нём текст поиска -%Preview%
Использовать критерий Required я не рекомендую, т.к. не все компьютеры вовремя передают свой статус, либо не передают его вообще.

Настроенные параметры фильтров можно проверить, используя кнопку Preview:

В разделе Evaluation Schedule выбираем Do not run this rule automatically, чтобы оставить за собой возможность запускать правило вручную.

Вкратце поясню здесь о проблеме планирования расписания запуска ADR на время выхода обновлений. Как известно, обновления выходят каждый второй вторник месяца примерно в 10 утра по Лос-Анджелесу (UTC -8 с ноября по март и UTC -7 с марта по октябрь). Если разница вашего локального времени с временем выпуска обновлений больше 14 часов, то у вас уже наступила среда.

Поэтому запланировать запуск ADR на второй вторник месяца у вас не получится, а вторая среда месяца не всегда следует за вторым вторником месяца.
Решений у этой проблемы три: -запускать ADR каждый месяц вручную; -настроить запуск ADR на произвольную дату месяца, которая гарантированно позже возможного второго вторника в этом месяце; -использовать сценарий для планирования запуска ADR https://gallery.technet.microsoft.com/PowerShell-Script-to-d90742dc#content

В разделе Deployment Schedule настраиваем расписание доступности обновлений и крайний срок установки (Installation deadline). Также устанавливаем флажок Delay enforcement of this deployment according to user preferences, up to the grace period defined in client settings («Отложить применение этого развертывания в соответствии с пользовательскими предпочтениями вплоть до окончания льготного периода»). Сам льготный период мы уже настроили (см. раздел Задержка принудительной установки ПО и обновлений).

В разделе User Experience настраиваем:

  • Уведомления пользователя (User notification): следует ли отображать обновления программного обеспечения в центре программного обеспечения и следует ли отображать на клиентских компьютерах уведомления для пользователей.
  • Действие при достижении крайнего срока (Deadline behavior): указываем, следует ли устанавливать обновления программного обеспечения в развертывании, а также, следует ли выполнять перезапуск системы после установки обновлений программного обеспечения, независимо от настроенного периода обслуживания. Если эти флажки установлены, то развёртывание и перезапуск произойдут невзирая на период обслуживания, если отключены, то установка и перезапуск будут произведены в период обслуживания.
  • Действие при перезапуске устройства (Device restart behavior): указываем, следует ли блокировать перезапуск систем на серверах и рабочих станциях после установки обновлений программного обеспечения, для завершения установки которых требуется перезапуск.
    На всякий случай выставим запрет перезапуска для серверов.
  • Обработка фильтра записи для устройств Windows Embedded: используем только при развертывании обновлений на устройствах под управлением Windows Embedded, на которых включены фильтры записи.
  • Поведение цикла повторной оценки для развертывания обновлений после перезапуска (Software updates deployment re-evaluation behavior upon restart). Этот параметр доступен начиная с версии Configuration Manager 1606. Устанавливаем флажок, чтобы клиенты выполняли проверку соответствия обновлений ПО сразу после установки обновлений и перезапуска. Это позволяет клиенту выполнить проверку наличия дополнительных обновлений программного обеспечения, которые стали применимыми после перезагрузки клиента, и которые также можно установить в тот же период обслуживания.

В разделе Alerts выбираем желаемые параметры оповещений:

В разделе Download Settings выбираем параметры скачивания обновлений в различных границах:

В разделе Deployment Package выбираем пункт создать новый, либо, если у вас уже есть, указываем существующий пакет.

Пакет развёртывания (Deployment Package) это всего лишь хранилище контента обновлений и его можно использовать для разных групп обновлений, а также он может содержать в себе обновления для нескольких ОС и других продуктов. Со времён SCCM 2012 существует рекомендация создавать новый пакет развёртывания два раза в год.

В разделе Distribution Point указываем точки распространения:

В разделе Download Location выбираем скачивать из Интернет:

В разделе Language Selection выбираем необходимые языки:

В разделе Summary просматриваем ещё раз выполненные настройки и сохраняем шаблон, если необходимо

Создание дополнительного развёртывания для коллекции Update — Production

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

Возможность добавлять дополнительные развёртывания к ADR появилась в ConfigMgr 1511, но не работала должным образом. Начиная с версии 1606 можно смело использовать этот функционал и создавать нужные развёртывания одним правилом ADR.

Указываем коллекцию и ставим флажок создавать развёртывание после запуска правила:

В разделе Deployment Settings оставляем параметры по умолчанию.
В разделе Deployment Schedule настраиваем параметры доступности и крайнего срока установки таким образом, чтобы вы успели провести тестирование обновлений на пилотной группе.

На вкладке User Experience выбираем необходимы параметры. Подробно мы их рассмотрели в начале создания правила ADR:

Последующие страницы мастера настраиваем по своим требованиям. После создания дополнительного развёртывания у нас должна быть такая картина:

Ежемесячный процесс обновления

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

Статус синхронизации

После того, как Microsoft выпустит обновления, идём в раздел Monitoring / Software Update Point Synchronization Status и проверяем статус синхронизации:

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

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

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

Запускаем правило ADR:

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

Таким образом, для коллекции Update-Tests обновления будут доступны почти сразу после запуска правила ADR, а для коллекции Update — Production они будут доступны для установки спустя 16 дней после запуска правила.

Управление процессом обновления

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

Удаление заменённых обновлений

В процессе развёртывания обновлений важно регулярно выполнять очистку заменяемых обновлений. В SCCM есть механизм автоматической очистки заменённых обновлений (superseded). Если заменённое обновление не включено ни в одну группу обновлений, то Configuration Manager автоматически удалит его через 7 дней. С точек распространения (Distribution Points) файлы также будут удалены автоматически самим SCCM. Поэтому важно проверять группы на наличие заменённых обновлений и исключать их из всех групп.
Как только в какой-либо группе обновления появится заменённое обновление, то значок группы станет таким:

Подробнее о всех значках здесь: https://docs.microsoft.com/ru-ru/sccm/sum/understand/software-updates-icons

Очистка WSUS и переиндексация SUSDB

Для автоматической очистки WSUS включаем соответствующий параметр в настройках точки обновления:

Галочка Run WSUS cleanup wizard позволяет автоматически удалять заменённые (superseded) и удалённые обновления из папки WSUS на диске, а также из базы данных WSUS.
Параметр появился в версии 1511. Также проверяем настройки  замены (Supersedence behavior).

Подробнее о том, как запланировать переиндексацию базы данных SUSDB см. в статье Автоматическая очистка сервера WSUS и переиндексация базы данных SUSDB.

Средство очистки ContentLibraryCleanup.exe

Начиная с версии 1702 появилась утилита командной строки ContentLibraryCleanup.exe, которая позволяет удалять содержимое из точек распространения, которое больше не связано с пакетами или приложениями.
Инструмент находится в %CM_Installation_Path%\cd.latest\SMSSETUP\TOOLS\ContentLibraryCleanup*
Подробная документация https://docs.microsoft.com/ru-ru/sccm/core/plan-design/hierarchy/content-library-cleanup-tool

Начиная с версии 1702 Configuration Manager научился автоматически удалять старые обновления из папки %CM_Installation_Path%\EasySetupPayload. В эту папку скачиваются обновления для самого SCCM (раздел \Administration\Overview\Updates and Servicing).

Скрипт PowerShell по очистке пакетов развёртывания

Для очистки пакетов развёртывания от ненужных файлов обновлений можно использовать скрипт, который создал Nickolaj Andersen: http://www.scconfigmgr.com/2017/08/17/clean-software-update-packages-in-configmgr-with-powershell/.

Сценарий доступен на GitHub , на всякий случай выложу его здесь Clean-CMDeploymentPackage.

В текущей версии скрипт позволяет удалять файлы обновлений которые не развёрнуты или не требуются ни одной системе:

Копируем сценарий локально, открываем PowerShell c повышением привилегий. Для запуска используется Package ID:

Package ID находим здесь:

Ключами -NonDeployedUpdates -NonRequiredUpdates можно соответственно удалить не развёрнутые обновления и не требующиеся к установке. С помощью ключей -ShowProgress и -Verbose отображаем ход процесса в консоль:

Управление группами SUG

Рассмотрим один из подходов к управлению группами обновлений, который рекомендует Microsoft. Данный подход также не является единственно правильным. Необходимо соотносить нужды и требования вашей инфраструктуры с возможностями, которые предоставляет нам механизм SUG.

Итак, MS предлагает создавать нам следующие группы:

Группы отчётов (Reporting groups) — эти группы не разворачиваются и используются только для просмотра отчёта о соответствии ваших систем. Т.к. группы не разворачиваются, то и не имеют ограничения в 1000 обновлений.

Группы развёртывания (Rollup groups или Baseline) — Когда вы начинаете разворачивать обновления через SCCM первое, что нужно сделать — это привести все системы в единое начальное состояние. Rollup или Baseline группы используются для такой отправной точки развёртывания обновлений. В них включают все доступные обновления на текущий момент. Такие группы целесообразно разделять по продуктам (отдельная SUG для каждой ОС), т.к. суммарное количество обновлений, например, для Windows 7 уже более 700.

Ежемесячные группы (Monthly groups) — Создаются правилом ADR автоматически, как рассмотрели ранее в этой статье.

Ежеквартальные и ежегодные группы (Quarterly and yarly groups) — используются для общего обзора соответствия ваших систем в течение квартала или года.

В эти группы нужно переносить обновления из ежемесячных групп, не включая в них заменённые обновления.

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

Для переноса обновлений из одной группы в другую выполняем следующие действия:

Переходим в раздел  \Software Library\Overview\Software Updates\Software Update Groups, выбираем группу из которой нужно перенести обновления и находим всех членов данной группы:

В открывшемся списке выбираем все обновления Ctrl+A и через правый клик выбираем меню Edit Membership:

Таким же методом удаляем заменённые (Superseded) обновления из всех групп, если они больше не нужны.

Мониторинг и отчёты

Каждый клиент после завершения поиска обновлений отправляет своё состояние соответствия (compliance state) на сервер SCCM. Эти данные используются для оценки состояния развёртываний обновлений. В Configuration Manager доступны 4 состояния соответствия:
1. Установлено (Installed) — означает, что обновление применимо к системе и уже установлено.
2. Не требуется (Not Required) — означает, что обновление не применимо к системе.
3. Требуется (Required) — означает, что обновление применимо к системе, но ещё не установлено. Либо обновление уже установлено, но статус о его установке ещё не отправлен на сервер.
4. Не известно (Unknown) — две ситуации: либо клиентская система не завершила сканирование, либо сервер сайта не получил данные о состоянии клиента.

Для просмотра состояний компьютеров по группам обновлений перейдём в раздел Monitoring / Deployments, двойной щелчок на интересующем развёртывании:

На четырёх вкладках представлена текущая картина по развёртыванию.

Встроенные отчёты

В Configuration Manager 1706 после развёртывания точки служб отчётов доступно 470 предустановленных отчётов. Из них 30 по обновлению ПО:

По развёртыванию точки служб отчётов см. статью Развёртывание System Center Configuration Manager 1702. Часть 8 – Установка точки служб отчётов

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