System Center Configuration Manager и как с ним бороться

Как известно, SCCM умеет инвентаризировать реестр и WMI. Часто возникает ситуация, когда собираемых сведений недостаточно и инвентаризацию нужно расширить, например, добавить в отчёт информацию о дате закупки ПК, переноса на другое рабочее место, серийный номер с наклейки на корпусе и т.д. Сделать это можно тремя способами, добавляя (или регулярно добавлять скриптами, обновляя) информацию в:

1. реестр и научить SCCM опрашивать нужные ветки и ключи;

2. WMI и научить SCCM опрашивать нужные классы;

3. MIF-файл. Учить не нужно: SCCM уже умеет вычитывать информацию из MIF-файлов (Management Information Format).

Организация Distributed Management Task Force (DMTF) занимается разработкой и поддержкой стандартов для управления системами. DMTF разработала CIM, WBEM (и его реализация на Windows — WMI), DMI и прочие стандарты, которые используются множеством вендоров. DMI — устаревший стандарт для управления программным обеспечением и аппаратными комплектующими, не зависим от вендора, операционной системы, протоколов управления и «железа».

DMI-архитектура состоит из DMI Service Provider (Service Layer — в старых спецификациях) — локальной резидентной программы, постоянно работающей в памяти, которая является связующим звеном между интерфейсом управляющей программы (Management Interface, MI), которая запрашивает информацию из MIF-базы, и DMI-совместимыми программами и аппаратными комплектующими (Component Interface, CI), которые через свой API вносят информацию в MIF-базу. Информация должна быть описана при помощи MIF — системонезависимого формата, а файлы, содержащие информацию о приложениях и комплектующих, называются MIF-файлами. Вся эта схема выглядит примерно так:

А если сказать совсем просто, то SCCM работает с DMI Service Provider через агента аппаратной инвентаризации, который умеет собирать информацию из MIF-файлов. SCCM умеет работать с IDMIF и NOIDMIF.

IDMIF — файлы с уникальным идентификатором, которые не ассоциированы с клиентом SCCM. Эти файлы отсылаются отдельно от отчёта по инвентаризации. В эти файлы вносят информацию, которая не связана напрямую с компьютером, например, имя копира или модель проектора. При удалении этих файлов с компьютера, информация из базы SCCM не удаляется.

NOIDMIF — файлы, привязанные к идентификатору компьютера, с которого они собраны. Информация из NOIDMIF прикрепляется к отчёту об инвентаризации. В эти файлы вносят информацию, связанную с компьютером, например, серийный номер и т.п. При удалении файлов с компьютера, информация удаляется из базы SCCM.

Если классы, описанные в MIF-файлах, являются уникальными, то они появятся в базе SCCM. В ином случае информация будет добавляться в уже существующие таблицы.

Continue reading ‘расширение инвентаризации при помощи MIF’ »

Предупреждение: не удаляйте руками информацию из базы. Если вы всё же решились на это, то не удаляйте руками информацию из базы.

Вдоволь наигравшись с инвентаризацией MIF-файлов и удалив их с клиента, я обнаружил, что новые классы не удалились из базы данных. В голову мне не пришло ничего лучше, чем через SQL Management Studio удалить новые представления и таблицы, но в базе ещё остались хранимые процедуры и связи с другими таблицами, после чего Resource Explorer вообще перестал показывать данные инвентаризации по клиентам.

В dataldr.log видно, что сервер не может принять отчёт по инвентаризации:

Defining attributes for group INFOABOUTPC…
CGroup::DefineAttributes — Detected schema change. Waiting for the threads to finish the queue.
Thread 7296 has been granted exclusive access.
CGroup::DefineAttributes — Proceeding with schema change.
CDefinedGroup::InsertDefinedAttribute — could not find table
CGroup::DefineAttributes — couldn’t define attributes
CGroup::DefineGroupAndAttributes — couldn’t define attributes for INFOABOUTPC
CMachineSource::InsertMachine — could not validate machine
Cannot process MIF XHE4OF0SZ.MIF, moving it to C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\1kylac3e.MIF
STATMSG: ID=2703 SEV=W LEV=M SOURCE=»SMS Server» COMP=»SMS_INVENTORY_DATA_LOADER» SYS=SCCM01 SITE=M01 PID=2864 TID=7296 GMTDATE=?? ??? 02 09:27:28.848 2011 ISTR0=»XHE4OF0SZ.MIF» ISTR1=»C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\1kylac3e.MIF» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=0

Подсовывание назад MIF-файла с теми же классами не помогло:

