Creating Groups of Computers based on Time Zone

I have written several posts over the years dealing with authoring groups.  See many examples here:  https://kevinholman.com/2010/07/27/authoring-scom-groups-from-simple-to-complex/

This post will deal with the concept that we might want to create groups in SCOM, of Windows Computer objects, based on the time zone setting for those computers.  This might be useful for maintenance mode, where we want to put all computers in a given Time Zone into maintenance mode at a very specific time on a schedule, for a set maintenance window.

There are lots of ways to do this, we could do a script based discovery, WMI, or registry.

This first example will be somewhat of a “Hack”.  What I found is that in SCOM 2012, there is a new property on the Windows Computer class called OffsetInMinuteFromGreenwichTime.  This property has no discovery associated with it.  I ASSUME this new property had more to do with keeping synchronization with the class properties in Service Manager, as it DOES populate this property there.  What we can do, is write a VERY simple Registry Discovery, and populate this existing Class Property on the Windows Computer class with data.

For this example – we will use the SCOM 2007 Authoring Console…. as it does a simple job for writing a basic discovery.  You can download it here:  http://www.microsoft.com/en-us/download/details.aspx?id=18222

Lets get started:

Open the Authoring Console and create a new empty management pack, give it an ID and a display name:

Open the Health Model pane, and highlight Discoveries.  Right click, choose New, Unfiltered Discovery:

Fill in the required information, which is a Discovery ID, Displayname, and target Windows Server Operating System (provided we only want this data for Servers.)

Set a schedule.  For something like this, every 24 hours is typically just fine.

Accept the default for the Computer name property value:

In the registry properties, we will be getting this data from a Registry Value, which is an Integer located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias.  Give the discovery value a name, such as “ActiveTimeBias” and set it to Integer:

Here is the “hack”.  On the class to be discovered – choose Windows Computer.  In the key properties map it via the “flyout” to the Host – Windows Computer Principal Name value.

In SCOM 2007 R2 – the OffsetInMinuteFromGreenwichTime class property does not exist.  So it does not show up in our list.  No bother – we will just set it to any existing non-key property in the console, and fix it up in XML later.  I am going to choose “LogicalProcessors” just for an example – as a temporary target for our discovered data.  For a registry discovery – the value is in the format $Data/Values/RegistryAttributeName$.  Since we named ours “ActiveTimeBias” in the graphic above, we will match that.

Now save the MP and open the XML in your XML editor of choice.

Find the <InstanceSettings> section of our discovery – this is where we map the discovery data to a class property.  We need to change “LogicalProcessors$” to “OffsetInMinuteFromGreenwichTime$”

 

Save the XML and import it.  You will see your class property get populated in a Windows Computer State or Discovered Inventory view:

 

At this point – we can make a dynamic group based on these values – the offset from GMT.  Central time is 360, Eastern is 300, Pacific is 480.  See example below:

I view group members and see that it is working:

 

The above process will work great for you – IF you are running SCOM 2012.

What if you are using SCOM 2007 R2?  Or what if you don’t want to populate a property on Windows Computer – you’d rather create a class property on your own?

No problem.  In the next example, we will take a different approach.  We will create a new class, which is generic, based on the “Local Application” class.  This class will be generic, used not to discover any specific application, but used to discover lots and lots of properties that we want for specific purposes.  Such as time zone, or custom registry stamping that we add ourselves, or anything really.  Then – we will seal this MP, and use these properties to create groups in many other MP’s.

 

Lets get started 2:  Management pack boogaloo.

 

Again – for this exercise – we will leverage the 2007 R2 Authoring console.  This will allow us to use the MP in SCOM 2007 R2 or in SCOM 2012.

Step 1 – Create an empty MP.

This MP will contain only our one class, and a single discovery for it.  Then – we will seal this MP and only add class properties and discoveries over time.  I used “Custom.Discovered.Properties”

Step 2 – Create a class.

In the Service Model pane, Classes, create a new custom class.  Give it a proper ID

