Sherry Kissinger at myITforum.com

Hardware Inventory customization - only specific services

There's a particular MOF edit you could use to only report on specific services, and not pull back all services by changing FALSE to TRUE on the win32_service class in the default sms_def.mof.  Since Brian Mason, ConfigMgr MVP, indicated he wants to call out this mof edit at his MMS session, I'm blogging this edit.  I won't tell you why it's so cool--you are going to have to wait until Brian and Steve Thompson's session on Monday!

Below is a sample mof snippet to be added to sms_def.mof and configuration.mof (If you are SMS2003, add both to sms_def.mof or mini.mof, and use your normal mofcomp routine to tell your clients how to report).  This example would be if the only services you wanted to know about were the 1e services for Nomad, Nightwatchman, and their WakeupAgent.  But for an example, it may be that the only services you are interested in would be the firewall, and the services for your anti-malware or anti-spyware.

And special thanks to the Dude at Dudeworks.com, he provided the expertise to create this edit.  Thanks Dude!

//==================================================================
//      Add to SMS_DEF.MOF
//      Created by Dudeworks.com
//      REPORT : Win32_ServicesLTD
//==================================================================
#pragma deleteclass("Win32_ServicesLTD",NOFAIL)

[dynamic, provider("MS_VIEW_INSTANCE_PROVIDER"),
 SMS_Report(TRUE), SMS_Group_Name("Win32_ServicesLTD"),
 SMS_Class_ID("CUSTOM|Win32_ServicesLTD|1.0")]
class Win32_ServicesLTD : SMS_Class_Template
{
                [SMS_Report(TRUE)] String DisplayName;
                [SMS_Report(TRUE), key] String Name;
                [SMS_Report(TRUE)] String PathName;
                [SMS_Report(TRUE)] String ServiceType;
                [SMS_Report(TRUE)] String StartMode;
                [SMS_Report(TRUE)] String StartName;
                [SMS_Report(TRUE)] String State;
};

//--------------------------------------------
// Add to Configuration.mof if Configuration Manager 2007
// Created by dudeworks.com
// Win32_ServicesLTD
//--------------------------------------------
#pragma namespace("\\\\.\\root\\cimv2")

[Union, ViewSources{"select DisplayName,Name,PathName,ServiceType,StartMode,StartName,State from Win32_Service where Name='SMSNomadP2P' OR Name='NightWatchman50' OR Name='SMSWUAgent'"},ViewSpaces{"\\\\.\\root\\cimv2"}, dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]

class Win32_ServicesLTD
{
    [PropertySources{"DisplayName"}]
    string    DisplayName;
    [PropertySources{"Name"},Key]
    string    Name;
    [PropertySources{"PathName"}]
    string    PathName;
    [PropertySources{"ServiceType"}]
    string    ServiceType;
    [PropertySources{"StartMode"}]
    string    StartMode;
    [PropertySources{"StartName"}]
    string    StartName;
    [PropertySources{"State"}]
    string    State;
};

PS: After Brian and Steve's presentation, I'll edit this blog and mention why it's so useful to use this instead of simply enabling the existing win32_services.

Edit:  ok, my promised edit about why this is so cool.  At the company Brian, John, Rob and I work for, there are about two hundred thousand clients.  About a year ago (before I started) during one of their normal hardware inventory reviews, it was determined that no one was using the v_gs_service view for any reports or advertisements based on collections.  At that time, sms_def.mof for win32_service was changed from TRUE to FALSE.  Within a few days, the database size went from 120GB to 80GB.  Holy Recovered Space, Batman!  For various reasons, we were asked to get back service information.  You might be able to guess that there was some slight resistence to increasing DB size by 30% just for 1 report, and that 1 report was really just for us, anyway.  Rob Olson (the Dude from Dudeworks) and I brainstormed and determined it was theoretically possible to just grab the services we cared about.  He put together the edit, and here we are.  Getting the data we want, and not bloating the database.

Report .mof for SCCMExpert datashift

By request, some sample reports for the SCCMExpert / SMSExpert datashift mof scripts.

Extract the .mof file (4reports.mof) and in your console, Reporting, Reports, right-click and Import Objects, point the 4reports.mof, and you'll get 4 reports for the datashift views.

MMS2009 Walking buddy?

I'm trying to walk for exercise; every day.  But somehow... I think that if I don't have a walking buddy during MMS to keep me honest... I'll be slackin'

If you're interested in being my walking buddy, let me know.  Because of conference activities, I'm guessing the best time would be early morning, about 6:30-7:30am.  Also, I'm no power walker; so if that's your walking style, I'll gladly wave as you take laps past me.  I'm more of a "moderate stroller". :-)

Mark Cochrane's RegKeytoMof

Mark Cochrane (System Center Configuration Manager MVP) released an excellent tool to assist with your custom MOF snippet creations, RegkeyToMof.  Grab it from here: http://www.myitforum.com/inc/upload/12336RegKeyToMOF.zip

