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.
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.
Configuration Manager already collects some information about the monitors by default, but it is being extremely stingy about it.
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
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.
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.
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.
This 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.