Collecting custom WMI classes with SCCM

In earlier versions of SCCM, customizing your inventory involved hand-coding MOF files and then replacing critical files in your SCCM installation directory with these. Even though SCCM was quite smart about parsing these and ignoring invalid files, this still scared most people off even attempting such things and thus custom inventory classes were sadly almost never used in production environments.

Luckily Microsoft streamlined the procedure in SCCM 2012 and it’s now possible to do this purely in the GUI. To extend the inventory, browse to “Administration” -> “Client Setting” then open your default client settings. Go to “Hardware Inventory” then click on “Set Classes…”


In the following window, click on “Add…” then on “Connect…” and enter the name of a PC that you have already run the script from part 1 on. You will then receive a list of the WMI classes available for collection on that PC, one of which will be our newly created one.


Select the MonitorDetails class for collection and press OK three times.

You can now either wait for the settings to take effect on your systems – which may take days depending on your hardware inventory cycle – or you can speed this up by first doing a Machine Policy Retrieval & Evaluation Cycle, waiting a few minutes for that to take effect, then follow up with a Hardware Inventory Cycle.

Our collected data showing up in resource explorer.
Our collected data showing up in resource explorer.

You will also get a new View in your SQL database called v_GS_MonitorDetails that you can query for reports.

In part 3 of this guide I will show you how to create a report to display this collected data.

Collecting monitor serial numbers with SCCM

Configuration Manager already collects some information about the monitors by default, but it is being extremely stingy about it.

Only the resolution is really of any use to us, everything else is quite pointless
This is what ConfigMgr collects out of the box. Only the resolution is really of any worth to us, everything else is useless.

Monitors actually advertise quite a bit more about themselves to the computer in the form of the EDID record. They do that so the operating system can display valid resolutions to the user to choose from, but this record also includes some extremely useful data for our inventory, mostly the manufacturer name, the serial number and the manufacturing date.

Windows collects this data and stores it in the registry in a sub-key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY

Regedit Screenshot

However as you can see above, it is stored directly in the raw binary format sent by the monitor. We can’t collect that from SCCM – it first needs to be converted into nice tabular data. For this, we will use a Powershell script you can get here: Download

We can run this script with administrator rights on any PC that has physical monitors connected to it. VMs and display-less computers obviously don’t work.

Running the script

It will parse the binary data in the correct registry key, create a new WMI class if necessary, then fill it with the most useful EDID fields of all currently attached monitors.

After the script has been run, you can query the new WMI class like usual.
After the script has been run once, you can query the new WMI class like usual.

If you create a package in SCCM with this script and push it out to your PCs you will get a nicely formatted WMI class on all your systems. To make sure that later changes in hardware are correctly recorded you will need to set a repeated deployment schedule – I recommend setting it to the same interval that your hardware inventory runs at.

Alternatively you can of course also use Scheduled Tasks to regularly run it.

Now that we have our data available in WMI, read part 2 of this guide where I will show you how to collect a custom WMI class in SCCM 2012.

Solar eclipse simulator

eclipseThis project originally started because I was bored and thought I could make some prettier graphics than the ones at Wikipedia. But as this stuff usually does, it turned out to be more complex than initially thought, and became a nice experiment that taught me quite a bit about practical astronomy, geographical databases and modern web development.

It is actually quite crazy what sorts of variables you have to consider to accurately model solar eclipses. There are the obvious factors like the ellipticity of orbits, but even smaller ones like Earth’s flattened shape, or the fact that the Earth’s rotation is speeding up because of the last Ice Age’s effects play a huge role and will make your calculations be off by kilometers if they aren’t considered.

Luckily NASA was nice enough to publish their tables of the finished calculations so after a bit of reading up on the interpretation of the data it was quite easy to develop this into a nice looking web app.