При слове «инвентаризация» обычный человек вспоминает ситуацию, когда придя в магазин, видишь табличку на закрытой двери и думаешь, что тебе придётся пройти ещё несколько домов, а в худшем случае и кварталов, чтобы купить необходимое. Необычный человек, работающий с 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:

……
<![LOG[Collection: Namespace = \\.\root\cimv2; Query = SELECT __CLASS, __PATH, __RELPATH, UUID FROM Win32_ComputerSystemProduct; Timeout = 600 secs.]LOG]!>
<![LOG[Collection: Namespace = \\.\root\ccm\invagt; Query = SELECT __CLASS, __PATH, __RELPATH, Domain FROM CCM_ComputerSystem; Timeout = 600 secs.]LOG]!>
…............................

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

Collection: 55/63 inventory data items successfully inventoried.
Inventory: Collection Task completed in 67.422 seconds
Inventory: 8 Collection Task(s) failed.

3. Формируется xml файл для отправки на management point. Файл формируется в папке %WinDir%\CCM\Inventory\Temp:

Inventory: Temp report = C:\SMS_CCM\Inventory\Temp\1870d2e7-631c-49e3-87f2-60b90bc1d410.xml InventoryAgent
Inventory: Starting reporting task. InventoryAgent
Reporting: 88 report entries created. InventoryAgent
Inventory: Reporting Task completed in 0.937 seconds InventoryAgent )

4. Xml файл отправляется на management point и удаляется (по умолчанию).

Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {CF597D3C-8D61-47FC-8292-9711F5AC8430}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted

Если нужно сохранить xml (во время выявления и решения каких-либо проблем ), то необходимо создать специальный «секретный» файл ARCHIVE_REPORTS.SMS.

Дата выполнения hinv сохраняется на клиенте в WMI: root\ccm\invagt\C00000000-0000-0000-0000-000000000001. Соответственно, если необходимо запустить Full inventory принудительно, то необходимо просто удалить запись с датой предыдущей hinv — ConfigMgr автоматически запустить FULL hinv.

Дальнейшие действия будут происходить на management point:


5-7. Management point получает hinv отчёт и обрабатывает его. После чего пересылает на Primary site.

<![LOG[Hinv Retry: ******************* Start of Task *********************]LOG]!>
<![LOG[Hinv: Loaded class definition map; DB policy timestamp = 2016-12-28 08:07:10.000]LOG]!>
<![LOG[Hinv: Normalized DB policy timestamp: 20161228080710.000000+000.]LOG]!>
<![LOG[Hinv Sax: loading C:\CM2012CB\inboxes\auth\dataldr.box\HinvAttachmentYNWMKIXC.xml]LOG]!>
<![LOG[Delta report from client ****, action description = Hardware]LOG]!>
<![LOG[Hinv Task: Translate report attachment to file «C:\CM2012CB\inboxes\auth\dataldr.box\HCJ91LAV.MIF» returned 0]LOG]!>

7*. Если Management Point установлен вне Primary site, то будет использоваться компонент MP File Dispatch Manager (MPFDM.log)

Действия на стороне Primary site:


8. Компонент Data Loader (Отвечает за обработку hinv) обнаруживает новые файлы *.mif в своей корневой папке inboxes\auth\dataldr.box и перемещает для дальнейшей обработки в папку inboxes\auth\dataldr.box\process\.

9-10. При обработке mif файла данные записываются в базу данных ConfigMgr.

9*. Если при обработке mif файл был отклонён, то файл перемещается в папку inboxes\auth\dataldr.box\bad и хранится 14 дней. По истечению 14 дней ConfigMgr удаляет его автоматически. Соответственно информация в базу данных не попадает и это служит причиной уменьшения достоверности, что влияет на весь функционал ConfigMgr.

При перемещении mif файлов в bad, ConfigMgr создает вложенные папки, используя тип ошибки обработки, как имя папок. Например:

InvalidMachine, NonExistentRow, MissingSystemClass, InvalidFileName, ExceedSizeLimit

Подробное описание причин отклонения mif файлов и как с этим бороться описано в статье Umair Khan (Support Escalation Engineer Microsoft Support). Однозначно рекомендую данную статью всем, кто работает с ConfigMgr любых версий.

Исходя из своего опыта, могу добавить, что в русскоязычных средах (где используется кириллица) существует еще одна причина отклонения mif файлов — несовпадение размерности поля ServicePack00 в таблицах dbo.INSTALLED_SOFTWARE_DATA и dbo.INSTALLED_SOFTWARE_HIST. По умолчанию, размерность ServicePack00 (dbo.INSTALLED_SOFTWARE_DATA) — 255 (nvarchar), a размерность ServicePack00 (dbo.INSTALLED_SOFTWARE_HIST) — 8 (nvarchar). В результате, когда ConfigMgr, при обработке mif файла, пытается переместить данные в HIST, они могут не проходить из-за размерности и mif отклоняется. Вариант исправления – изменение размерности поля в таблице HIST. Но, необходимо учитывать, что любые изменения в базе данных ConfigMgr на продакшен сервере Вы можете производить только после тщательного тестирования и это может привести к серьезным сбоям.

Администраторы ConfigMgr должны постоянно контролировать процесс накопления отклонённых mif файлов. Для этого можно использовать системы оперативного мониторинга, имеющиеся в организации или утилиту Inbox Monitor.

Сама hardware inventory хранится в базе данных ConfigMgr в виде большого количества views. Актуальная hardware inventory хранится во view, начинающихся с v_GS, исторические данные хранятся во views, начинающихся с v_HS. Подробная информация с описанием всех views доступна здесь. Используя данную информацию, Вы можете с легкостью получать требуемую отчетность с минимальным усилием.

Надеюсь данная статья поможет администраторам ConfigMgr лучше понимать процесс hinv и даст четкое понимание, как искать и устранять сбои, возникающие во время работы данного функционала.

Об авторе

Андрей Петров — ИТ-специалист с 15 летним стажем, специализируюсь в области Infrastructure Support, Cloud Computing и DevOps.

Предыдущая статья по этой теме: Как не запутаться в аббревиатурах SCCM [Шпаргалка].