In the next screen – choose a base class.  A Base class is the class type that our custom class will be based on.  Microsoft.Windows.LocalApplication is a good generic base class and was created for uses like this, and common for simple applications.

Give the Class a good display name.  Change the value to “Public” as we wish to leverage this class and properties in other MP’s down the road.

On the Properties tab – right click and create a new property.  Call it “GMTOffset”.  Click OK.

Provide a Display name, then click OK.

 

Step 3 – Create a discovery.

On the Health Model, Discoveries, New, Registry (Filtered).

Provide an ID and displayname for the discovery.

For the target, choose to run this on all Operating Systems, or Server Operating Systems.  Since I will be using this custom class solution on client OS’s and Server OS’s, I will choose “Microsoft.Windows.OperatingSystem”

Run once per day.  Click Next.

Accept the default on the Computer Name screen, and click Next.

On the Registry Probe Configuration – click Add.  For the first registry item, we need to choose a registry Key that will be used to create membership in our class.  Since I want ALL machines to have an instance of this class, I am going to set membership to “Has a registry key of HKLM\SOFTWARE”.  So I select Key, then for the name, I will use “SoftwareKeyExists”.  Type in “software” for the key path, and sett attribute type to “Check if exists” and click OK.

For the second registry entry – this will be to find the value to populate time zone information.  Click Add again, and choose Value, and provide the same name we used before:  “ActiveTimeBias”.   Provide the registry location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias.  Note – HKLM is provided in the console, so start with “SYSTEM”.  Set attribute type to Integer and click OK.

Click Next when done.  Click Insert, and for the parameter, choose “SoftwareKeyExists”.  Set the Operator to “equals”.  Type “true” in for the value.  A “check if exists” (Boolean) expression will be true or false.  If it is found, it will be true, and we will create an instance of our custom class on that agent.

Click Next.  For the class that will be discovered – choose our new custom class we recently created.  For the Key property – choose Host > Principal Name

For the GMTOffset class property – map this to our custom registry discovery data, in the format of:  $Data/Values/ActiveTimeBias$

For the displayname property – I like to use the FQDN of the agent, so Host > NetworkName.

Click Finish.

That’s it!

At this point you can save and import the MP for testing in a lab, or seal it, test, and move into production.

In the SCOM console – Monitoring pane, choose discovered inventory.  Change Target Type to our Custom Discovered Properties Class.  Within a few minutes, you should start to see discovered instances of this class, along with the property value for GMTOffset.  These instances will show “not monitored” by design, as we don’t have any monitors pointing at this class, it is not designed for monitoring purposes, only discovery of custom properties.  Eventually we should see the same number of instances that you have Windows Operating System instances in the management group.

Lastly – we need to create the group.

The SCOM console does not let us create groups of Windows Computers based on a property of a DIFFERENT class… so for this, we need to do a little XML work for the group population.  Jonathan Almquist covered this in a previous blog post:  http://blogs.technet.com/b/jonathanalmquist/archive/2010/07/22/how-to-create-a-group-of-windows-computers-based-on-a-discovered-property-of-virtually-any-class.aspx

Follow that blog post to create the group – and essentially in the XML – your group membership expression will look like this (assuming you sealed the custom discovery MP):

    <MembershipRule> 
      <MonitoringClass>$MPElement[Name="Windows!Microsoft.Windows.Computer"]$</MonitoringClass> 
      <RelationshipClass>$MPElement[Name="SC!Microsoft.SystemCenter.ComputerGroupContainsComputer"]$</RelationshipClass> 
      <Expression> 
        <Contains> 
          <MonitoringClass>$MPElement[Name="ReferenceNameofCustomClassMP!Custom.Discovered.Properties.Class"]$</MonitoringClass> 
        </Contains> 
      </Expression> 
    </MembershipRule>

That’s it.

Now – with this custom class, we can continue to easily add new properties, and add groups based on those custom discovered properties.