CMachineSource::InsertMachine — machine info is resynced data (ie: MIF is a full/resync report).
STATMSG: ID=2715 SEV=I LEV=M SOURCE=»SMS Server» COMP=»SMS_INVENTORY_DATA_LOADER» SYS=SCCM01 SITE=M01 PID=3576 TID=5792 GMTDATE=?? ??? 02 14:12:47.874 2011 ISTR0=»SMS Inventory Agent» ISTR1=»» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=0
*** select InstanceKey,RevisionID,AgentID,Color00,Serial_Number00,Vidan00 from PCinfo_DATA where MachineID = 2 order by InstanceKey ASC
*** [42S02][208][Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name ‘PCinfo_DATA’.
CMachine::EnumGroups — error in csql->Execute
Command:~select InstanceKey,RevisionID,AgentID,Color00,Serial_Number00,Vidan00 from PCinfo_DATA where MachineID = 2 order by InstanceKey ASC
CMachineSource::InsertMachine — could not enum groups. Adding machine.

Сделав запрос в базу данных, обнаружилось, что классы эти до сих пор присутствуют:

Select GroupName, SpecificTableName, HistoryTableName, GroupClass
From GroupMap

Утилита DelGrp.exe из набора System Center Configuration Manager 2007 Toolkit V2 отказалась удалять классы:

После этого я решил воспользоваться утилитой Site Sweeper. Выбрал ненужные мне классы:

И удалил их:

Следующий отчёт инвентаризации с клиента был корректно обработан.

А совсем камикадзе могут попробовать вычистить неиспользуемые классы из базы руками.

В начале сентября в Microsoft Ukraine стартовала серия бесплатных семинаров Microsoft University Осень 2011, на которых рассматривались продукты семейства System Center 2012. Я был докладчиком на двух семинарах по SCCM 2012. Пока сконвертировал и привёл в порядок первый доклад — http://www.techdays.in.ua/videos/3772.html

В докладе кратко рассматривается функционал SCCM: установка программ, обновлений, операционных систем, инвентаризация и т.д. Много времени ушло на объяснение простых вещей, споры и диалоги, поэтому из тайминга выбились, но было весело, что слышно на записи. 🙂

Спасибо всем пришедшим.

В SCCM 2012 суть расширения инвентаризации осталась та же — правка MOF-файлов. Разработчики услышали наши молитвы и теперь MOF-файлы не нужно открывать блокнотом и ломать голову, что и где нужно изменить. 🙂

Можно импортировать из MOF-файлов, экспортировать или добавлять напрямую из WMI:

В InventoryAgent.log на клиенте видно, что инвентаризация собирается и успешно отправлется:

Inventory: Temp report = C:\WINDOWS\system32\CCM\Inventory\Temp\a98b401f-2983-4db4-bd8c-014b10e85e01.xml
Inventory: Starting reporting task.
Reporting: 344 report entries created.
Inventory: Reporting Task completed in 0.828 seconds
Inventory: Successfully sent report. Destination:mp:MP_HinvEndpoint, ID: {C4533A8C-6CF4-4727-BF80-A59E8F3BE6FA}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted
Inventory: Cycle completed in 44.937 seconds
Inventory: Action completed.

Точка управления в лог MP_Hinv пишет, что данные от клиента получены:

Delta report from client TEST, action description = Hardware MP_HinvEndpoint 08.03.2011 21:56:16
Hinv Task: Translate report attachment to file «D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\H0CUTSCD.MIF» returned 0 MP_HinvEndpoint 08.03.2011 21:56:16

Но поместить эти данные в базу не может, что видно из dataldr.log:

CMachineSource::InsertMachine — could not validate machine
Cannot process MIF H0CUTSCD.MIF, moving it to D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\eb4lsv1j.MIF

Инвентаризации по клиенту нет и в консоли SCCM компьютер помечен, как Client=No. Понятно, что проблема в DDR-записи компьютера, которого сервер SCCM считает устаревшим. После принудительного создания DDR и отправки инвентаризации получаем другую ошибку в dataldr.log:

ERROR — attempt to update non-existent row. Invalid command: exec pWorkstationStatus_DATA 1,66,’03/08/2011 21:41:14′,1,’3/8/2011 21:41′,’4294967297′,1049,120
Rollback transaction: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD)
Remote client hardware inventory resync generated for client GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD; update/insert result = 2
Send resync command to local site for machine GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD.
STATMSG: ID=2722 SEV=I LEV=M SOURCE=»SMS Server» COMP=»» SYS=SCCM SITE=000 PID=2596 TID=6476 GMTDATE=Tue Mar 08 19:41:17.426 2011 ISTR0=»TEST» ISTR1=»» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=0
Cannot process MIF XH733SUDL.MIF, moving it to D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\190i3w91.MIF
STATMSG: ID=2703 SEV=W LEV=M SOURCE=»SMS Server» COMP=»» SYS=SCCM SITE=000 PID=2596 TID=6476 GMTDATE=Tue Mar 08 19:41:17.426 2011 ISTR0=»XH733SUDL.MIF» ISTR1=»D:\Program Files (x86)\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\190i3w91.MIF» ISTR2=»» ISTR3=»» ISTR4=»» ISTR5=»» ISTR6=»» ISTR7=»» ISTR8=»» ISTR9=»» NUMATTRS=0
Done: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD) code=2 (11 stored procs in XH733SUDL.MIF)

