При слове «инвентаризация» обычный человек вспоминает ситуацию, когда придя в магазин, видишь табличку на закрытой двери и думаешь, что тебе придётся пройти ещё несколько домов, а в худшем случае и кварталов, чтобы купить необходимое. Необычный человек, работающий с Microsoft System Center Configuration Manager, при упоминании этого слова, представляет кипу проблем, связанных с достоверностью получаемых результатов. Про их решение мы и поговорим под катом.



Передаю слово автору.

Здравствуйте коллеги. Каждый администратор, работающий с Microsoft System Center Configuration Manager (далее ConfigMgr), повседневно использует функционал инвентаризации (Inventory). Это базовый функционал, который собирает данные об управляемой среде и в дальнейшем это используется для построения коллекций, запросов, отчетов. При кажущейся легкости настройки и использования функционала инвентаризации, администраторы ConfigMgr сталкиваются с постоянными проблемами с достоверностью получаемых результатов. Задача статьи — дать полное понимание, как работает инвентаризация, как выявлять и как решать проблемы. По сути постараюсь максимально подробно рассмотреть «что есть под капотом».

Disclaimer

Прежде чем уйдём вглубь, необходимо обговорить маленький disclaimer. ConfigMgr работает как с Windows операционными системами, так и с Linux/Unix (используя nanoWbem), c мобильными системами. ConfigMgr изначально развивался как продукт по управлению Windows ОС, поэтому для полноценного технического охвата в статье будем рассматривать только клиентов, под управлением ОС Windows. Если есть интерес к пониманию, как работает инвентаризация для Linux/Unix — пишите в комментариях, подумаю над написанием статьи. Теперь перейдём к самому интересному.

Перейдём к инвентаризации

ConfigMgr имеет два разных типа инвентаризации — hardware inventory (в русскоязычной документации — инвентаризация оборудования) и software inventory (соответственно инвентаризация программного обеспечения). В статье я буду использовать англоязычные названия. Ключевой момент здесь то, что по сути «название не соответствует содержимому». И это причина одной из главных ошибок администраторов. По сути, hardware inventory — это WMI инвентаризация, а software inventory — файловая инвентаризация (сбор свойств файлов по заданной маске). Именно поэтому список установленного ПО ConfigMgr собирает через hardware inventory — эта информация находится в WMI классах (частично в дефолтовых, частично в ConfigMgr client WMI классах).

На практике более используемая и более критичная для успешного выполнения повседневных задач — hardware inventory. Поэтому в данной статье пристально рассматриваем именно её.
Для использования данного функционала необходимо, чтобы в настройках клиентов (client settings --> Hardware inventory) на стороне Primary site было значение «enable», настроено расписание, выбраны WMI классы, информацию из которых необходимо собрать (часть классов включены по умолчанию). Полное описание WMI классов есть на MSDN.

ConfigMgr использует файл Configuration.mof, расположенный в \inboxes\clifiles.src\hinv, в котором указывает используемые WMI provider, WMI классы. Когда клиент по расписанию обращается на сервер (к точке управления — management point), он скачивает политику, к которой прикреплен данный файл и компилит его локально. После этого, исходя из расписания, ConfigMgr client запускает процесс hardware inventory (далее по тексту hinv).

Здесь необходимо сделать маленькое отступление. ConfigMgr client состоит из движка (engine) и агентов, каждый из которых отвечает за определенный функционал. При этом, СonfigMgr клиент использует trigger codes (cписок можно посмотреть здесь) для запуска каких-либо действий со своими агентами. Для запуска hinv агента используется trigger code {00000000-0000-0000-0000-000000000001}.

На клиенте будет происходит следующая последовательность действий:


1. Запуск hinv по расписанию. В inventoryagent.log будет следующая запись:

Inventory: Opening store for action {00000000-0000-0000-0000-000000000001}…
Inventory: Action=Hardware, ReportType=Delta, MajorVersion=1, MinorVersion=5

ReportType — тип отсылаемого на Primary site отчета (Delta или FULL). FULL — в отчёте будет вся информация, которая собрана (по умолчанию отправляется при первой инвентаризации). Delta — отчёт, который содержит лишь изменения со времени предыдущей hinv. Использование Delta report позволяет уменьшить размер пересылаемой по сети информации.

2. Сбор данных из WMI:

……

https://habrahabr.ru/post/329792/