To use it, Run regkeytomof on a box which has the regkeys you want to gather, and browse in the top window to the Regkey Location, until you see the keys & values you want on the right.  Then below in the middle-right, give it a ClassGroup (like CUSTOM) and a ClassName (this must be unique for each custom mof edit you do--but the ClassGroup of CUSTOM can always be CUSTOM) then just copy & paste the results for configuration mof & sms_def.mof
If there are values that you don't want to see in your database, before you save sms_def.mof, just change those from TRUE to FALSE.  (Leave them defined, but change to FALSE, it needs to be consistent)

For example, I've been meaning to make up a Microsoft Forefront client mof edit, similar to the ones available for McAfee and Symantec, for client AV signature info.  Mark's tool made it much easier.  If you look at the below screenshot, I just browsed until I found the regkeys I wanted (in Software\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Signature Updates.  On the right, I could see there were entries for AVSignatureVersion and ASSignatureVersion.  Looks like just what I wanted!

In the middle, I changed the Classgroup to CUSTOM.  I always use CUSTOM for my custom edits.  That helps me to differentiate anything I've done from a 'real' mof snippet from Microsoft.  If you like, you could use any name; but I would keep it short and consistent, and no spaces.  i.e., if you work for ACME Corporation, use something like ACMECorp.  For ClassName, this must be unique for each custom edit you make.  For example, let's say that one day there will be a Microsoft Forefront version 2.0, and that clients' info goes into a completely different area of the registry.  But for a time, I might need to gather both 1.0 keys and 2.0 keys.  So I couldn't call both of the ClassNames "MSForefront".  That's why in my sample I called it MSForefront1, anticipating that one day there will be a MSForeFront2 I'll want to have.  Also, for the ClassName, no spaces.  And don't use _ i.e., don't use MS_ForeFront_1.0.  I think you *can* use them, but in some places within your database tables/views, you might end up with double _; that just feels messy to me.  So avoid the whole thing and don't use spaces or underscores.  AND keep it short. 

So, cool; I've got my edits.  I'm using Configuration Manager, so I need the results from the SCCM Configuration.mof and SCCM sms_def.mof.  Now, to check them.  Hm... do I really need AVSignatureApplied?  I could, I suppose.. but if I *do* want them, if I actually go look at the registry, those binary values are multi binary, not just 1 entry for binary of 0 vs 1.  It's hard to programmatically see that with regkeytomof, so it's not already set to be multi; but if I DID want to gather that info, I just need to add the [] to those entries.  But actually... those values don't really mean much to me.  They aren't in any kind of calendar date format that makes sense to me.  So I would likely just change those from TRUE to FALSE anyway.  So I'd end up with this.  And it only took me about 10 minutes to get that edit together, and make decisions about TRUE vs. FALSE.  Easy!

// configuration.mof for MS Forefront 1.0 Client Signatures
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("MSForeFront1", NOFAIL)
[DYNPROPS]
Class MSForeFront1
{
[key] string KeyName;
String EngineVersion;
String AVSignatureVersion;
String ASSignatureVersion;
Boolean ASSignatureApplied[];
Boolean AVSignatureApplied[];
String SignatureLocation;
};
[DYNPROPS]
Instance of MSForeFront1
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft Forefront\\Client Security\\1.0\\AM\\Signature Updates|EngineVersion"),Dynamic,Provider("RegPropProv")] EngineVersion;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft Forefront\\Client Security\\1.0\\AM\\Signature Updates|AVSignatureVersion"),Dynamic,Provider("RegPropProv")] AVSignatureVersion;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft Forefront\\Client Security\\1.0\\AM\\Signature Updates|ASSignatureVersion"),Dynamic,Provider("RegPropProv")] ASSignatureVersion;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft Forefront\\Client Security\\1.0\\AM\\Signature Updates|ASSignatureApplied"),Dynamic,Provider("RegPropProv")] ASSignatureApplied;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft Forefront\\Client Security\\1.0\\AM\\Signature Updates|AVSignatureApplied"),Dynamic,Provider("RegPropProv")] AVSignatureApplied;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft Forefront\\Client Security\\1.0\\AM\\Signature Updates|SignatureLocation"),Dynamic,Provider("RegPropProv")] SignatureLocation;
};

//sms_def.mof for MS Forefront 1.0 Client Signatures
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("MSForeFront1", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("MSForeFront1"),SMS_Class_ID("CUSTOM|MSForeFront1|1.0")]
Class MSForeFront1: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String EngineVersion;
[SMS_Report(TRUE)] String AVSignatureVersion;
[SMS_Report(TRUE)] String ASSignatureVersion;
[SMS_Report(FALSE)] Boolean ASSignatureApplied[];
[SMS_Report(FALSE)] Boolean AVSignatureApplied[];
[SMS_Report(FALSE)] String SignatureLocation;
};