SELECT Distinct CommonPublisher,Publisher
FROM v_LU_SoftwareList
INNER JOIN V_LU_Softwarehash ON V_LU_Softwarehash.SoftwareID = v_LU_SoftwareList.SoftwareID
ORDER BY CommonPublisher
Showing posts with label hardware inventory. Show all posts
Showing posts with label hardware inventory. Show all posts
6/27/2011
SCCM Asset Intelligence - List manufacturer friendly names
This Query will list all possible manufacturer listings of an application and the friendly names (grouped)
Labels:
asset intelligence,
catalog,
ConfigMgr,
friendly,
group policy,
hardware inventory,
manufacturer,
microsoft,
name,
query,
SCCM,
software,
vendor
9/27/2010
NULL Values in SCCM Hardware Inventory
I tried to capture the value of the registry key HKLM\SOFTWARE\YOURCOMPANY\Department from all systems independed of the OS architecture. I had the problem that the inventory delivered NULL Values in the database, although everything seemed to be configured correctly. The problem occurred very sporadic. Sometimes a system delivered a value and sometimes it didn’t.
Here’s my basic configuration.mof and sms_def.mof
configuration.mof
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV86", NOFAIL)
[DYNPROPS]
class CustomHINV86
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV86
{
KeyName="CustomHINV";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV64", NOFAIL)
[DYNPROPS]
class CustomHINV64
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV64
{
KeyName="CustomHINV";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
sms_def.mof
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("CustomHINV86", NOFAIL)
[SMS_Report(TRUE),
SMS_Group_Name("Your Custom HINV"),
SMS_Class_ID("YOURCOMPANYYour Custom HINV1.0"),
SMS_Context_1 ("__ProviderArchitecture=32uint32"),
SMS_Context_2 ("__RequiredArchitecture=trueboolean")]
Class CustomHINV86: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String Department;
};
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("CustomHINV64", NOFAIL)
[SMS_Report(TRUE),
SMS_Group_Name("Your Custom HINV"),
SMS_Class_ID("YOURCOMPANYYour Custom HINV1.0"),
SMS_Context_1 ("__ProviderArchitecture=64uint32"),
SMS_Context_2 ("__RequiredArchitecture=trueboolean")]
Class CustomHINV64: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String Department;
};
The result was the following entry in the SQL table
That’s the problem!
As the hardware inventory listed above is designed for both OS architecture, there should be created two entries in the table. I then compared those entries with some working one, from another customization and saw the differences.
The entries were overwritten, as the column KeyName0 is not unique. This also explained the sporadic behavior. Depending on which inventory entry (32bit or 64 bit) was written into the database in which order, the first one was overwritten.
The correct entries for a 64 bit system should look like this:
So the result was to customize the configuration.mof file the get unique KeyName0 columns. Here it is:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV86", NOFAIL)
[DYNPROPS]
class CustomHINV86
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV86
{
KeyName="CustomHINV86";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV64", NOFAIL)
[DYNPROPS]
class CustomHINV64
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV64
{
KeyName="CustomHINV64";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
Here’s my basic configuration.mof and sms_def.mof
configuration.mof
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV86", NOFAIL)
[DYNPROPS]
class CustomHINV86
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV86
{
KeyName="CustomHINV";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV64", NOFAIL)
[DYNPROPS]
class CustomHINV64
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV64
{
KeyName="CustomHINV";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
sms_def.mof
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("CustomHINV86", NOFAIL)
[SMS_Report(TRUE),
SMS_Group_Name("Your Custom HINV"),
SMS_Class_ID("YOURCOMPANYYour Custom HINV1.0"),
SMS_Context_1 ("__ProviderArchitecture=32uint32"),
SMS_Context_2 ("__RequiredArchitecture=trueboolean")]
Class CustomHINV86: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String Department;
};
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("CustomHINV64", NOFAIL)
[SMS_Report(TRUE),
SMS_Group_Name("Your Custom HINV"),
SMS_Class_ID("YOURCOMPANYYour Custom HINV1.0"),
SMS_Context_1 ("__ProviderArchitecture=64uint32"),
SMS_Context_2 ("__RequiredArchitecture=trueboolean")]
Class CustomHINV64: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String Department;
};
The result was the following entry in the SQL table
ResourceID | GroupID | RevisionID | AgentID | TimeStamp | Department0 | KeyName0 |
33 | 1 | 3 | 1 | 14.09.2010 16:59:19 | NULL | CustomHINV |
That’s the problem!
As the hardware inventory listed above is designed for both OS architecture, there should be created two entries in the table. I then compared those entries with some working one, from another customization and saw the differences.
The entries were overwritten, as the column KeyName0 is not unique. This also explained the sporadic behavior. Depending on which inventory entry (32bit or 64 bit) was written into the database in which order, the first one was overwritten.
The correct entries for a 64 bit system should look like this:
ResourceID | GroupID | RevisionID | AgentID | TimeStamp | Department0 | KeyName0 |
33 | 1 | 3 | 1 | 14.09.2010 16:59:19 | NULL | CustomHINV86 |
33 | 1 | 3 | 1 | 14.09.2010 16:59:19 | MyValue | CustomHINV64 |
So the result was to customize the configuration.mof file the get unique KeyName0 columns. Here it is:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV86", NOFAIL)
[DYNPROPS]
class CustomHINV86
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV86
{
KeyName="CustomHINV86";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("CustomHINV64", NOFAIL)
[DYNPROPS]
class CustomHINV64
{
[key] string KeyName = "";
string Department;
};
[DYNPROPS]
instance of CustomHINV64
{
KeyName="CustomHINV64";
[PropertyContext("localHKEY_LOCAL_MACHINE\\SOFTWARE\\YOURCOMPANYDepartment"),
Dynamic, Provider("RegPropProv")]
Department;
};
Labels:
class,
ConfigMgr,
configuration.mof,
database,
entry,
hardware inventory,
null,
reg,
registry,
registry key,
SCCM,
SMS SITE SQL BACKUP,
sms_def.mof,
System Center Configuration Manager,
table,
value,
values
Subscribe to:
Posts (Atom)