Kernel Confusion

At some point in the lifecycle of hardware you are in the position to consider an upgrade to achieve better performance without the cost of a complete renewal of the whole system. In most cases, adding some memory does very well. But what if do not have an up-to-date inventory of all the clients out there? You could send out your apprentice-minions, use scripts or just utilize the mighty Configuration Manager!

With little effort you can extend the hardware inventory so you will get to know

• The total amount of DIMM-Slots
• The free amount of DIMM-Slots

To get your hands on this information, you have to modify the SMS_DEF.MOF on your primary sites. There are two WMI queries that need to run on the client. The first one gets detailed information about every installed module and the second one is used to determine the total and used slots on the mainboard. This is inspired by some wise guy from the myITforum.

The MOF-File in question is located in the following location: <smsinstalldir>\inboxes\clifiles.src\hinv

Be sure to make a backup and, to be on the safe side, do not test this in a productive environment. It’s unlikely that it causes trouble, but we should always fear Murphy’s Law!

Just add the following code at the bottom of the MOF-File and save it.

//**************************************************************************
//* Class: Physical Memory
//* Derived from: (nothing)
//*
//* Auslesen der Speicherinformationen pro installiertem Modul
//*
//**************************************************************************
[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)] uint32 PositionInRow;
[SMS_Report (TRUE)] uint32 Speed;
[SMS_Report (TRUE),Key] string    Tag;
[SMS_Report (TRUE),Key] string    CreationClassName;
};

//**************************************************************************
//* Class: Physical Memory Array
//* Derived from: (nothing)
//*
//* Auslesen der verfügbaren Speicherslots
//*
//**************************************************************************
[SMS_Report (TRUE),
SMS_Group_Name ("Physical Memory Array"),
SMS_Class_ID   ("Microsoft|Physical_Memory_Array|1.0")]

class Win32_PhysicalMemoryArray : SMS_Class_Template
{
[SMS_Report (FALSE)] string Caption;
[SMS_Report (FALSE)] string CreationClassName;
[SMS_Report (FALSE)] string Description;
[SMS_Report (FALSE)] uint16 Location;
[SMS_Report (FALSE)] string Manufacturer;
[SMS_Report (TRUE), SMS_Units("Megabytes")] uint32 MaxCapacity;
[SMS_Report (TRUE)] uint16 MemoryDevices;
[SMS_Report (FALSE)] uint16 MemoryErrorCorrection;
[SMS_Report (FALSE)] string Model;
[SMS_Report (FALSE)] string Name;
[SMS_Report (FALSE)] string OtherIdentifyingInfo;
[SMS_Report (FALSE)] string PartNumber;
[SMS_Report (FALSE)] boolean PoweredOn;
[SMS_Report (FALSE)] boolean Removable;
[SMS_Report (FALSE)] boolean Replaceable;
[SMS_Report (FALSE)] string SerialNumber;
[SMS_Report (FALSE)] string SKU;
[SMS_Report (FALSE)] string Status;
[SMS_Report (TRUE), Key] string Tag;
[SMS_Report (FALSE)] uint16 Use;
[SMS_Report (FALSE)] string Version;
};

As you can see, you can gather much more details if you switch some of the “FALSE” values to TRUE. The next time the client updates his policy, the new code will be compiled on the client. The next scheduled hardware inventory will execute the new queries and report the results back to the assigned site server. When this happens, two new tables will be created in the CfgMgr-Database. In this case, this would be:

• v_gs_physical_memory_array
• v_gs_physical_memory

Of course, this alone won’t help us so much. To make the data readable, we can create a report. I have created a report that combines both tables to show you the details of each installed module, enriched with the information how many slots there are and how much of them are still unused. Feel free to change the SQL statement to your needs.

Report Example

To make things easier, you can download the report’s .MOF-file for quick import into the CfgMgr.

Download: CfgMgr RAM Report MOF