Local Shutdown Tracking in ConfigMgr

Another example I quickly covered in my System Center Universe Europe 2015 session on Advanced Data Collection was tracking shutdowns of managed systems. This is done by selectively collecting event log entries from systems using hardware inventory. As with all things hardware inventory, WMI is the key and in this case, the Windows event log events are in fact easily available using the Win32_NTLogEvent WMI class. This isn’t to say that WMI contains the log events though, this class just exposes the data in the event logs using a WMI provider. Thus querying this class returns events directly from the event logs in real-time.

There are some very IMPORTANT caveats when using this provider to collect events though:

• Collect only what you need. This *will* increase the size of your database as well as the size of the hardware inventory files submitted by clients.
• Since the WMI Provider for Windows event logs queries in real-time, the bigger the event log, the longer it will take to query and return data. This generally shouldn’t be an issue, but it will cause perf hit on your clients based on the size of the event log of each client. As mentioned, this most likely isn’t anything to be concerned with, but it is something to be aware of and potentially monitor on any systems where performance is critical.
• Only info currently in the event log is collected — this should hopefully be obvious. This, of course, means that if your event logs roll based on size, you will have a variable amount of events available on each client. Remember also that ConfigMgr keeps 90 days of hardware inventory by default so it’s not critical to have your logs go back that far if you need to report that far back. The logs do need to be sized so that records are not purged at an interval greater than your hardware inventory though. For example, if you have hardware inventory set to run at the default interval of every seven days and are collecting information from the Windows application event log, then the log needs to hold at least seven days worth of events otherwise relevant events may be missed which will make the entire data set inaccurate at best.

Because we don’t want to collect all of the events exposed in the event log it’s not as simple as adding the Win32_NTLogEvent class which is what we would for any other WMI class. Instead, we need to expose the data that provides a “view” of the data in the Win32_NTLogEvent class. This is essentially just like a view in a database and is done using another provider (the WMI view provider to be exact). The below mof snippet does just this for a very specific subset of events, namely events that are indicative of a system shutdown (as listed in the table near the bottom of this post).

To use this snippet, simply copy and paste it to the end of your configuration.mof file. ConfigMgr will automatically deliver the update configuration.mof to all managed clients via machine policy and compile it into their WMI repositories. After being compiled on a system, a new class, called Local_ShutdownTracker will be available in the root\cimv2 namespace. Querying this new class will return the subset of events that we’ve specified in the mof using a standard WQL query. You will then be able to add this new class to your hardware inventory using client settings. Don’t add Win32_NTLogEvent as this will cause every event to be added to hardware inventory — that would cause your database size to explode and your network team to break out the pitchforks and hunt you down.

[ms_label background_color=”#00274c”]LocalShutdownTracker.mof[/ms_label]

#pragma namespace("\\\\.\\root\\cimv2")

[Union,
ViewSources{"select RecordNumber,SourceName,EventCode,
Message,TimeGenerated,LogFile
from Win32_NTLogEvent where LogFile='System' and
( (SourceName='EventLog' and (EventCode=6006 or EventCode=6008) )
or (SourceName='USER32' and EventCode=1074) )"},
ViewSpaces{"\\\\.\\root\\cimv2"},
dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]
class Local_ShutdownTracker
{
    [PropertySources{"RecordNumber"}, key]
	uint32          RecordNumber;
    [PropertySources{"LogFile"}, key]
	string			LogFile;
    [PropertySources{"SourceName"}]
	string          SourceName;
    [PropertySources{"EventCode"}]
	uint16          EventCode;
    [PropertySources{"Message"}]
	string          Message;
    [PropertySources{"TimeGenerated"}]
	datetime		TimeGenerated;
};

[ms_alert icon=”fa-exclamation-triangle” background_color=”#00274c” text_color=”#f5f5f5″ border_width=”0″ border_radius=”2″ box_shadow=”no” dismissable=”no” class=”” id=””]I formatted the above so it would fit the width of my blog. For this to work, you need to ensure that the ViewSources qualifier is not separated over multiple lines; i.e., remove the new lines from line 4-8 when pasting this into your configuration.mof. (Thanks to Bernhard Kroemeke for pointing this out.)[/ms_alert]

For another example, see Querying Windows event logs using ConfigMgr hardware inventory.