Удаляем все .MIF-файлы из Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS, перезапускаем службу SMS_SITE_COMPONENT_MANAGER, отправляем инвентаризацию с проблемного клиента ещё раз и видим, что процесс прошёл успешно:

Processing Inventory for Machine: TEST Version 2.1 Generated: 03/08/2011 21:56:15
Begin transaction: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD)
Commit transaction: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD)
Done: Machine=TEST(GUID:3D8C87D1-E1B9-4571-8869-85549F640DAD) code=0 (15 stored procs in XH0CUTSCD.MIF)

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

Mark Cochrane выпустил вторую версию своей известной утилиты RegKeyToMof, которая позволяет легко расширять инвентаризацию, вычитывая информацию из ключей реестра, — http://www.myitforum.com/forums/RegKeyToMof-v2-m220197.aspx

Если в отчёте по оперативной памяти вы захотите увидеть тип памяти, то в столбце MemoryType могут быть нули (http://msdn.microsoft.com/en-us/library/aa394347(VS.85).aspx). Эта ошибка связана со старой версией SMBIOS в операционных системах Windows XP и Windows Server 2003. Я лично столкнулся с такой проблемой.
Далее цитирую Александра Бражникова с форума TechNet, который связался с техподдержкой Microsoftt:

Windows XP сейчас находится в стадии расширенной поддержки.

Слово «расширенной» относится к временному периоду поддержки. Для любого (почти) продукта MS первые пять лет после выпуска осуществляется основная фаза поддержки, затем еще пять лет расширенная фаза поддержки. Так вот последняя предполагает выпуск только критических обновлений безопасности.
 Интересующая нас проблема к критической проблеме безопасности не относится, поэтому для нее фикс выпускать не будут.

Соответственно у нас остается два варианта решения этой проблемы, переход на Windows 7 либо использовать сторонние программы для инвентаризации в Windows XP , и с помощью них создавать mif файлы.

Представим, что появилась потребность узнать, на каких клиентах SCCM 2007 у нас установлены планки памяти 1024 Мб и больше.
Для этого в файл sms_def.mof добавляем следующие строки:

// Physical Memory information

[SMS_Report (TRUE),


SMS_Group_Name («Physical Memory»),


SMS_Class_ID («Microsoft|Physical_Memory|1.0»)]

class Win32_PhysicalMemory : SMS_Class_Template


{


[SMS_Report (TRUE)] string BankLabel;


[SMS_Report (TRUE), SMS_Units(«Megabytes»)] uint64 Capacity;


[SMS_Report (TRUE)] string Caption;


[SMS_Report (TRUE)] string DeviceLocator[];


[SMS_Report (TRUE)] uint16 FormFactor;


[SMS_Report (TRUE)] string Manufacturer;


[SMS_Report (TRUE)] uint16 MemoryType;


[SMS_Report (TRUE)] string Model;


[SMS_Report (TRUE)] string Name;


[SMS_Report (TRUE)] uint32 PositionInRow;


[SMS_Report (TRUE)] uint32 Speed;


[SMS_Report (TRUE),Key] string Tag;


[SMS_Report (TRUE),Key] string CreationClassName;


};
 
После обновления политик на клиентах и прохождения цикла инвентаризации можно строить отчёт (в базе SCCM появится новая таблица v_GS_PHYSICAL_MEMORY):
 
SELECT TOP (100) PERCENT dbo.v_R_System.Netbios_Name0 AS Компьютер, dbo.v_GS_PHYSICAL_MEMORY.Capacity0 AS [Планка памяти]



FROM dbo.v_R_System INNER JOIN


dbo.v_GS_PHYSICAL_MEMORY ON dbo.v_R_System.ResourceID = dbo.v_GS_PHYSICAL_MEMORY.ResourceID


WHERE (dbo.v_GS_PHYSICAL_MEMORY.Capacity0 >= ‘1024’)


ORDER BY Компьютер