Пример использования возможностей инвентаризации и отчетов в 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. Запрос к этому классу возвращает параметры, в числе которых системное название дискового устройства и состояние его здоровья (часть вывода опущена):
PS C:\Windows\system32> Get-WmiObject -namespace root\wmi -class MSStorageDriver_FailurePredictStatus
Active : True
InstanceName : SCSI\Disk&Ven_ATA&Prod_WDC_WD5003AZEX-0\4&15828421&0&030000_0
PredictFailure : False
Reason : 0
Active : True
InstanceName : SCSI\Disk&Ven_ATA&Prod_OCZ-VERTEX3\4&15828421&0&050000_0
PredictFailure : False
Reason : 0
...
В данном выводе нас интересует параметр 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-файла.
