Что такое System Center? Часть 1
В преддверие выхода новых версий продуктов семейства System Center, версий 2012, думаю, будет не лишним напомнить, что в принципе представляет собой System Center. Во-первых, такой краткий обзор может послужить отправной точкой для последующего более детального рассмотрения конкретных продуктов, их возможностей и сценариев использования. Во-вторых, мне никогда не нравилось то, как эта информация изложена на microsoft.com. То есть, возможно, с точки зрения ИТ-руководителя или маркетолога информация там представлена как раз так, как надо, но мне почему-то всегда не хватало четкости и конкретики.
Итак, System Center (SC) – семейство специализированных продуктов для управления ИТ-инфраструктурой. Максимальный эффект от SC вы получите, если инфраструктура построена на платформе Microsoft. Однако применение тех или иных инструментов SC в гетерогенных средах также может оказаться на удивление полезным. Далее перечислим, какие конкретно продукты входят в SC с указанием последних версий и задач, которые каждый из них решает. На текущий момент в SC входят:
System Center Operations Manager 2007 R2 – для проактивного мониторинга ключевых объектов ИТ-инфраструктуры;
System Center Configuration Manager 2007 R3 – для конфигурирования серверов и рабочих станций;
System Center Virtual Machine Manager 2008 R2 – для централизованного управления виртуальными машинами и серверами виртуализации;
System Center Data Protection Manager 2010 – для резервного копирования и восстановления критически важных данных;
System Center Service Manager 2010 – для автоматизации управления инцидентами;
Opalis – для интеграции продуктов SC и автоматизации на основе этой интеграции ИТ-процессов организации;
System Center Essentials 2010 – для мониторинга, защиты и управления ИТ-инфраструктурой в организациях среднего масштаба.
Теперь давайте охарактеризуем каждый из продуктов семейства. В этом посте я начну с первых трех – наиболее известных и популярных.
System Center Operations Manager 2007 R2 (OpsMgr)
Единая консоль мониторинга. В процессе настройки администратор указывает OpsMgr-у, какие объекты необходимо подвергать мониторингу, устанавливает на выбранные объекты агентов OpsMgr (возможен мониторинг и без агентов), после чего информация о состоянии объектов периодически пересылается на сервер OpsMgr, аккумулируется и отображается в так называемой консоли оператора. Таким образом, оператор получает фактически в одном окне оперативную информацию о состоянии инфраструктуры.
Пакеты управления. Каким образом OpsMgr «узнает» о том, как следить за тем или иным сервером, какие параметры необходимо анализировать, какие значения этих параметров говорят о потенциальной проблеме? Чтобы OpsMgr мог выполнять мониторинг, необходимо загрузить в OpsMgr соответствующий пакет управления (Management Pack, MP). Например, загружаете в OpsMgr MP для Windows Server, и OpsMgr «знает», какие события необходимо проверять в журнале System, за какими счетчиками производительности нужно наблюдать и пр., чтобы «понимать», что с сервером все в порядке. Или загружаете MP для Exchange, и OpsMgr «понимает», в каких диапазонах должны находиться параметры Exchange Server, чтобы сделать вывод о том, что сервис «почта» функционирует нормально, либо же наоборот необходимо срочно предпринимать какие-то шаги. И точно также OpsMgr способен предоставлять, например, информацию о состоянии конкретной базы данных SQL Server-а, установленного внутри виртуальной машины. Таким образом, продукт обеспечивает мониторинг как физической, так и виртуальной инфраструктуры.
Проактивный мониторинг. Каждый MP содержит описание так называемой модели здоровья продукта или сервиса, для которого MP разработан. Если в процессе мониторинга выявляется отклонение от состояния «здоров», в консоли оператора появляется оповещение (alert). При этом в MP включается информация (база знаний) о том, что необходимо сделать, если возникает тот или иной alert. В некоторых случаях OpsMgr способен в автоматическом режиме среагировать на alert и выполнить необходимые действия, скажем, запустить скрипт, который очистит журнал транзакций SQL Server при заполнении журнала до определенного уровня. Но главное следствие подобной архитектуры – проактивность. OpsMgr предупредит вас о назревающей проблеме еще до того, как эта проблема собственно возникнет и скажется на работе инфраструктуры и пользователей.
И еще один важный момент. MP для продукта или сервиса разрабатывают те, кто разрабатывают сам продукт или сервис. MP для Exchange создает команда Exchange. А кто кроме них лучше знает, за какими параметрами и как необходимо следить? Для каждого серверного продукта Microsoft существует MP, который можно бесплатно скачать с сайта microsoft.com. Но точно также есть MP для мониторинга Linux-серверов или, скажем, маршрутизаторов CISCO. Правда, MP третьих фирм, как правило, не бесплатны.
System Center Configuration Manager 2007 R3 (SCCM)
SCCM позволяет администратору решать несколько задач, связанных с конфигурацией серверов и рабочих станций компании. И что самое главное, решать удаленно. SCCM – достаточно жесткий и привлекательный для администратора инструмент в том смысле, что реализует большинство действий вне зависимости от желания пользователя компьютера. Последнее, естественно, предполагает наличие инфраструктуры Active Directory и административных прав на соответствующие рабочие станции и серверы.
На компьютеры, которыми вы хотите управлять, необходимо установить клиент SCCM. Следует сразу отметить, что поддерживаются только операционные системы MS, начиная с Windows 2000. Причем SCCM предлагает несколько вариантов автоматического обнаружения компьютеров в сети, а после обнаружения возможна принудительная и незаметная для пользователя установка SCCM-клиента. После установки клиентов в консоли SCCM вы видите компьютеры организации и над различными их подмножествами можете выполнять целый спектр задач.
Инвентаризация аппаратного и программного обеспечения. SCCM не скажет вам, какие планки памяти и в какие слоты на материнской плате установлены. Но понять, например, какие компьютеры с точки зрения «железа» готовы к установке новой версии супер-бизнес-приложения вашей компании, очень даже поможет. Равно как и то, на каких машинах эта новая версия уже установлена.
Установка программного обеспечения и обновлений. С помощью SCCM вы можете автоматически и удаленно устанавливать на нужную группу компьютеров необходимое ПО. Причем в отличие от групповых политик SCCM не ограничивает вас дистрибутивами, в которых есть установочный файл в формате msi. Особым случаем этой возможности является установка обновлений (патчей и фиксов).
Desired Configuration. Механизм Desired Configuration (желаемой конфигурации) проверяет программное обеспечение, установленное на клиентских машинах на соответствие внутренним политикам, которых с ростом организации традиционно становится все больше и больше. Например, правильная ли версия операционной системы установлена, все ли необходимые приложения установлены и настроены соответствующим образом, нет ли запрещенных приложений.
Установка операционной системы. Эта возможность обеспечивает администратора инструментом для создания образов операционных систем, которые впоследствии могут быть автоматически установлены на управляемые компьютеры, на которых уже установлен агент SCCM, или же на неуправляемые (или вообще пустые) компьютеры с помощью PXE, загрузочных DVD/CD дисков и пр.
Диагностика и устранение неполадок. Существуют определенные инструменты и для удаленного управления, включая перехват клавиатуры, которые позволяют ИТ-специалисту взять управление машиной на себя и устранить возникшие проблемы.
Таким образом, если OpsMgr является «всевидящим оком», то SCCM – глазами и руками невидимого админа.
System Center Virtual Machine Manager 2008 R2 (VMM)
Главная задача VMM – обеспечить удобное централизованное управление множеством виртуальных машин (ВМ). Когда у вас пара физических серверов, на которых крутится десяток другой виртуальных машин, вполне можно обойтись штатной консолью Hyper-V. Если же мы имеем дело с ЦОД, с десятками серверов и сотнями или даже тысячами виртуальных машин, управлять такой виртуальной средой без специализированных инструментов практически невозможно. Давайте рассмотрим чуть более подробно, что стоит за понятием «централизованное управление ВМ».
Управление несколькими физическими серверами. VMM позволяет из одной консоли управлять несколькими физическими серверами, причем поддерживающими разные технологии виртуализации: Virtual Server, Hyper-V, ESX. При этом вы можете выполнять все основные операции со всеми ВМ на этих серверах: создание, удаление, настройка, запуск, пауза, выключение. Более того, при создании очередной ВМ VMM предложит наиболее оптимальный по целому набору критериев физический сервер для данной ВМ. VMM различает кластерные структуры – создание ВМ на кластере приводит к корректному ее размещению на одном из кластерных узлов со всеми необходимыми параметрами.
Библиотека. VMM позволяет организовывать библиотеки, в которых можно хранить VHD-файлы и шаблоны ВМ с заданными свойствами, благодаря чему, создание ВМ с нужной ОС, сетевыми настройками и другими параметрами осуществляется буквально парой щелчков мыши.
Миграция ВМ. VMM поддерживает P2V (physical-to-virtual) и V2V (virtual-to-virtual) миграции. В первом случае VMM анализирует указанный для миграции сервер и создает ВМ с параметрами, соответствующими этому серверу. Во втором, VMM конвертирует файлы ВМ из формата Virtual Server или ESX в формат Hyper-V.
Начиная с версии 2008 R2, VMM поддерживает технологию Live Migration (LM). Мигрировать ВМ с одного узла кластера на другой администратор может прямо из консоли VMM. Более того, можно настроить интеграцию с уже упомянутым OpsMgr. В этом случае VMM может сам принимать решение о миграции ВМ, например, если текущая загрузка CPU на одном из узлов кластера велика, в то время как другие узлы относительно свободны.
Self-Service Portal. Этот портал позволяет пользователем без каких-либо административных прав создавать, запускать и использовать ВМ. Пользователю достаточно выбрать на веб-страничке требуемые характеристики (естественно, из разрешенных администратором), после чего VMM (на основе шаблона в библиотеке) автоматически создает и запускает ВМ с указанными параметрами. Иными словам, ВМ предоставляются потребителю в виде сервиса. Усовершенствованную версию, Self-Service Portal 2.0, можно скачать в виде дополнительного бесплатного пакета.
Администрирование. VMM предоставляет администратору инструменты для создания отчетов, удаленного подключения к любой ВМ, оценки текущего состояния ВМ. И еще одно очень важное свойство VMM – все операции, которые администратор выполняет в консоли, сначала преобразуются в скрипт PowerShell, а затем уже скрипт собственно запускается. Любой такой скрипт администратор может сохранить, модифицировать и использовать в дальнейшем для автоматизации определенных задач.
В следующем посте пройдемся по DPM, Opalis, SCSM и Essentials.
Что такое Configuration Manager?
Относится к: Configuration Manager (Current Branch)
Начиная с версии 1910 Configuration Manager является частью Microsoft Endpoint Manager.
Microsoft Endpoint Manager — это интегрированное решение для управления всеми устройствами. Корпорация Майкрософт объединяет configuration Manager и Intune без сложной миграции и упрощенного лицензирования. Продолжайте использовать существующие инвестиции Configuration Manager, а также использовать возможности облака Майкрософт в вашем собственном темпе.
Следующие решения для управления Майкрософт теперь являются частью Microsoft Endpoint Manager:
Введение
Используйте диспетчер конфигурации, чтобы помочь вам в следующих действиях по управлению системами:
Диспетчер конфигурации помогает вам предоставлять более эффективные ИТ-службы, включив:
Диспетчер конфигурации расширяет и работает вместе со многими технологиями и решениями Майкрософт. Например, диспетчер конфигурации интегрируется с:
Диспетчер конфигурации также использует:
Чтобы успешно работать с Configuration Manager в производственной среде, тщательно спланируйте и протестируйте функции управления. Configuration Manager — это мощное приложение для управления, которое может повлиять на каждый компьютер в организации. При развертывании и управлении диспетчером конфигурации при тщательном планировании и учете бизнес-требований диспетчер конфигурации может снизить административные затраты и общую стоимость владения.
Пользовательские интерфейсы
Консоль Configuration Manager
После установки диспетчера конфигурации используйте консоль Configuration Manager для настройки сайтов и клиентов, а также для выполнения и мониторинга задач управления. Эта консоль является основной точкой администрирования и позволяет управлять несколькими сайтами.
Консоль Configuration Manager можно установить на дополнительные компьютеры, а также ограничить доступ и ограничить доступ к консоли административным пользователям с помощью администрирования на основе ролей Configuration Manager.
Центр программного обеспечения
Центр программного обеспечения — это приложение, установленное при установке клиента Configuration Manager на Windows устройстве. Пользователи используют Центр программного обеспечения для запроса и установки развернутого программного обеспечения. Центр программного обеспечения позволяет пользователям делать следующие действия:
Вы также можете показывать настраиваемые вкладки в Центре программного обеспечения для удовлетворения дополнительных бизнес-требований.
Дальнейшие действия
Перед установкой диспетчера конфигурации ознакомьтесь с основными понятиями и терминами:
Если вы знакомы с System Center 2012 года, см. в System Center 2012 года.
Технический обзор диспетчера конфигурации на высоком уровне см. в обзоре Основы диспетчера конфигурации.
Если вы знакомы с основными понятиями, используйте эту библиотеку документации, чтобы помочь вам успешно развернуть и использовать Диспетчер конфигурации. Начните со следующих статей:
Пример использования возможностей инвентаризации и отчетов в System Center Configuration Manager
Автор статьи — Михаил Глазырин, системный и сетевой инженер, Хабаровский аэропорт
Всем привет. Сегодня я хотел бы рассказать о наиболее редко используемых возможностях в System Center Configuration Manager – инвентаризации и отчётности.
Даже не знаю, почему так сложилось, но по опыту, администраторы, установившие в своей инфраструктуре SCCM, крайне редко пользуются двумя этими функциями. Безусловно, киллер фичами SCCM являются автоматизация развёртывания систем и установки ПО. На третьем месте по популярности – управление корпоративным антивирусом System Center Endpoint Protection. Про инвентаризацию и мониторинг в SCCM многие знают на уровне «видел в консоли управления, но никогда не кликал». Доходит даже до того, что особо нерадивые (и ниже я поясню почему) администраторы вообще отключают функциональность инвентаризации в политике клиента SCCM по умолчанию для, якобы, ускорения загрузки и снижения нагрузки на клиентские системы. Сразу скажу, что нагрузка от инвентаризации средствами Configuration Manager на порядок ниже использования некоторых других распространённых продуктов (того же Everest, например), т.к. инвентаризация происходит исключительно по расписанию, а не каждую загрузку либо каждый вход пользователя, тем самым не замедляя загрузку клиентских машин.
В данной статье мы настроим SCCM для проактивного мониторинга состояния жёстких дисков в клиентских машинах, но сначала – несколько слов об инвентаризации.
Конкретнее – об аппаратной инвентаризации. В SCCM есть инвентаризация ПО, основанная на сборе информации о файлах и их наличии, в данной статье она рассматриваться не будет. Инвентаризация же аппаратного обеспечения вся построена на WMI, поэтому можно собирать любые параметры, которые доступны для запроса через этот интерфейс. В стандартной поставке SCCM есть много предопределённых классов, покрывающих большинство потребностей по сбору информации о клиентских машинах. Разумеется, все их собирать необязательно. Чтобы настроить инвентаризируемую информацию, в консоли SCCM откройте Administration –> Client Settings, свойства Default Client Policy –> Hardware Inventory –> Set Classes. Здесь вы сможете выбрать то, что хотите собирать, используя SCCM, вплоть до параметров классов WMI. Можно назначать разные политики инвентаризации разным коллекциям устройств, например, включить сбор информации о батареях и питании только для коллекции мобильных устройств. Подобная гранулярность позволяет экономить место, занимаемое базой данных сайта SCCM, снижает нагрузку на клиентские машины и, что лично для меня немаловажно, соответствует best practice «необходимой достаточности».
История из жизни
Однажды отдел техподдержки нашей компании озадачился возможность централизованного сбора данных SMART с клиентских машин. К сожалению, поиски так и не выявили приемлемого с точки зрения удобства и централизации решения, и мы обратились ко встроенным в Windows средствам. Системы Windows всех актуальных на сегодняшний день версий имеют функциональность сбора данных SMART с установленных в системе накопителей. К сожалению, информации о том, как и какие параметры система анализирует, мне найти не удалось, однако для нас сейчас важно то, что итогом этой деятельности является WMI-параметр, который можно считать при помощи SCCM. Кстати, это тот самый параметр, который ответственен за вывод вот такого знакомого многим окна:
Однако среднестатистический пользователь просто закроет такое окно, не придав ему никакого значения. Мы же будем собирать данный статус со всех наших компьютеров, чтобы в итоге знать, где нужно заменить диск.
Он находится в пространстве имён root\wmi, класс называется MSStorageDriver_FailurePredictStatus. Запрос к этому классу возвращает параметры, в числе которых системное название дискового устройства и состояние его здоровья (часть вывода опущена):
В данном выводе нас интересует параметр PredictFailure. Собирать его мы будем, просто добавив новый класс в окне Hardware Inventory Classes. Никаких сложностей процедура добавления не имеет. В итоге получим следующую картину:
После прохождения очередного цикла инвентаризации по расписанию, в ресурсах компьютера появится наш параметр:
Конечно, на этом вполне можно было бы остановиться, но зачем, если можно пойти до конца и заставить SCCM самостоятельно присылать нам информацию о компьютерах с проблемными дисками?
Для этого воспользуемся функциональностью формирования отчётов.
Отчётность в SCCM работает целиком и полностью на базе SQL Server Reporting Services (при этом консоль управления SCCM в разделе Monitoring –> Reporting представляет собой фактически фронтенд для упрощения работы с ними). «Из коробки» сразу после установки продукта мы получаем достаточно большое количество разнообразных, а главное, полезных отчётов. Их можно использовать как в разовом режиме, так и сформировать подписку. В последнем случае их можно получать на почту (полезно для получения регулярной информации о состоянии инфраструктуры по тем или иным параметрам), либо выкладывать на сетевой диск (например, если вам необходимо иметь под рукой актуальный реестр каких-либо сведений).
Для редактирования отчётов вам понадобится SQL Server Report Builder. Перед модификацией стандартного отчёта хорошей идеей будет сначала сохранить его под новым именем, чтобы было к чему вернуться при необходимости. Для выгрузки статистики по потенциально проблемным жёстким дискам нам придётся создать новый отчёт с нуля. Да, я готов признать, что создание отчёта с нуля является не самой тривиальной процедурой: вам будут необходимы знания в области написания SQL запросов и структуры БД SCCM. И если информации по первому в избытке, то по второму её не так много.
Можно пойти читерским путём и несколько упростить себе жизнь, сначала создав запрос через интерфейс, доступный в разделе Monitoring –> Queries.
Потом можно в свойствах запроса просто посмотреть его исходный код:
Вот в этом месте и находится основная проблема, отпугивающая людей от создания отчётов в SCCM. Ведь запросы пишутся на SQL-подобном языке WQL, а отчёты работают напрямую с БД, и ни о каком WQL они не знают. Если попытаться вставить такой запрос напрямую в Report Builder, он вполне обоснованно будет говорить о том, что не знает, что такое SMS_R_System и SMS_G_System. Всё станет значительно проще, если знать, что эти объекты являются видами в БД SCCM. Причём объектам, начинающимся с SMS_R_System, соответствуют виды, имя которых начинается с v_R, а объектам SMS_G_System – v_GS. Таким образом, достаточно просто преобразовать запрос WQL в SQL. В нашем примере SMS_G_System_MSSTORAGEDRIVER_FAILUREPREDICTSTATUS станет v_GS_ MSSTORAGEDRIVER_FAILUREPREDICTSTATUS. В общем, если у вас возникают сомнения – не бойтесь открыть БД SCCM в SQL Management Studio, всё станет гораздо нагляднее. Все объекты, параметры и свойства там как на ладони:
После того, как вы написали запрос, сделать отчёт с помощью мастера Report Builder элементарно.
После этого запрашивать наш новый отчёт можно будет прямо из консоли SCCM:
Конечно же, на новый отчёт можно оформить подписку точно так же, как и на любой другой. При этом надо помнить, что практически не имеет смысла автоматически генерировать отчёт чаще, чем мы собираем новые данные с клиентских машин. Наш отдел техподдержки получает этот отчёт по почте каждую неделю с утра в понедельник в виде вложенного PDF-файла.
Устранение проблем с развертыванием приложений через SCCM из-за разрушения базы WMI
Часто приходится выяснять причины, почему не разворачивается то или иное приложение через SCCM, хотя ПК находится в соответствующей коллекции и прошло достаточное количество времени.
Принудительное же развертывание (Application Deployment Evaluation Cycle) и обновление групповых политик на ПК (Machine Policy Retrieval and Evaluation Cycle) через консоль SCCM ни к чему не приводят:
Разберем на примере установки новой версии клиента 1С. Видим, что развертывание должно было произойти, но при этом на ПК данной версии 1С (8.3.18.1289) еще нет:
Скорее всего, проблема связана с разрушением базы WMI на ПК и необходимостью переустановить полностью клиент SCCM. Проверить это можно из вкладки Мониторинг / Состояние клиентов консоли SCCM:
Если данный ПК присутствует в списке, то необходимо перейти на вкладку Активы и соответствие / Устройства консоли и найти через поиск данный ПК. Ошибка также будет видна на вкладке Данные о проверке клиента данного ПК.
Для устранения ошибки необходимо восстановить базу WMI на ПК, для чего мы запускаем проводник данного ПК:
и переходим в папку C:\Windows\System32\wbem\Repository:
Также правой кнопкой из консоли SCCM открываем Управление компьютером (Manage Computer) данного ПК и переходим к вкладке Службы:
После этого останавливаем службу Инструментарий управления Windows (Winmgmt) и все зависящие от неё службы, как правило это Вспомогательная служба IP (iphlpsvc) и служба агента SCCM – SMS Agent Host (ccmexec), но могут присутствовать и другие службы, например Центр обеспечения безопасности (wscsvc) и / или службы производителя, например Intel(R) Rapid Storage Technology (IAStorDataMgrSvc) либо другие – надо остановить все зависимые и Winmgmt:
После остановки необходимо быстро удалить все содержимое из папки C:\Windows\System32\wbem\Repository (переключившись в проводник удаленного ПК) и затем включить снова службу Инструментарий управления Windows (Winmgmt) для создания чистой базы репозитория WMI (создается автоматически при запуске службы). Также можно включить все остановленные зависимые службы, кроме агента SCCM (SMS Agent Host).
После этого запускаем из консоли SCCM командную строку на удаленном ПК:
и проверяем, что службы, связанные с SCCM (ccmsetup, ccmexec, cmrcservice) остановлены, либо отсутствуют:
Если они все в состоянии STOPPED – удаляем их:
Если какая-то из служб находится в состоянии RUNNING (работает), то перед удалением останавливаем её с помощью команды: sc stop cmrcservice (например).
Теперь можно удалить (очистить) папки, связанные с SCCM из C:\Windows (ccmsetup, ccmcache, CCM). При этом в папке C:\Windows\CCM не удалится одна системная папка – ScriptStore – это нормально.
После этого мы можем установить клиента SCCM заново из консоли:
Отследить установку можно по файлу логов (появится при запуске установки): C:\Windows\ccmsetup\ccmsetup.log:
Можно открыть его с помощью утилиты CmTrace.exe и наблюдать в реальном режиме времени процесс установки клиента:
Если установщик вернет код 7, то ПК необходимо будет перезагрузить для продолжения установки.
По окончании установки, начнется распространение и установка приложений, назначенных и ещё не установленных на ПК, которое можно отследить по появляющимся папкам в кэше по пути C:\Windows\ccmcache в проводнике удаленного ПК. Нас интересует папка с установщиком 1С. Находим её и запоминаем имя. В этой папке будет файл log.log, показывающий процесс установки, который мы также можем просмотреть через CmTrace.exe:
Видим, что процесс установки завершился ошибкой (не нулевой код):
Это значит, что скорее всего запущен еще какой-то процесс msiexec (другая установка, обновление, например). Можно перегрузить ПК либо удалить данный процесс из командной строки с помощью команды taskkill /PID XXXXX /F, где XXXXX номер процесса:
Далее, запускаем установку 1С вручную из папки кэша (в данном случае – C:\Windows\ccmcache\3):
И проверяем, что нужная нам версия установилась по появлению соответствующей папки в C:\Program Files\1cv8 :
На этом процесс восстановления работоспособности клиента SCCM можно считать завершенным.
Как правило, WMI разрушается на ПК с Windows 10, на Windows 7 такой ошибки не наблюдается. Причины могут быть самыми разными. Возможность автоматизировать данный процесс, например с помощью скриптов PowerShell есть, но с оговорками:
— удаление служб с ожиданием их остановки (Remove-Service) доступно только начиная с версии 6.0 (по умолчанию, на Windows 10 установлена версия 5.1) – остальное делается штатными командами PS.
— чтобы развернуть новую версию PowerShell и запустить скрипт нужно, чтобы служба WMI и клиент SCCM работали, т.е. восстановить на уже сбойных ПК не удастся, либо устанавливать PS 6.0, например, через групповые политики.
Все действия производились на версии SCCM 2010:
Дополнительно, установлено расширение консоли ConfigMgr Console Extensions от Dan Ireland для удобного доступа к дополнительным функциям по правой кнопке мыши (подходит версия 1.7.3a для SCCM 2012).