Это заметка о том, как развернуть роль Software Update Point (SUP) в System Center 2012 Configuration Manager (SCCM). Она написана в рамках моего небольшого опыта в этой области, и поэтому не может претендовать на какую-то исключительность и полноту. Перед началом описания процесса хочу отметить то, что описанное ниже ни коим образом не может заменить официальной документации Библиотека TechNet - Обновление программного обеспечения в Configuration Manager, а может лишь использоваться в качестве дополнительного наглядного материала. Конфигурация описанная здесь является самой типичной и не учитывает каких-то особенностей типа построения отказоустойчивой роли SUP с использованием NLB и т.п. Исходные условия таковы, что имеется уже развёрнутая и работающая инфраструктура SCCM 2012 c центральным сайтом Central Administration site (CAS) и дочерними первичными и вторичными сайтами. Рассмотрим цепочку настройки роли SUP на каждом уровне иерархии.
На первом этапе роль SUP должна быть развернута и сконфигурирована на CAS, затем мы настроим подчинённый первичный сайт, а вслед за ним уже и подчинённый вторичный сайт.
Для развертывания роли SUP на серверах SCCM потребуются серверные компоненты WSUS. Фактически исполняемые файлы WSUS играют роль транспорта для доставки метаданных и контента обновлений в SCCM.
Перед началом развёртывания SUP (предполагая что документация уже прочитана), нужно задуматься о планировании дискового пространства на серверах SCCM. Сам контент обновлений, которым будет оперировать SUP будет хранится фактически в двух местах:
1) В специально созданной сетевой папке, в которую будет происходить непосредственная загрузка обновлений из Интернета. Папка может быть расположена как на самом сервере SCCM так и на удалённом файловом сервере. Обновления будут загружаться в эту папку в процессе создания пакетов обновлений.
2) На каждом сервере SCCM с активными ролями SUP и точки распространения (Distribution Point (DP)), с которого планируется установка обновлений на клиенты. То есть фактически файлы обновлений будут копироваться в библиотеку точки распространения (каталог SCCMContentLib) из вышеуказанной сетевой папки при развёртывании пакетов обновлений, которые в последствии будут распространены на клиентов.
На самом деле, идеологию размещения и категоризации загружаемых из Интернета файлов обновлений нужно выбирать в зависимости от вашего рабочего окружения (инфраструктура площадок, качество каналов связи т.п.). В нашем примере папка (п.1) будет создана немного позже на отдельном файловом сервере, хотя возможно кто-то посчитает что такую папку резонней было бы размещать на сервере CAS.
Настройка SUP на CAS
На любом уровне иерархии SCCM для включения роли SUP на сервере сайта предварительно должны быть установлены компоненты WSUS 3.0 SP2. В документации можно найти упоминание о том, что если на сервере ранее уже функционировал WSUS, то можно использовать существующий экземпляр. Однако, учитывая “весёлые приключения” тех товарищей, которые пробовали это сделать, крайне рекомендуется удалить существующий экземпляр WSUS и установить его заново. Если же на сервере была установлена только консоль WSUS, то её также нужно деинсталлировать для того чтобы установить полный экземпляр WSUS.
Скачиваем WSUS30-KB972455-x64.exe и в мастере установки выбираем полный тип установки – Full server installation including Administration Console
Выбираем папку на локальном диске сервера в которой будут храниться загружаемые файлы WSUS. Фактически WSUS не будет сохранять в этой папке большой объём файлов, как это происходит в классическом варианте использования WSUS. В моей конкретной ситуации, у уже функционирующих серверов с ролью SUP на всех уровнях иерархии, размер этой папки не превышает 150Mb
Обязательно включить опцию локального сохранения контента – Store updates locally. Она нужна для того, чтобы для всех обновлений, метаданные которых будут храниться в БД WSUS/SUP, была возможность загрузить и сохранить файлы соглашений EULA.
На этапе выбора экземпляра SQL Server для БД WSUS можно выбрать локальный существующий экземпляр, на котором работает сайт SCCM.
После успешного подключения к экземпляру SQL Server выбираем создание отдельного веб-сайта для WSUS в IIS с использованием портов 8530/8531 – Create a Windows Server Update Services 3.0 SP2 Web site
В конце процесса установки дожидаемся автоматического запуска мастера настройки сервера WSUS и отказываемся от настройки. Важно помнить, что всю необходимую настройку службы WSUS SCCM будет выполнять самостоятельно и поэтому крайне не рекомендуется выполнять какие-то самостоятельные настройки в консоли WSUS.
После того как служба WSUS установлена, переходим к включению роли SUP в консоли SCCM на CAS. В разделе консоли
Administration\Overview\Site Configuration\Servers and Site System Roles
выделяем верхний сайт иерархии и вызываем мастер добавления ролей – Add Site System Roles
В открывшемся мастере отмечаем роль Software update point
Если для соединения с интернетом используется прокси сервер, можем указать его адрес. В нашей ситуации на сервере Forefront TMG создано специальное правило, разрешающее без авторизации подключаться к сайтам Microsoft Update с сервера SCCM, поэтому опции остаются ненастроенными. Из документации:
По умолчанию для подключения к Интернету и загрузки обновлений при запуске правил автоматического развертывания используется учетная запись Локальная система сервера, на котором было создано правило автоматического развертывания. Если у этой учетной записи нет доступа в Интернет, обновления программного обеспечения не будут загружены, а в файл журнала ruleengine.log будет добавлена следующая запись: Не удалось загрузить обновление из Интернета. Ошибка = 12007. Настройте учетные данные для подключения к прокси-серверу, если у учетной записи "Локальная система" нет доступа в Интернет.
Отмечаем опцию определяющую создание активной роли SUP и конфигурирующую параметры взаимодействия с исполняемыми модулями WSUS – Use this server as the active software update point. Здесь же выбираем вариант конфигурирования веб-сайта IIS который был использован при установке WSUS – с использованием портов 8530/8531
Так как выполняется настройка сервера верхнего уровня иерархии SUP, в качестве источника обновлений указываем – Synchronize Microsoft Update.
Здесь же отключаем опцию отсылки клиентами отчётов на WSUS, так как мониторинг состояния установки обновлений мы будем выполнять в консоли SCCM – Do not create WSUS reporting events
Далее включаем синхронизацию по расписанию и указываем расписание синхронизации. Обратите внимание на то, что расписание указывается только на сайте верхнего уровня. После того как сайт верхнего уровня (в нашем случае CAS) выполнит синхронизацию с сайтом MS - сразу же будет автоматически запущена процедура синхронизации метаданных на подчинённых первичных сайтах, которые в свою очередь запустят синхронизацию на подчинённых вторичных сайтах SCCM.
При планировании расписания можно вспомнить документацию:
Одним из типичных сценариев является настройка расписания синхронизации обновлений таким образом, чтобы синхронизация запускалась через некоторое время после регулярного выпуска обновлений безопасности Майкрософт во второй вторник каждого месяца
В нашем примере выбран вариант ежедневной синхронизации в 6 часов утра, исходя из тех соображений, что нам потребуется ежедневное обновление антивирусных писаний System Center Endpoint Protection
На следующем шаге определяемся с тем, как SCCM должен поступать с обновлениями, которые заменены другими обновлениями. В нашем примере выбран вариант немедленного окончания срока действия заменённых обновлений – Immediately expire a superseded software update
Содержательная выдержка из документации по этому поводу:
На странице "Правила замены" можно указать, что срок действия заменяемых обновлений ПО истекает немедленно. При этом такие обновления уже не включаются в новые развертывания, а для существующих развертываний указывается, что они содержат одно или несколько обновлений с истекшим сроком действия. Или же можно указать период времени, после которого истечет срок действия заменяемых обновлений ПО, что позволит по-прежнему их развертывать. Оцените следующие сценарии, в которых может потребоваться развернуть заменяемое обновление.
- Если заменяющее обновление поддерживает только более новые версии операционной системы, а некоторые клиентские компьютеры работают под управлением прежних версий операционной системы.
- Если заменяющее обновление обладает более ограниченной областью применения по сравнению с заменяемым обновлением, из-за чего новое обновление может оказаться непригодным для некоторых клиентских компьютеров.
- Если процесс управления изменениями допускает развертывание только проверенных обновлений ПО, вне зависимости от того, заменяемые они или нет, а заменяющее обновление не было проверено на возможность развертывания в вашей рабочей среде.
На следующих двух шагах мастера снимите все флажки для классов обновлений и продуктов. Мы настроим эти параметры позже, потому что после первой синхронизации с Microsoft Update перечень этих значений изменится, к тому же, скорее всего нам не понадобятся метаданные о всех продуктах отмеченных по умолчанию, и даже будут потом нам мешать.
На следующем шаге мастера нам будет предложено настроить языковые предпочтения для метаданных и файлов обновлений. Довольно подробно описаны эти опции в документации:
Software update File (Файл обновления программного обеспечения)
Языки, настроенные с помощью параметра "Файл обновления программного обеспечения", представляют собой набор языков по умолчанию, которые будут доступны при загрузке обновлений на сайте. Настройте параметры языков файлов обновлений ПО, выбрав языки, наиболее часто использующиеся в вашей среде. Например, если на клиентских компьютерах на сайте используются главным образом английский и русский языки, а другие языки практически не используются, выберите в столбце "Файл обновления программного обеспечения" английский и русский языки и снимите флажки для всех прочих языков. После этого при загрузке или развертывании обновлений языки будут автоматически выбираться по умолчанию в мастере на странице "Выбор языка". При необходимости можно выбрать другие языки.
Summary Details (Сводные данные)
Сводные данные — это метаданные обновлений программного обеспечения. Метаданные содержат информацию об обновлении: имя, описание, поддерживаемые продукты, класс обновления, ИД статьи, URL-адрес загрузки, правила применения и т. п. При выборе языков для сводных данных выбирайте лишь те языки, которые необходимы в вашей среде. Метаданные обновлений ПО отображаются на языке операционной системы, в которой запущена консоль Configuration Manager. Если локализованные свойства обновлений недоступны, информация будет показана на английском языке…. Чем больше языков выбрано для отображения сводных данных, тем дольше продлится синхронизация обновлений ПО…
Важно! Перед первым запуском синхронизации обновлений ПО выберите все языки сводных данных, необходимые в иерархии Configuration Manager. Несмотря на то, что можно изменить языки в сводных данных после синхронизации точки обновления на сайте центра администрирования, метаданные на новых языках не будут загружаться для уже синхронизированных обновлений, если не появится обновленной версии этих обновлений.
После завершения работы мастера настройки роли, должна выполниться первоначальная синхронизация, в ходе которой получение метаданных обновлений не выполнится, так как мы отключили все категории, а произойдёт только обновление списка классов и продуктов в службах WSUS и в Configuration Manager. Отследить статус её завершения можно в разделе консоли:
Monitoring\Overview\Software Update Point Synchronization Status
После завершения первой синхронизации нам нужно снова зайти в свойства роли SUP и выполнить настройку необходимых классов и продуктов уже в обновлённом их составе, после чего сразу запустить повторную синхронизацию в разделе консоли
Software Library\Overview\Software Updates\All Software Updates
Опция ручного запуска синхронизации верхнего уровня доступна только при подключении к CAS
После того как вторая синхронизация будет закончена, мы получим непосредственный набор метаданных по тем классам и продуктам, которые выбрали и все эти данные станут отображаться в разделе All Software Updates
Настройка SUP на серверах подчинённых сайтов
Устанавливаем роль SUP по иерархии сначала на серверах подчинённых первичных, а затем вторичных сайтов SCCM. Так же как и в случае с CAS, предварительно поднимаем WSUS 3.0 SP2 с той же последовательностью действий, что описана ранее. Отличием будет разве что только выбираемый экземпляр БД для размещения локальной БД WSUS
Итак, после установки компонент WSUS, поднимаем роль SUP с синхронизацией с сервера вышестоящего уровня иерархии SCCM. В дальнейшем описании буду приводить скриншоты из локализованной консоли SCCM
Выполняем первую синхронизацию подчиненного сервера с вышестоящим. В результате успешной синхронизации версии каталога метаданных должны совпадать.
Если требуется получить более подробные сведения о процессе синхронизации, можно изучить файл wsyncmgr.log, расположенный в каталоге <путь_установки_Configuration_Manager>\Logs на каждом сервере сайта.
Итак, “скелет” нашей инфраструктуры SUP настроен, далее настроим параметры клиентов и затем перейдём к процедурам наполнения контентом и проверки функциональности.
Настройка параметров клиента SCCM
Для того чтобы задействовать на клиентах SCCM функционал получения обновлений с SUP, перейдём в раздел консоли
Администрирование\Обзор\Параметры клиентов
выберем применяемый к нашим клиентам набор параметров, откроем его свойства и на закладке Обновления программного обеспечения включим соответствующую опцию и настроим расписание периодических проверок обновления на клиентах.
Обратите внимание на то, что при планировании расписания можно указать интервал меньше 1 дня, но как утверждает документация, минимально будет по умолчанию использован 1 день. Опять же из документации:
Фактическое время запуска на клиентских компьютерах равно сумме заданного времени запуска и случайного промежутка времени продолжительностью до 2 часов. Это позволяет избежать одновременного запуска проверки и подключения клиентских компьютеров к службам WSUS на сервере активной точки обновления.
Отключение параметров WSUS в GPP
Для того чтобы объяснить клиентам месторасположение источника служб обновлений, SCCM использует функционал автоматической настройки локальной групповой политики на клиентских ПК. Поэтому, если для настройки имени сервера WSUS мы ранее использовали доменные групповые политики, то нам нужно выключить такие параметры доменных GPP, чтобы избежать конфликты между этими доменными политиками и локальными, которые настраиваются непосредственно клиентом SCCM. Убедиться в этом можно открыв оснастку редактирования локальной групповой политики (gpedit.msc)
Подготовка сетевой папки для исходных файлов SUP
Как я отметил в самом начале, нужно создать специальную сетевую папку, в которую будет происходить непосредственная загрузка исходных файлов обновлений из Интернета. На скриншотах приведённых ниже можно понять что папка исходных файлов размещена на самом сервере SCCM. И пусть вас это не смущает, так как изначально так и было, однако спустя некоторое время было решено переместить её на отдельный файловый сервер (файловый кластер). При настройке разрешений на сетевую папку нужно добавить полные права для учетной записи сервера SUP, который в дальнейшем будет выполнять загрузку обновлений из Интернета по расписанию в эту папку.
В созданной сетевой папке нужно создать структуру каталогов для группировки обновлений. Структура каталогов может быть в каждом окружении своя и будет зависеть от логики разделения обновлений на обобщающие сущности SCCM – Группы обновлений. На основе Групп обновлений в SCCM будут создаваться Развёртывания обновлений, которые по сути своей являются связующим звеном между Группами и Коллекциями компьютеров на которые эти Группы назначаются. При выборе тактики группировки обновлений необходимо помнить об одном важном жёстком ограничении SCCM 2012 - Количество обновлений назначаемых в одном Развёртывании не может превышать 1000 штук, а так как между Развертыванием и Группой прямая зависимость – мы должны спланировать разбиение на Группы таким образом, чтобы у нас не было ни одной группы с количеством обновлений больше этого предела.
Есть мнения, что более логично будет разгруппировать обновления по временному признаку, то есть например создать поквартальные или помесячные группы обновлений и в практиках применения SUP чаще всего именно такой подход и используется. В нашем случае выбран несколько иной подход – группировка по продуктам, к которым относятся обновления.
На тему выбора порядка группировки конечно можно развести полемику, так как у любого порядка группировки есть свои плюсы и минусы. Группировка по продуктам, даёт на мой взгляд бОльшую гибкость с точки зрения развертывания групп в иерархии SCCM. Например мы можем создать группу обновлений для Windows 7 но выполнять её развёртывание будем только на DP тех дочерних сайтов, где присутствуют клиенты с такой ОС. И по такому же принципу можно будет отдельно удалять c DP пакеты обновлений для продуктов, которые перестали использоваться, сокращая при этом объём используемого дискового пространства. Это может быть особенно актуально для структурных подразделений, ограниченных в серверных ресурсах. Однако, надо также понимать, что такой метод группировки обновлений с точки зрения процесса тестирования и развертывания новых обновлений будет более трудозатратен для администратора SUP.
Создание групп обновлений
В консоли SCCM для создания основных группы обновлений переходим в раздел
Библиотека программного обеспечения\Обзор\Обновления программного обеспечения\Все обновления программного обеспечения
Когда полный список обновлений будет загружен, включаем Фильтр по условиям – Продукт (выбрать нужный) и Замена (выбрать Нет)
При этом будут отобраны обновления относящиеся к конкретному продукту и не заменённые при этом другими обновлениями. для создания группы выделяем все отфильтрованные обновления и нажимаем соответствующую кнопку – Создать группу обновлений программного обеспечения
Практика использования SUP подсказывает, что возможно потребуется создать отдельные группы обновлений, которые применимы сразу к нескольким версиям продукта, например есть обновления которые применимы ко всем редакциям Windows. Чтобы сразу “отловить” такие обновления для включения их в отдельную группу потребуется в списке отображения обновлений вывести дополнительную колонку Продукт
Если мы сразу не учтём этот момент, то в результате можем получить ситуацию, при которой одно и тоже обновление входит в состав разных групп, а это как минимум приведёт к тому, что в сетевой папке исходных файлов обновлений один и тот же файл (иногда очень приличного размера) будет загружаться в разные каталоги.
Если в нашем окружении используется разветвлённая иерархия и настроено делегирование административных функций SCCM, опирающееся на Области безопасности, то возможно нам дополнительно потребуется настроить Области безопасности для вновь созданных Групп обновлений в разделе консоли
Библиотека программного обеспечения\Обзор\Обновления программного обеспечения\Группы обновлений программного обеспечения
Развёртывание групп обновлений (пакетов)
Разворачиваем каждую группу обновлений на коллекцию компьютеров, на которые мы планируем устанавливать обновления. Перед созданием развертывания необходимо определиться с типом развёртывания. Есть два основных типа - Обязательное развертывание и Доступность к установке. Например на рабочих станциях пользователей резонно использовать первый тип развертывания, при котором обновления автоматически устанавливаются в системе, а на серверных системах возможно более логично использовать второй тип, при котором обновления будут ждать ручного запуска процесса установки. Исходя из такой логики можно создать две коллекции, на которые мы и будем выполнять развёртывание с соответствующим типом
Рассмотрим пример создания развертывания конкретной группы обновлений на коллекцию рабочих станций. Выбираем интересующую нас группу обновлений и вызываем команду Развернуть
Открывается мастер развертывания, где на первом этапе задаём понятное имя для нашего развёртывания и выбираем коллекцию компьютеров на которую мы хотим нацелить группу обновлений.
Если среди обновлений, входящих в развёртываемую группу есть обновления имеющие лицензионные соглашения, то возможно мы получим запрос на принятие таких соглашений.
Далее – важный шаг - выбираем тип развёртывания. Обратите внимание на то, что нужно заранее определиться с типом развёртывания, так как после создания развертывания изменить его тип уже будет нельзя без повторного прохождения процедуры развертывания.
Время доступности и крайний срок установки выбираем в зависимости от ситуации. В нашем конкретном примере речь идёт о развертывании обновлений Windows 7 на рабочие станции и мы выбираем незамедлительную установку обновлений.
Здесь мне хочется сразу сделать одно уточнение, к которому я пришёл уже после некоторой практики использования SUP. Если использовать необязательный тип развёртывания (доступность к установке) , например для серверов, мы получим ситуацию (по крайней мере в SCCM 2012 RTM это именно так) когда установку каждого из обновлений доступных для установки на целевой системе придётся запускать отдельным кликом мыши, и при это ещё и ждать установку каждого обновления, чтобы запустить следующее. То есть нельзя будет одним нажатием кнопки запустить установку сразу всех назначенных обновлений как при использовании классического апплета панели управления клиента WSUS. Поэтому, что бы избежать данной ситуации, можно использовать для всех групп обновлений обязательный тип развёртывания, но для тех развертываний где требуется отложенная установка (как например на серверных системах) просто выставлять большой Крайний срок установки, например 2020 год. И тогда можно будет на серверных ОС использовать функцию пакетной установки всех обязательных обновлений и делать это тогда когда вам удобно.
Прочие настройки развертывания, как говориться “по вкусу”, только нужно не забыть про блокировку перезагрузки после установки обновлений.
Далее указываем Пакет развертывания, в который будут помещены все обновления Группы обновлений. Здесь Пакет выступает как объект которым манипулирует роль точки распространения (DP). То есть на точки распространения дочерних сайтов сами файлы обновлений будут поступать именно в виде таких Пакетов. То есть фактически именно мастер развертывания выполняет логическую связку между Группой обновлений и Пакетом, который создается на основе этой группы. К сожалению в консоли SССM у меня так и не получилось хоть где-нибудь увидеть связь между двумя этими сущностями. Более того, в консоли SCCM 2012 Пакет развертывания обновлений можно создать только из мастера развертывания.
Пакет должен иметь уникальное не превышающее 50 символов имя, которое описывает содержимое пакета. И здесь же указывается ссылка на подкаталог который мы предварительно приготовили в ранее созданной сетевой паке.
Стоит отметить, что при создании Пакета развертывания для каждого Пакета необходимо выбирать отдельный подкаталог в качестве источника, именно поэтому мы предварительно создали структуру каталогов. То есть не получиться схитрить и для всех Пакетов обновлений использовать один и тот же каталог. У меня была такая мысль, когда я задумался о дублирующихся файлах обновлений, но мастер честно мне сказал нельзя использовать каталог который использовался уже в каком то другом Пакете.
К сведению:
После того, как Configuration Manager создаст пакет развертывания, в свойствах пакета развертывания можно изменить расположение источника пакета, однако сначала нужно скопировать содержимое из исходного источника пакета в новое расположение источника пакета.
http://technet.microsoft.com/ru-ru/library/gg712304
Если мы выбрали создание нового пакета развертывания то нам будет предложено определиться тем на какие DP должен попасть.
Затем выбираем источник загрузки файлов обновлений. Если в локальной сети есть действующий сервер WSUS то можно попробовать загрузить обновления из его сетевой паки контента. Разумеется что надо понимать, что на сервере WSUS все обновления которые входят в наш пакет развертывания должны быть загружены ранее.
Практика показывает, что при указании параметра загрузки из Интернета в процессе работы данного мастера, загрузка будет выполняться непосредственно через тот компьютер на котором в данный момент запущена консоль SCCM и от имени того пользователя который в данный момент работает с этим мастером. После скачивания файлы будут перемещаться в сетевую папку указанную ранее в качестве источника пакета. Подтверждение этому можно увидеть в файле
%windir%\CCM\Logs\PatchDownloader.log
Еще одно интересное наблюдение. В документации сказано, что если файлы обновлений уже присутствуют в сетевой папке, то повторно загружены они не будут, но не смотря на это в большинстве случаев файлы перекачиваются заново. И это хорошо видно из лога. Понять почему так происходит, мне не удалось.
После того, как я понял, что предстоит ещё большое количество экспериментов с пакетами развертывания и каждый раз придётся ждать загрузку обновлений большого размера из интернета, стало ясно что надо что-то придумать чтобы ускорить процесс загрузки. Выходом стал отдельно развернутый сервер WSUS на котором включено авто-одобрение и загрузка всех тех же классов и продуктов что и на CAS. Теперь этот сервер по ночам выкачивает обновления а на SCCM-е пакеты при сборке качаются уже не с интернета а с сетевой паки контента этого WSUS-сервера.
Вернёмся к мастеру развертывания. На следующем шаге мастера выбираем языки для которых нужно загрузить файлы обновлений. По умолчанию включены те языки которые были указаны нами при установке роли SUP
Далее переходим к возможности сохранения настроек в качестве шаблона для ускорения создания развертываний в последующем.
И дожидаемся успешного завершения работы мастера развёртывания…
По аналогии делаем развертывание всех “нарезанных” ранее групп обновлений на коллекции компьютеров.
В итоге, в нашем примере, для пакетов обновлений применимых и к серверным и к клиентским системам у нас получиться по два развёртывания
Если есть необходимость, дополнительно настраиваем области безопасности появившихся в результате развёртывания пакетов обновлений.
После того как все развёртывания выполнены и на клиентах SCCM прошёл по расписанию цикл проверки обновлений, на рабочих станциях будет выполнена автоматическая установка обновлений, о чем будет свидетельствовать Просмотр журнала обновлений…
… а на серверных системах клиент SCCM будет ожидать процедуры запуска установки обновлений администратором в Центре программного обеспечения (Software Center):
Тестирование новых обновлений
После того как мы разобрались с существующими актуальными обновлениями на момент развертывания инфраструктуры SUP, настало время рассмотреть логику тестирования и развертывания вновь поступающих обновлений. Сразу хочу отметить то, что описанная далее последовательность действий отталкивается опять-таки от условия, что мы имеем группировку обновлений по продуктам а не по временным периодам.
Выполним ряд подготовительных действий:
A) Создадим группу обновлений для тестирования новых обновлений. Это делается один раз и в последующих циклах будет использоваться эта же существующая группа. Для создания группы можно использовать хотя бы одно любое ещё не развернутое обновление (ориентируемся по колонке Развернуто);
B) Создадим коллекцию компьютеров для тестирования обновлений. Для удобства можно сделать так чтобы в эту коллекцию попадали компьютеры входящие в группу безопасности AD с помощью запроса:
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.SecurityGroupName = "HOLDING\\SCCM-SUP-Test-New-Updates" and SMS_R_System.Name like "KOM-%"
C) Развернём тестовую группу обновлений на коллекцию.
Итак, предположим, что решено выполнять загрузку и установку новых обновлений один раз в месяц, тогда ежемесячный цикл манипуляций с новыми обновлениями можно разделить на следующие этапы:
1. Загрузка новых обновлений. Для начала используем фильтр для обора всех новых обновлений, например как показано на скриншоте снизу.
Не забываем включить отображение колонки Продукт чтобы увидеть какие обновления относятся к каким продуктам. Сортируем обновления по колонке Продукт, выделяем все обновления, относящиеся к конкретному продукту и вызываем мастер загрузки обновлений, выбирая в нём соответствующий пакет развёртывания для этого конкретного продукта.
Здесь важно понимать, что загрузка обновлений в пакет не вызовет установки этих обновлений до тех пор пока эти обновления не будут назначены какой-либо группе обновлений, так как объектом развертывания обновлений является именно группа обновлений. Именно поэтому после того как все новые обновления загружены в свои пакеты необходимо назначить их в группы.
2. Назначение новых обновлений в тестовую группу (развертывание)
Выделяем все свежие уже загруженные обновления и меняем членство на ранее созданную тестовую группу обновлений…
В окне выбора групп отмечаем только тестовую группу…
А так как тестовая группа уже развернута на тестовую коллекцию ранее, спустя некоторое время обновления станут доступными для установки на компьютерах тестовой коллекции.
3. Перевод протестированных обновлений в продуктивную среду
После того как фактический цикл установки обновлений на тестовую коллекцию компьютеров прошёл успешно, наступает время назначить обновления из тестовой группы обновлений на все компьютеры. Для этого в консоли войдём в тестовую группу обновлений, выделим все обновления входящие в эту группу и изменим членство этих обновлений с тестовой группы на те продуктивные группы (в разрезе продуктов) к которым относятся эти обновления.
После этой процедуры в группе тестовых обновлений у нас не должно остаться ни одного обновления.
Спустя несколько минут мы сможем убедиться в том, что у новых обновлений для которых мы поменяли членство с тестовой группы на группу продуктивную, - автоматически появилась информация о действующих развёртываниях, связанных с этой продуктивной группой.
Вот собственно и всё. На первый взгляд это может показаться несколько громоздко, но со второго/третьего раза становиться понятно что ничего в этом сложного нет. Обратите внимание на то, что в рамках данной заметки мы не рассматривали новый функционал SCCM 2012 в плане возможностей автоматического развёртывания обновлений. Применительно автоматизации ежедневных обновлений антивирусных описаний SCEP мы рассмотрим этот функционал в рамках отдельной заметки чуть позже.
Обработка заменённых обновлений
Для того чтобы заменённые обновления не копились в SCCM существует механизм автоматической очистки. Он работает по той логике, что если какое-либо обновление заменено другим обновлением, и это самое заменённое обновление не входит ни в одну группу обновлений, – автоматически удаляется из SCCM через 7 дней. Об этом подробно описано в блоге команды разработчиков SCCM 2012 в статье Software Update Content Cleanup in System Center 2012 Configuration Manager
Поэтому, чтобы не копить заменённые обновления, можно время от времени выполнять процедуру исключения заменённых обновлений из всех групп обновлений (разумеется с учетом того что эти обновления больше ни требуются для установки ни на одном компьютере).
Как описано в вышеуказанной статье, в лог-файле wsyncmgr.log можно будет отследить активность SCCM по отмене таких обновлений…
Removed 106 unreferenced updates SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:15 AM
… а через 7 дней удалении таких обновлений…
Deleting old expired updates... SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:16 AM
Deleted 80 expired updates SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:20 AM
Deleted 80 expired updates total SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:20 AM
С точек распространения файлы заменённых и удалённых из метаданных обновлений будут удалены автоматически, остается лишь озадачиться вопросом удаления всех уже ненужных файлов обновлений из сетевого каталога исходных файлов, в который мы изначально выполняли загрузку. В обозначенной статье приводится VBS скрипт для обработки сетевой папки исходников, но если честно, я пока не вдавался в его изучение и применение на практике. Вообще конечно есть желание со временем реализовать этот функционал с помощью PowerShell.
Использование Prestaged пакетов
После того как функционал SUP был внедрён в основном офисе и роль SUP уже была развернута на серверах подчинённых вторичных сайтов в территориальных подразделениях, мы столкнулись с проблемой первичного распространения пакетов обновлений при наличии сильно загруженных каналов передачи данных. Проблема заключалась в том, что SCCM честно врал нам о том, что пакет на удалённую DP скопирован успешно, однако когда мы запускали процедуру проверки содержимого (проверка хэша файлов) наблюдали в разделе консоли Мониторинг\Обзор\Состояние распространения\Состояние конфигурации точек распространения ошибки, говорящие об отсутствии одного или нескольких файлов в том или ином пакете. Чаще всего этим страдали большие пакеты.
На выручку пришёл функционал Создания файлов с предварительно подготовленным содержимым (Prestaged) из пакетов
В итоге получившиеся на выходе файлы в формате .pkgx были скопированы на сервера DP удалённых площадок, а там пакеты были развернуты из этих файлов командой:
<Папка установки сервера SCCM>\bin\X64\extractcontent.exe /P:"E:TempOffice2010.pkgx" /F
После этого проверка хэша содержимого прошла успешно и при последующих инкрементальных обновлениях этих пакетов проблем вроде бы замечено не было.
Интеграция обновлений в процесс OSD
После того как мы получили работающую роль SUP стало возможным добавить процедуру установки всех необходимых обновлений в процесс автоматического развёртывания операционной системы Windows (OSD). Всё что для этого требуется – лишь включить в последовательность задач развертывания ОС соответствующую опцию:
Таким образом, наряду с установкой самой операционной системы, драйверов и всего прикладного программного обеспечения мы дополняем процесс установкой обновлений с SUP, получая тем самым на выходе готовую к применению систему.
Для возможности установки обновлений в процессе OSD, нужно понимать, что целевой компьютер должен предварительно попасть в коллекции на которые назначено развертывание обновлений SUP.
Дополнительные источники информации:
Отличная статья!
Чувствуется, что функционал выстрадан автором ;)
Алексей, отличная статья!!! "В обозначенной статье приводится VBS скрипт для обработки сетевой папки исходников, но если честно, я пока не вдавался в его изучение и применение на практике. Вообще конечно есть желание со временем реализовать этот функционал с помощью PowerShell. " - очень порадовало, так как сам не понимаю, почему автор статьи писал на vbs. Спасибо!
В SC 2012 R2 Configuration Manager можно не использовать скрипт очистки каталога исходных файлов SUP. SCCM сделает всю работу сам :)
https://blog.it-kb.ru/2014/02/10/system-center-2012-r2-configuration-manager-sccm-software-update-point-sup-source-updates-files-catalog-clean-up-orphaned-content-folders/
Огромное спасибо, статья очень годно и подробно описана, редко попадается столь проработанный материал
Всё прелестно, но столкнулся с такой проблемкой, создал пакет обновления, распространил на коллекцию устройств, но есть компьютеры которые не надо обновлять, а как их добавить в исключения, найти не смог. Есть ли такая возможность?
Список устройств задаётся коллекцией на которую вы повесили развёртывание. В свойствах коллекции создайте запрос членства коллекции таким образом чтобы исключались интересующие вас компьютеры. Это вопрос касается по сути не SUP, а банального создания нужных коллекций устройств в SCCM 2012.
Дело в том, что создавать отдельную коллекцию под обновления не хотелось бы, коллекция называется Windows 7 и к этой коллекции привязано много типов развертываний. Вопрос решил путем параметров клиентов, создал новый параметр, добавил пункт "Обновления программного обеспечения" и выключил его, добавил созданную коллекцию, которая исключена от обновлений. Можно данное сообщение посчитать за флуд, но вдруг кому то пригодиться.
Спасибо!
Еще один способ исключения обновлений
http://social.technet.microsoft.com/Forums/ru-RU/94eae776-9af5-43a9-a2f7-1a328072437b/sc-2012-cm-software-updates-?forum=smsru
Не подскажите, почему в логе ..\Update Services\LogFiles\Change.log появляется запись вида -
WSUS configuration has been changed by NT AUTHORITY\SYSTEM
и следовательно меняются настройки wsus - options - update source and proxy server - update source и обновления переставют синхронизироваться
sccm2012, sup, wsus
Могу только предположить что Вы пытались изменить настройки экземпляра WSUS на базе которого работает SUP руками через консоль WSUS. Этого делать не надо. Все конфигурационные изменения нужно выполнять непосредственно через консоль SCCM.
Понятно, тоесть в WSUS консоли ничего не настроено должно же быть ? у меня так . но меняется только update source и у меня встаёт обновление в sccm 2012. Как быть чтобы не менялись настройки ?
Отличная запись.
Буду у себя как раз разворачивать CAS + Child Primary вот и проверю)
Если ты не против, то я начинаю писать тоже заметки по SCCM и проблемам около него, то я там ссылки на свои посты поразмещаю, как полезные к прочтению?
Против ссылок я думаю никто никогда не был :)
Скажите пожалуйста, а компоненты WSUS на сервер можно установить через добавление ролей или надо обязательно скачивать и потом устанавливать?
Да думаю можно и через установку ролей поставить. Главное его не настраивать, так как при развёртывании роли SUP SCCM его настроит сам под себя так как ему надо.
Спасибо за ответ. Мне удалось настроить синхронизацию, а вот со скачиванием никак.. :(
В логах файла PathDownloader вот такие записи:
Failed to create directory \\sccm\services\updates\Endpoint\f118bb2a-7e61-42ce-91bf-6fd3a661036f.1\, error 5
ERROR: DownloadContentFiles() failed with hr=0x80070005
Что-то мне подсказывает что это связано с правами на общую папку для загрузки..но я поверил - тем кому надо даны полные права..
Не поможете советом?
Заранее спасибо.
Можно продолжить обсуждение Ваших проблем здесь http://forum.it-kb.ru/viewforum.php?f=28
Хорошо. Попробую зарегистрироваться.
День добрый! Хочу поднять роль на существующей системе роль SUP. Апдейт WSUS30-KB972455-x64.exe у меня установлен (это я говорю за CAS сервер) - только консоль. Если же я удалю и переустановлю компонент на фулл установку, на текущую систему это не повлияет?
Если я правильно Вас понял, то на CAS перед поднятием роли SUP удаление отдельно ранее установленной консоли и установка нового полного экземпляра WSUS даже рекомендуема. Об этом сказано и в тексте заметки.
.... " Если же на сервере была установлена только консоль WSUS, то её также нужно деинсталлировать для того чтобы установить полный экземпляр WSUS."... - виноват, не дочитал! Спасибо!
Обратная ссылка: System Center 2012 R2 Configuration Manager — Очистка каталога исходных файлов обновлений Software Update Point | Блог IT-KB /
Добрый день. Возникла проблема: обновления разворачиваются на клиенты в "обязательном" порядке, но пользователи не видят или намеренно сворачивают предложения об установки и так до дедлайна. После наступления дедлайна клиент устанавливает обновления и перезагружает компьютер (что для многих очень нежелательно) без предупреждения. Сообщения об имеющихся обновлениях и наступлении крайнего срока настолько ненавязчиво, что многие пользователи и за 2 недели не замечают их. Если способ сделать напоминания пользователю об имеющихся обновлениях и в особенности о наступлении крайнего срока более "настойчивыми" визуально?
Проблема с дублирующимися бинарниками была в 2007. В ConfigMgr 2012 совершенно по-другому организовано хранение контента, т.е. в папках с пакетами хранится только метаданные о пакете, и если в двух пакетах испольуются одни и те же бинарники, то пакеты будут иметь только ссылки на них. Соответственно дублирования обновлений не должно быть. Поправьте, если не прав.
Речь про дублирование шла не про сами пакеты, которые хранятся в библиотеке контента, а про их источники.
Добрый день. А не подскажете, как убрать привязку WSUS от SCCM?? Поставил с дуру роль на СМ обновления программного обеспечения, не понравилось, слишком сложно и муторно + слишком много места занимает. Он забрал на себя все роли.. Теперь не могу вернуть.. На WSUS клиенты не стучатся даже с прописанными настройками в AD. Переставлял роль WSUS на сервер, они находятся на одном сервере - не помогло.
Доброго времени суток!
SCCM 2012. SQL 2008 R2. Иерархия CAS-Primary-Secondary.
Вниз по иерархии - CAS развернут SUP. Primari развернут SUP. Secondary развернут SUP.
Клиент вторичного сайта (Secondary) статус Sms software update agent - false
В клиентских параметрах установлен флаг Software Updates - True.
Скачаны обновления на CAS, созданы группы, распространены на вторичные сайты.
Соответственно, на ПК не приезжают задачи по обновлению.
Предыдущие доменные политики WSUS, временно потушил, чтобы не конфликтовали.
В логе windowsupdate.log видно что он перечитал доступные обновления с точки управления.
Что мог упустить? Что не включил или отключил?
Заранее спасибо!
Ситуацию решили очень как-то просто. ПК был сразу же в нескольких коллекциях. Изменили приоритет политик, ту в которой был включен SUP и соответственно все приехало.
Вот так часто и бывает, что решение находится под самым носом :)
Алексей, добрый день. Подскажите, не могу никак понять, как же все таки это работает. Я правильно понимаю, что нужно будет каждый раз новые обновления добавлять в нужную группу, скачивать в ручную и прочее? Нет ни какого автоматизированного способа, чтобы обновления сами попадали в нужную группу?
Есть. Этот механизм называется Automatic Deployment Rules. Просто в рамках данной заметки он не рассматривался.
Да, я видел данныую фичу. То есть она и отвечает за автоматизацию.. Понятно. Просто проверить никак не смог на тестовом развертывании. Спасибо БОЛЬШОЕ!
У меня такая проблема: хотя в SUP стоит и русский и английский язык, обновления для Windows 10 приезжают только EN-GB и EN-US, как добавить русский?
На WSUS в настройках тоже почему-то стоит только Английский, хотя настройками WSUS управляет же SCCM и при синхронизации мои настройки должны приезжать, нет?
SCCM берёт метаданные с WSUS. Хотя любая правка WSUS обслуживающего SCCM крайне не желательно, всё таки можно попробовать включить русский язык на WSUS, затем выполнить синхронизацию в SCCM и проверить не появился ли русский язык в настройках SUP.
я не совсем понял один момент в развертывании тестовых обновлений.
1. обновления я загружаю в пакеты по продуктам.
2. при создании развертывания какой пакет указывать? или нужно создавать столько развертываний сколько у меня продуктов?
Для тестирования свежих обновлений создаём отдельную группу обновлений, например "Test Group". Для этой группы обновлений создаём развёртывание на тестовую группу компьютеров.
Когда на WU появляются свежие обновления, то мы делаем вещи:
1) Загружаем свежие обновления в соответствующие пакеты по продуктам, как Вы и написали.
2) На период тестирования добавляем обновления в группу "Test Group"
По окончании периода тестирования убираем членство в группе "Test Group" и включаем членство в группе, относящейся к конкретному продукту, которая развёрнута на все компьютеры (продуктивное развёртывание)
Алексей, про членство обновлений группам это понятно.
мне не понятен момент выбора пакета, при создании тестового развертывания.
т.е. у меня 2 группы ПО: office и windows 7. соответственно созданы пакеты развертываний office и windows 7.
создана группа Test. в ней новые обновления для обеих групп. и соответственно на группу Test я создаю развертывание? появится окно выбора пакета.
но обновления уже разложены по двум пакетам. какой пакет выбирать? или создавать 2 развертывания?
Шаг выбора пакета в мастере развёртывания группы обновлений будет присутствовать лишь в том случае, если в группе есть незагруженные обновления. Если же у Вас в тестовую группу в данный момент входят обновления, которые ранее уже были загружены по своим пакетам и в консоли для группы в колонке "Загружено" отображается статус "Да", то вопрос с выбором пакета просто не возникнет.
если обновление относится к двум продуктам, например, windows 7 и windows 2008 (групп 2 и пакетов тоже 2), то нужно загружать обновления в оба пакета?
Не нужно. Если Вы внимательно посмотрите на скриншоты, то на одном из них увидите, что в рассматриваемом примере есть группа обновлений с названием Windows All. Эта группа имеет соответствующий пакет. Все обновления Windows, которые относятся к нескольким продуктам загружаются в этот пакет. И эта группа обновлений развёрнута как на клиентские, так и на серверные системы.
а есть ограничения на количество обновлений в одной группе или пакете?
Есть. В статье про это написано.
я читаю инструкции только когда все сломаю )
понятно. т.е. вы обновления для всех windows не кидали в одну группу. только те, которые относятся к двум и более продуктам. А жаль, с одной группой было бы более удобно
А если сделать несколько пакетов (по 1000 обновлений в каждом) Windows-all1, windows-all2 и т.д.
В чем преимущество твоего способа? каждый пакет на свою группу?
Доброго времени суток!
У меня следующая ситуация:
SCCM 2012 R2 на сервере Windows 2008 R2
WSUS на сервере Windows 2012 R2
Вопрос: Можно ли их подружить? Ели да, то как? или необходимо мигрировать SCCM на Windows 2012?
Здравствуйте, Азат. "Дружить" здесь ничего не нужно. Роль SUP в SCCM требует своего локального выделенного экземпляра WSUS. Не пытайтесь притянуть за уши к SCCM уже действующие самостоятельные экземпляры WSUS. Из этого ничего хорошего не выйдет и про это в статье написано.
Т.е. необходимо установить WSUS на сервер с SCCM?
Но так как SCCM установлен на Windows 2008 R2 я могу установить только WSUS 3,0 sp2 + fixs. а он насколько я знаю не обновляет Win10. Т.е. значит нужно мигрировать SCCM на Windows 2012 R2 что бы установить WSUS 6 версии?
Здравствуйте, Алексей! В тексте Вы упомянули один момент, который меня очень заинтересовал ещё на момент развёртывания: "переместить её на отдельный файловый сервер (файловый кластер)". Почти с год назад развернул SUP, всё работало хорошо. В конце апреля переместил сетевую папку на файловый кластер, и клиенты перестали получать обновления. По логам выглядит, что они не могут брать файлы с тома, отличного от NTFS, а на файловом кластере файловая система CSVFS. Сами обновления скачиваются как прежде, ошибок нет. Верно ли я трактую ситуацию с клиентами? Или же файловый кластер нужен другой? Прошу комментариев, и заранее за них благодарен.
Доброго времени года, Василь. Пожалуй, это тот случай, когда можно ответить вопросом на вопрос. Сможете ли Вы найти на сайте MS информацию о том, что SUP совместим с CSVFS? Ответ, вероятней всего, будет отрицательный.
Алексей, спасибо за ответ, согласен с Вами полностью заранее, вероятнее всего такой информации нет. Тогда, прошу прояснить другой вопрос, заданный мной - Или же файловый кластер нужен другой? Т.е. какой же файловый кластер Вы упомянули в посте?