Kevin Holman's OpsMgr Blog : Authoring

Writing monitors to target Logical or Physical Disks

kevinhol — Tue, 24 Nov 2009 17:28:49 GMT

This is something a LOT of people make mistakes on – so I wanted to write a post on the correct way to do this properly, using a very common target as an example.

When we write a monitor for something like “Processor\% Processor Time\_Total” and target “Windows Server Operating System”…. everything is very simple. “Windows Server Operating System” is a single instance target…. meaning there is only ONE “Operating System” instance per agent. “Processor\% Processor Time\_Total” is also a single instance counter…. using ONLY the “_Total” instance for our measurement. Therefore – your performance unit monitors for this example work just like you’d think.

However – Logical Disk is very different. On a given agent – there will often be MULTIPLE instances of “Logical Disk” per agent, such as C:, D:, E:, F:, etc… We must write our monitors to take this into account.

For this reason – we cannot monitor a Logical Disk perf counter, and use “Windows Server Operating System” as the target. The only way this would work, is if we SPECIFICALLY chose the instance in perfmon. I will explain:

Bad example #1:

I want to monitor for the perf counter Logical Disk\% Free Space\<All Instances> so that I can get an alert when any logical disk is below 50% in free space.

I create a new monitor > unit monitor > Windows Performance Counters > Static Thresholds > Single Threshold > Simple Threshold.

I target a generic class, such as “Windows Server Operating System”.

I choose the perf counter I want – and select all instances:

And save my monitor.

The problem with this workflow – is that we targeted a multi-instance perf counter, at a single instance target. This workflow will load on all Windows Server Operating Systems, and parse through all discovered instances. If an agent only has ONE instance of “Logical Disk” (C:) then this monitor will work perfectly…. if the C: drive does not have enough free space – no issues. HOWEVER… if an agent has MULTIPLE instances of logical disks, C:, D:, E:, AND those disks have different threshold results… the monitor will “flip-flop” as it examines each instance of the counter. For example, if C: is running out of space, but D: is not… the workflow will examine C:, turn red, generate an alert, then immediately examine D:, and turn back to green, closing the alert.

This is SERIOUS. This will FLOOD your environment with statechanges, and alerts, every minute, from EVERY Operating System.

A quick review of Health Explorer will show what is happening:

This monitor went “unhealthy” and issued an alert at 10:20:58AM for the C: instance:

Then went “healthy” in the same SECOND from the _Total Instance:

Then flipped back to unhealthy, at the same time – for the D: instance.

I think you can see how bad this is. I find this condition all the time, even in “mature” SCOM implementations… it just happens when someone creates a simple perf threshold monitor but doesn't understand the class model, or multi-instance perf counters. In an environment with only 500 monitored agents – I can generate over 100,000 state changes – and 50,000 alerts, in an HOUR!!!!

Ok – lesson learned – DONT target a single-instance class, using a multi-instance perf counter. So – what should I have used? Well, in this case – I should use something like “Windows 2008 Logical Disk” But we can still screw that up! :-)

Bad example #2:

I want to monitor for the perf counter Logical Disk\% Free Space\<All Instances> so that I can get an alert when any logical disk is below 20% in free space.

I create a new monitor > Unit monitor > Windows Performance Counters > Static Thresholds > Single Threshold > Simple Threshold.

I have learned from my mistake in Bad Example #1, so I target a more specific class, such as “Windows Server 2008 Logical Disk”.

I choose the perf counter I want – and select all instances:

And save my monitor.

Ack! The SAME problem! Why????

The problem is – now, instead of each Operating System instance loading this monitor, and then parsing and measuring each instance, now EACH INSTANCE of logical disk is doing the SAME THING. This is actually WORSE than before…. because the number of monitors loaded is MUCH higher, and will flood me with even more state changes and alerts than before.

Now if I look at Health Explorer – I will likely see MULTIPLE disks have gone red, and are “flip-flopping” and throwing alerts like never before.

When you dig into Health Explorer – you will see – that they are being turned Unhealthy – and it isn't event their drive letter! I will examining the F: drive monitor:

I can see it was turned unhealthy because of the free space threshold hit on the D: drive!

and then flipped back to healthy due to the available space on the C: instance:

This is very, very bad. So – what are we supposed to do???

We need to target the specific class (Windows 2008 Logical Disk) AND then use a Wildcard parameter, to match the INSTANCE name of the perf counter to the INSTANCE name of the “Logical Disk” object. Make sense? Such as – match up the “C:” perf counter instance – to the “C:” Device ID of the Logical Disk discovered in SCOM. This is actually easier than it sounds:

Good example:

I want to monitor for the perf counter Logical Disk\% Free Space\<All Instances> so that I can get an alert when any logical disk is below 20% in free space.

I create a new monitor > Unit monitor > Windows Performance Counters > Static Thresholds > Single Threshold > Simple Threshold.

I have learned from my mistake in Bad Example #1, so I target a more specific class, such as “Windows Server 2008 Logical Disk”.

I choose the perf counter I want – and INSTEAD of select all instances, I learn from my mistake in Bad Example #2. Instead – this time I will UNCHECK the “All Instances” box, and use the “fly-out” on the right of the “Instance:” box:

This fly-out will present wildcard options, which are discovered properties of the Windows Server 2008 Logical Disk class. You can see all of these if you viewed that class in discovered inventory. What we need to do now – is use discovered inventory to find a property, that matches the perfmon instance name. In perfmon – we see the instance names are “C:” or “D:”

In Discovered Inventory – looking at the Windows Server 2008 Logical Disk, I can see that “Device ID” is probably a good property to match on:

So – I choose “Device ID” from the fly-out, which inserts this parameter wildcard, so that the monitor on EACH DISK will ONLY examine the perf data from the INSTANCE in perfmon that matches the disk drive letter.

The wildcard parameter is actually something like this:

$Target/Property[Type="MicrosoftWindowsLibrary6172210!Microsoft.Windows.LogicalDevice"]/DeviceID$

This simply is a reference to the MP that defined the “Device ID” property on the class.

Now – no more flip-flopping, no more statechangeevent floods, no more alert storms opening and closing several times per second.

You can use this same process for any multi-instance perf object. I have a (slightly less verbose) example using SQL server HERE.

To determine if you have already messed up…. you can look at “Top 20 Alerts in an Operational Database, by Alert Count” and “Historical list of state changes by Monitor, by Day:” which are available on my SQL Query List. These should indicate lots of alerts, and monitor flip-flop, and should be investigated.

Making groups of logical disks – an example from simple to advanced

kevinhol — Thu, 05 Nov 2009 06:00:37 GMT

I have been seeing this question come up a lot lately – as customers try and create groups of their disks – in order to create overrides for “certain” disks. So – I am creating this post to give some real world examples.

Well – I will start this simply. Say we want to create a group of all logical disks, with the drive letters of C: and D:?

I would start with creating a new group – and adding the “Windows Server 2003 Logical Disk” class. Now – I could just use the parent class of “Logical Disk” instead of the OS specific class if I wanted. The only issue with that is that most monitors targeting a disk – are OS specific – and duplicated three times. So it is best to create specific groups for these – but totally not required.

Ok – so in the Dynamic Members query builder – I click add, and pick a property. Since I know “Device Name” contains the drive letter – this will do nicely. I select device name “Equals” “C:”.

Now – I want to also include D:. There are many way to do – this – and I will go through them. First – I could simply Insert a new line for Windows Server 2003 Logical Disk – and replicate the line I have – adding one for D:

Only one problem – this is an “AND” grouping – I really need this to be an “OR” grouping to include both C: and D: drives. You can switch this grouping the in UI, just right click the word “AND” and change it to an OR grouping:

Voila!

This formula now looks like:

( Object is Windows Server 2003 Logical Disk AND ( Device Name Equals C: ) OR ( Device Name Equals D: ) )

Save your group – then right click it – and choose “View Group Members”. This will ensure we are cooking with gas. It should contain all your Windows 2003 based C: and D: volumes.

So far – so good.

Now – what if I ONLY want C: and D: disks, that are HOSTED by specific Windows Computers? I can do that too! Lets say I want a group – of all the C: and D: logical disks, on servers that begin with the name “SR______”

If you look at the bottom of the list of properties for Logical Disks – you will see (Host=Windows Computer). From here – we can pick any attribute of the Windows Computer class as well to add to our expression – to limit our logical disks in our group to very specific Computers.

Go back to the properties of your group, edit the Dynamic Members, and you can construct something like this:

Which translates to the following formula:

( Object is Windows Server 2003 Logical Disk AND ( Windows Computer.NetBIOS Computer Name Matches wildcard sr* ) AND ( ( Device Name Equals C: ) OR ( Device Name Equals D: ) ) )

Now – I will be honest – getting all the “ands” and “ors” in the right place using the UI is a big pain. It is very easy to screw it up. I like to simplify this to the fewest lines possible – using Regex.

Using Regular Expressions – we can use modifiers to create very advanced expressions. my favorites are ^ which means the beginning of a new line or word, and | which is the “pipe” symbol – which means “or”.

So a simple way to accomplish the same example above – without all the complexity – is this:

WAY simpler!

However – you might notice – this doesn't work right. This is because Regex is case sensitive. If the Server NetBIOS name is detected in all CAPS, this expression wont match. I talk a little about this issue in this post: http://blogs.technet.com/kevinholman/archive/2009/04/21/quick-tip-using-regular-expressions-in-a-dynamic-group.aspx

So – based on that posts example – there is a simple way to make a RegEx case insensitive: (?i:blah)

Using that as an example – we can now make very advanced groupings, quite easily:

(?i: to make it case insensitive. ^ to signify the beginning of the word/line match. Here is the formula now:

( Object is Windows Server 2003 Logical Disk AND ( Device Name Matches regular expression (?i:^C|^D) ) AND ( Windows Computer.NetBIOS Computer Name Matches regular expression (?i:^sr) ) )

Check it out:

Victory!

What if I wanted all logical disks that we NOT hosted by a Virtual Machine? Easy!

( Object is Logical Disk AND ( Windows Computer.Virtual Machine Equals False ) AND True )

This reveals a group of ALL logical disks hosted by a Windows Computer with the attribute of Virtual Machine = False:

As you can see – using the Hosting relationship of the disk – to the Windows Computer object, there is much more you can do with groups.

What is config churn?

kevinhol — Mon, 05 Oct 2009 08:29:49 GMT

There have been a couple good articles briefly covering this topic…. you might have read them. I will reference some below. Config churn is basically, when your RMS is in an almost never-ending loop of generating config. This can be caused by “less than optimized” management packs, pushing agents all the time, or injecting major changes into a management group, such as overrides or custom rules and monitors, or importing updated management packs. By examining this topic in depth – we will re-state some already known best practices with maintaining a healthy management group, and get some deeper knowledge as to why they are best practices in the first place.

Any time you push agents, or create rules and monitors, or overrides for widespread classes….. you can create a config update on the RMS that must be sent down to ALL agents in the management group. For small management groups (under 500 agents) this is generally not a big deal and processes rather quickly. For large management groups over 1000 agents, this can cause high resource utilization of the RMS and SQL Database, in terms of CPU, Memory, and Disk I/O. This can impact data insertion, and console performance during these times. For these reasons, we like to keep those activities down to a minimum during working hours, and schedule these major changes in an off-hours maintenance window.

What about “less than optimized” management packs? What does that mean? Well, this means management packs that you might be using, that have poorly written discoveries.

We have long known that a worst practice in Management Pack development, is to have a discovery that discovers instances of a class, that has properties for those instances that are likely to change frequently. Here is a write-up from OpsManJam on the topic: LINK

Ok… wait… Whaaaaat?

Let me put that in English:

Say we have a discovery for a Logical Disk. This will discover any logical disk, like C:, D:, E:, Q:, etc…. When we write the discovery for a logical disk, we can add properties to that discovery. These are attributes of the discovered instances. So – in this case – lets say we decided to add “Size” of the disk as a property, and “Free Space” as a property. And for the discovery frequency – we will run this discovery every hour, looking for new disks.

“Size” is an excellent property for the Logical Disk class. We like to know the size of the disks…. we can use this property group them if needed. “Size” of a logical disk is not something that we would expect to change very often.

“Free Space” is a horrible property for the Logical Disk class. Free space is something that will likely change, just a small amount even, between each run of the discovery. Free space is a property that is likely to change frequently, therefore – it should NOT be used in a discovery.

Make sense?

Ok – so… what's the big deal?

Well, the agent will run almost all discoveries that it knows about when the health service starts up (like when you bounce the service, or after a reboot). It will always send this discovery data to the management server. (this is another reason why agents restarting all the time is very bad) Then, it will run then based on the “Interval” frequency specified on the discovery. Sometimes this is as frequent as once per hour, sometimes as long as once per day. When the discovery runs, the agent will inspect the discovery data that it gets, and compare it to the last discovery data it sent to the management server. If nothing changed – the agent drops the discovery data and does nothing. IF anything changed in the values of the discovery data – it will re-submit the new data to the management server, which will submit this data to the database. The RMS will detect the change, and will have to recalculate (regenerate) configuration. You will see this on the RMS as a 21025 event:

Log Name:      Operations Manager
Source:        OpsMgr Connector
Date:          9/27/2009 11:51:49 PM
Event ID:      21025
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      OMRMS.opsmgr.net
Description:
OpsMgr has received new configuration for management group PROD1 from the Configuration Service. The new state cookie is "D7 9B A4 BE 00 90 CF 13 35 B5 9B 5F 3B 14 FF 78 D6 13 9A 2D "

The 21025 event isn’t really “bad”… it simply means the config service did its job. It re-generated its configuration file from the database data, and wrote it to: \Program Files\System Center Operations Manager 2007\Health Service State\Connector Configuration Cache\<MGNAME>\OpsMgrConnector.Config.xml The problem is – when this config file gets large (like in large agent count environments) and when the “Config Instance Space” is large (number of discovered objects in total). Recalculating this config can have a significant impact on the disk where the file exists on the RMS, use lots of memory and CPU on the RMS for the config service, and use significant disk I/O on the SQL database.

If the RMS is in a perpetual cycle of recalculating config, and sending these config updates to all agents…. the performance of the management group is impacted.

Daniele Grandini of Quaue Nocent Docent is pretty much the “godfather” of good information researching the 21025 event. Read his 3 part series on config churn here:

http://nocentdocent.wordpress.com/2009/07/09/troubleshooting-21025-events-wrap-up/

So – what can I do if I think I have too much config churn?

The biggest problem causing the most frequent config updates is management packs with noisy discoveries. However, lets wrap up all the issues that can cause it, and what you can do:

New agents. Discover/install/approve new agents in bulk and off-hours.
Overrides. Set overrides during off-hours, or create override MP’s in a lab, then synch to production management groups during schedule off-hours times.
Custom rules and monitors. Create these during off-hours, or create using the authoring console, test in a lab, then import to production during off-hours.
Newly discovered instances. For instance – someone adds a new disk, or SQL database, or DNS zone, to an existing agent. Not much we can do about this, except the expectation that this would be done during off hours.
Management packs with noisy discovery properties. See below.

Ok – the remainder of this article will touch on #5.

How can I tell which discoveries are noisy?

Danilele Grandini has put together a good query on this, from his link: http://nocentdocent.wordpress.com/2009/05/23/how-to-get-noisy-discovery-rules/

I will repost these (slightly modified) below:

/* Top Noisy Rules in the last 24 hours */

select ManagedEntityTypeSystemName, DiscoverySystemName, count(*) As 'Changes'
from
(select distinct
MP.ManagementPackSystemName,
MET.ManagedEntityTypeSystemName,
PropertySystemName,
D.DiscoverySystemName, D.DiscoveryDefaultName,
MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName', MET1.ManagedEntityTypeDefaultName 'TargetTypeDefaultName',
ME.Path, ME.Name,
C.OldValue, C.NewValue, C.ChangeDateTime
from dbo.vManagedEntityPropertyChange C
inner join dbo.vManagedEntity ME on ME.ManagedEntityRowId=C.ManagedEntityRowId
inner join dbo.vManagedEntityTypeProperty METP on METP.PropertyGuid=C.PropertyGuid
inner join dbo.vManagedEntityType MET on MET.ManagedEntityTypeRowId=ME.ManagedEntityTypeRowId
inner join dbo.vManagementPack MP on MP.ManagementPackRowId=MET.ManagementPackRowId
inner join dbo.vManagementPackVersion MPV on MPV.ManagementPackRowId=MP.ManagementPackRowId
left join dbo.vDiscoveryManagementPackVersion DMP on DMP.ManagementPackVersionRowId=MPV.ManagementPackVersionRowId
AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%'+MET.ManagedEntityTypeSystemName+'%'
left join dbo.vManagedEntityType MET1 on MET1.ManagedEntityTypeRowId=DMP.TargetManagedEntityTypeRowId
left join dbo.vDiscovery D on D.DiscoveryRowId=DMP.DiscoveryRowId
where ChangeDateTime > dateadd(hh,-24,getutcdate())
) As #T
group by ManagedEntityTypeSystemName, DiscoverySystemName
order by count(*) DESC

and

/* Modified properties in the last 24 hours */

select distinct
MP.ManagementPackSystemName,
MET.ManagedEntityTypeSystemName,
PropertySystemName,
D.DiscoverySystemName, D.DiscoveryDefaultName,
MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName', MET1.ManagedEntityTypeDefaultName 'TargetTypeDefaultName',
ME.Path, ME.Name,
C.OldValue, C.NewValue, C.ChangeDateTime
from dbo.vManagedEntityPropertyChange C
inner join dbo.vManagedEntity ME on ME.ManagedEntityRowId=C.ManagedEntityRowId
inner join dbo.vManagedEntityTypeProperty METP on METP.PropertyGuid=C.PropertyGuid
inner join dbo.vManagedEntityType MET on MET.ManagedEntityTypeRowId=ME.ManagedEntityTypeRowId
inner join dbo.vManagementPack MP on MP.ManagementPackRowId=MET.ManagementPackRowId
inner join dbo.vManagementPackVersion MPV on MPV.ManagementPackRowId=MP.ManagementPackRowId
left join dbo.vDiscoveryManagementPackVersion DMP on DMP.ManagementPackVersionRowId=MPV.ManagementPackVersionRowId
AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%'+MET.ManagedEntityTypeSystemName+'%'
left join dbo.vManagedEntityType MET1 on MET1.ManagedEntityTypeRowId=DMP.TargetManagedEntityTypeRowId
left join dbo.vDiscovery D on D.DiscoveryRowId=DMP.DiscoveryRowId
where ChangeDateTime > dateadd(hh,-24,getutcdate())
ORDER BY MP.ManagementPackSystemName, MET.ManagedEntityTypeSystemName

Wow – that returned a LOT of discoveries running all the time! What can I do?

Don't import too many MP’s! The FIRST line of defense – is NOT to import ANY management packs into a management group that you don't absolutely need RIGHT THEN. Management packs are constantly updated, and by the time you have an actual SLA in a technology area – there will likely be a newer, better MP available for it. The biggest mistake many customers make is to import any available MP for a technology that they have internally. They end up with a FLOOD of alerts, big fat databases, slow consoles, and lots of weird errors. MP’s should be transitioned slowly, one at a time – tuning and resolving as you go.

Disable the noisy discoveries. Probably not a great solution, unless they discover objects that you really don't care about – but there are other objects in the MP that you DO want to monitor.

Increase the interval of the discovery frequency. This means… essentially – change any “bad” discoveries to run only once per day.

Add a “synch time” override to the discovery – if possible. This option is not available unless the MP author of the discovery exposed it. What this will do – it cause all the agents to ONLY run the discovery at a distinct and specified time every day (say…. 1AM). This might cause too much discovery data to flood in at one time… but since it will all come in at the same time – it wont cause constant config churn all throughout the day.

Re-write the discovery. If this is a custom MP – rewrite the discovery/MP, and remove that property which changes too often.

Make sure your hardware and software is optimized for scalability. On your RMS – it is good to place your config file on fast disks, especially in large environments. I have worked with very large customers who were experiencing config churn, but had zero ill effects, because their RMS disk I/O was on a 4 spindle RAID10 with 15K spindles, CPU and memory were really good, and their SQL database disk I/O for the OpsDB was excellent with plenty of breathing room. I have also worked with smaller agent counts, where config churn has a serious impact…. mostly due to the RMS config file being places on the same RAID spindle set as that OS and pagefile, using only 2 older 10,000 RPM disks. The SQL disk I/O was also just borderline for their agent count.

Re-run the queries periodically – especially after importing/upgrading to a new management pack in your management group. This “instance space change” report should be part of your testing and evaluation of a new MP when brought into your lab…. if you have a large agent count environment.

Some very common discoveries I have seen – that have properties that change very frequently – are listed below. I often recommend these be overridden to run once per day (86,400 seconds)

Discovery Display Name	Discovery Target Class	Discovered Type	Default frequency	Modified frequency
Discover File Groups and Files	SQL 2005 DB Engine	SQL 2005 DB File	7260	86400
Discover File Groups and Files	SQL 2005 DB Engine	SQL 2005 DB File Group	7260	86400
Discover SQL 2000 Databases	SQL 2000 DB Engine	SQL 2000 DB	1800	86400
Discover Databases for a Database Engine	SQL 2005 DB Engine	SQL 2005 DB	7200	86400
DNS 2003 Component Discovery	DNS 2003 Server	DNS 2003 Zone	21600	86400
DNS 2008 Component Discovery	DNS 2008 Server	DNS 2008 Zone	21600	86400
Windows Internet Information Services Base Classes Discovery Rule	IIS 2003 Server Role	IIS FTP Site	3600	86400
Windows Internet Information Services Base Classes Discovery Rule	IIS 2000 Server Role	IIS NNTP Virtual Server	3600	86400

The above is just a sample – you should examine the query output of the query above and see what is impacting your management group the most.

Alert Notification Subscription Variables, and linking that to the console, database, and SDK

kevinhol — Wed, 23 Sep 2009 20:54:00 GMT

Attached you will find a spreadsheet, with all the possible alert notification subscription variables that I am aware of. In this spreadsheet, I link these to the same values in the Alert table of the DB, the alert view of the DB, the Console alert view, the SDK (Get-Alert), and lastly the new R2 Connector Key pairs.

My thought was to better understand each data property type of an alert, and what you can managed, from each area. Hope this is beneficial.

Most of these are listed at my other blog post on alert description and notification variables: http://blogs.technet.com/kevinholman/archive/2007/12/12/adding-custom-information-to-alert-descriptions-and-notifications.aspx

Here is a sample shot of the spreadsheet tool:

See attached:

Nice clean Alert descriptions have been added to R2. Ahem.

kevinhol — Tue, 04 Aug 2009 09:14:34 GMT

I didn't realize this feature got added – very nice.

In OpsMgr SP1 – we had to use some hacks to get the Alert Description formatted to be nicely readable. I wrote about this HERE. The problem was – we could add a </BR> to the alert description and get this to work in SP1 – but in the email subscriptions – it was not formatted the same way and showed the <BR /> in text. You you could have good readable emails or good readable alerts – but not both.

Now – in R2 – this is a much better story.

When authoring a rule against a test event, I can now hit “Enter” and start a new line, just like it should be:

In the console, this now formats exceptionally well – as expected:

However – the email is close – but not perfect. This works most of the time as designed – but occasionally the email subscription does not pick up on the carriage returns.

Note the blobs in yellow above – this is where the Carriage Return did not get picked up.

All is not lost!

One trick – is that this might be caused by ending the line with a variable – as is my example. What I did – was to simply end each variable statement with a real character – I simply added a “period” after each variable as shown:

Which now shows the email formatting as desired:

The XML:

What this does – behind the scenes – is adds the following to the Alert Message ID Display String: (Basically – you can just add carriage returns in the XML and it will be picked up correctly in R2):

        <DisplayString ElementID="MomUIGeneratedRule3407012ebced48c38440ed666eb0ae09.AlertMessage">
          <Name>Custom - Test alert on event 100 from rule</Name>
          <Description>A test event occurred.
The Event ID is: {0}.
The Logging Computer is: {1}.
The Event Source is: {2}.
The Event Level is: {3}.

Event Description = {4}</Description>
</DisplayString>

What do the {numbers} mean? Those are alert parameters. It gets those from the Alert params section in the Rule XML:

<WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert">
<Priority>2</Priority>
<Severity>2</Severity>
<AlertOwner />
<AlertMessageId>$MPElement[Name="MomUIGeneratedRule3407012ebced48c38440ed666eb0ae09.AlertMessage"]$</AlertMessageId>
<AlertParameters>
    <AlertParameter1>$Data/EventNumber$</AlertParameter1>
    <AlertParameter2>$Data/LoggingComputer$</AlertParameter2>
    <AlertParameter3>$Data/EventSourceName$</AlertParameter3>
    <AlertParameter4>$Data/EventLevel$</AlertParameter4>
    <AlertParameter5>$Data/EventDescription$</AlertParameter5>
</AlertParameters>
<Suppression />
<Custom1 />
<Custom2 />
<Custom3 />
<Custom4 />
<Custom5 />
<Custom6 />
<Custom7 />
<Custom8 />
<Custom9 />
<Custom10 />
</WriteAction>

Using the Probe Based Script Event Rule – or – how to used a script to create events in the workflow

kevinhol — Tue, 28 Jul 2009 02:44:00 GMT

So – in my previous post on the basics of MOMScriptAPI.LogScriptEvent, we talked about how to take your own script – and log an event to the OperationsManager Windows Event Log.

One of the challenges with this – is that it will not allow us to add multiple parameters to the event. Using the Probe Based Script Event rule – we can do this…. it is just a bit more complicated. I haven't seen any good examples out there on the basics of authoring this type of rule – so here goes.

For starters – I am going to create this rule in the intended fashion – it is an Event Collection rule by nature. So, I will run the most simple of scripts, on a schedule, and collect the event based output. Then, in the more advanced scenario – I will edit the rule, to add an alert write action – which will be able to pull rich event data into the alert description, or custom fields.

Let’s get started.

Create the rule for a Test MP in your lab. We will be using the Authoring Console to write this rule. If you aren't familiar with the Authoring console yet – you need to get more familiar with it – and this is an excellent chance to get accustomed to the Auth Console for a very simple rule type like this. We “could” make this basic rule in the OpsMgr UI, Authoring tab – but all the advanced functions we need are in the authoring console:

Start up the Authoring console. Choose File, New, Empty Management Pack. Give it an Identity (I will use Custom.Script.Test.MP) Then give the MP a disaply name – which you will see in the console once imported. Use your documented custom MP naming standard here. I will use “Custom – Script Test MP”

In the Auth Console – choose the Health Model tab. Click Rules. Right click in the open space on the right, and choose New > Collection > Event Based > Script Based Event Collection. Here is what pops up:

In the Element ID – this is prefaced my the MP ID, then “NewElement”. So – we need to change “NewElement” to something meaningful… basically – something that represents this rule name. I will use “Custom.Script.Test.MP.CustomRuleTestScript” (This field does not allow spaces)

In the Display Name – this is what will show up in the console UI for the Rule Name – so name this according to your documented custom Rule naming standards. I will use “Custom – Script Event Rule” (This field does allow spaces)

For the target – I will be using my favorite generic target - “Windows Server Operating System”.

Set the Rule Category to “EventCollection”. Here is how it looks filled out:

For testing – we will run this rule every 1 minutes:

Give the script a name – I used TestScript.vbs. Set the TimeOut to 30 seconds (needs to be less than the interval, which in this case was every 60 seconds).

Paste in a sample script:

The script above is very simple – it does not do anything fancy – it simply runs, and submits PropertyBags in the form of Event information, which the Event Workflox in XML can consume, and collect. We are only submitting three items in this basic example – Event ID, and two custom EventParameters.

If we wanted to test this script – to make sure it works correctly – just run it on a test machine with a SCOM agent installed – and examine the output:

C:\bin\scripts>cscript.exe /nologo TestScript1.vbs

<DataItem type="System.PropertyBagData" time="2009-07-27T11:58:39.4154203-05:00" sourceHealthServiceId="2B5A37C8-DB0A-7CAE-DB0E-451EA34FA250"><Property Name="EventID" VariantType="2">10</Property><Property Name="EventParam1" VariantType="8">SomeText1</Property><Property Name="EventParam2" VariantType="8">SomeText2</Property></DataItem>

This is the expected output above.

Next – on the Event Mapping screen… we need to fill in variables – or hard coded information we want in our script.

For the Computer field – we will use a Windows Computer property, to place the NetBIOS name of the Windows Computer hosting this Operating System, into the event. Click the browse button at the right – and choose Target, then (Host=Windows Computer), then NetBIOS Computer Name. It should look something like this: $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosComputerName$

For the Event Source and Event Log, those are our own custom source and log – since this isn't a real Windows Event… so I will use “MyCustomEventSource” and “MyCustomScriptEventLog” for examples here. You can use anything you like.

Leave EventID at the default variable.

I will be using Category = 1, and setting Level = Error:

Now – create the rule, and then save the MP.

If we imported this simple MP into our lab management group - what we should should see – is that OpsMgr is collecting this event in the database every minute, for our test machine. Create a view in MyWorkspace for event ID 10:

Notice the event details:

This is pretty basic. Lets examine the XML for our rule: I highlighted in blue and bold, all the stuff we just did in the UI – so you can see where it matches up:

      <Rule ID="Custom.Script.Test.MP.CustomRuleTestScript" Enabled="true" Target="Windows!Microsoft.Windows.Server.OperatingSystem" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>EventCollection</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.EventProvider">
            <IntervalSeconds>60</IntervalSeconds>
            <SyncTime />
            <ScriptName>TestScript.vbs</ScriptName>
            <Arguments />
            <ScriptBody><![CDATA[Dim oAPI, oBag
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
Call oBag.AddValue("EventID",10)
Call oBag.AddValue("EventParam1","SomeText1")
Call oBag.AddValue("EventParam2","SomeText2")
Call oAPI.Return(oBag)           ]]></ScriptBody>
            <TimeoutSeconds>30</TimeoutSeconds>
            <EventOriginId>$MPElement$</EventOriginId>
            <PublisherId>$MPElement$</PublisherId>
            <PublisherName>MyCustomEventSource</PublisherName>
            <Channel>MyCustomScriptEventLog</Channel>
            <LoggingComputer>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosComputerName$</LoggingComputer>
            <EventNumber>$Data/Property[@Name='EventID']$</EventNumber>
            <EventCategory>1</EventCategory>
            <EventLevel>1</EventLevel>
            <UserName />
            <Description />
            <Params />
          </DataSource>
        </DataSources>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
          <WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData" />
        </WriteActions>
      </Rule>

The above is very simple – a rule, using the built-in TimedScript.EventProvider Data source, which runs a script every 60 seconds, and submits some PropertyBags as event data.

TimeoutSeconds was configured on the Script page in the UI.

EventOriginId and PublisherId will be left at defaults.

PublisherName = “Event source” in the UI.

Channel = “Event log” in the UI.

EventNumber = “Event ID” in the UI.

EventCategory = “Category” in the UI.

EventLevel = “Level” in the UI. (0=Success, 1=Error, 2=Warning, 4=Information)

UserName, Description, and Params are not exposed in the UI – but can be filled in by variable output of your custom script for advanced scenarios, or you could hard code these in your XML if needed.

Ok – done with the simple stuff…… :-)

Now – what if we don't want to COLLECT the event – we want to ALERT, if this event is created as an option of our script? Well – we can do that – just not in the regular Console UI. We need to edit the <WriteActions> part of the XML, along with several other parts of XML – OR – we can add this very simply in the Authoring Console.

So – back to the Authoring console.

Right click the custom rule we just created – and choose Properties.

Select the Modules Tab.

In the Actions area – click the Create button.

Scroll down – and highlight the System.Health.GenerateAlert. For “Module ID” – type in “Alert” and click OK (see graphic)

Back on the Modules Tab – Highlight “Alert” under Actions, and click the Edit button.

On the pop-up – click “Configure”

Now you can fill out the details on this familiar screen. Give it a good Alert Name. Set the Priority and Severity as desired.

Click Alert Suppression, and suppress duplicate alerts based on your choosing. I will use Event ID, and Logging Computer.

Click OK several times to accept these changes, and then save your MP.

At this point – you can import the MP and it works as designed…. you will run the script – create the script based event data, collect the event in the OpsMgr database, and then also – generate an Alert each time the script runs, based on the event data. Here is an example of the alert generate:

Now – lets make the alert richer. The whole point of this exercise was to be able to add multiple parameters as variables to the Alert – for instance – to be able to add them as Custom Fields in the alert.

In order to do this – we need to add a few things to the rule:

First – we need to add the Parameter to the data source:

In the Authoring Console – right click the rule and choose properties.

Select the Modules tab.

Highlight the Data Source and click Edit.

Click Configure.

Go to the Event Mapper Tab, and click the “Parameters” button. We will past in the following parameters – separated by a SPACE:

$Data/Property[@Name='EventParam1']$ $Data/Property[@Name='EventParam2']$

These are the parameters directly from our script:

Call oBag.AddValue("EventParam1","SomeText1")
Call oBag.AddValue("EventParam2","SomeText2")

This will allow our Alert workflow to call these parameter variables – and place the resolved text into the Alert description or custom fields.

Lets do that!

In the Authoring Console - on the Modules tab of the custom rule, highlight the Alert Action, and click Edit.

Click the Configure button.

Add the parameter variables to the Alert Description field, and Custom Field 8 and Custom Field 9. These should be in the syntax of:

$Data/Params/Param[1]$

$Data/Params/Param[2]$

etc….

Click OK on the screens to save your changes, save, and import your test MP.

The alerts will now have richer data available – with the alert description and custom fields now populated with your custom script based event parameters:

Below – you will find my final XML attached (with the rule disabled so it wont flood your environment should you import it)

101: Using custom scripts to write events to the OpsMgr Event Log with MOMScriptAPI.LogScriptEvent

kevinhol — Wed, 22 Jul 2009 08:15:55 GMT

This is very basic 101 stuff. I provide some links to some much deeper articles.

When converting MOM 2005 scripts…. on of the common things to do is to change the way events are written.

In MOM 2005, we would most commonly use a custom method, ScriptContext.CreateEvent, which would create custom events via script in the MOM channel, that other event workflows could pick up on (Script Generated Data Source).

Alternatively – we would use the native VBscript methods to write a generic event to the application event log.

A GREAT write-up on this whole process – breaking it down step by step is located here:

Updating MOM 2005 Scripts for Operations Manager 2007:

http://www.systemcentercentral.com/Downloads/DownloadsDetails/tabid/144/IndexID/7608/Default.aspx

This MOM 2005 method has been deprecated in OpsMgr 2007. It still is possible to utilize via converted MOM 2005 MP’s… but the best practice is to convert these to native SCOM scripts, and use the MOMScriptAPI.LogScriptEvent method, which will write a real event to the OperationsManager event log. You will see many Microsoft MP’s do this… such as the ADMP, DHCP, and Exchange MP’s, even the core test scripts. Here are some examples:

Event Type:    Information
Event Source:    Health Service Script
Event Category:    None
Event ID:    6022
Date:        7/21/2009
Time:        8:00:03 PM
User:        N/A
Computer:    EX07A
Description:
LogEndToEndEvent.js : This event is logged to the Windows Event Log periodically to test a event collection.

Event Type:    Information
Event Source:    Health Service Script
Event Category:    None
Event ID:    19960
Date:        7/21/2009
Time:        11:06:30 PM
User:        N/A
Computer:    EXCH1
Description:
Check service(s) state : All specified services are running. List of specified services: MSExchangeIS, MSExchangeMGMT, MSExchangeMTA, MSExchangeSA, SMTPSVC, W3SVC

Event Type:    Information
Event Source:    Health Service Script
Event Category:    None
Event ID:    1112
Date:        7/21/2009
Time:        7:51:34 PM
User:        N/A
Computer:    DC01
Description:
DHCP2003ComponentDiscovery.vbs : Discovery of DHCP components started. Portion 1

The MOMScriptAPI.LogScriptEvent method is documented here: http://msdn.microsoft.com/en-us/library/bb437630.aspx

To start – I am just going to write a timed event rule, which will run a script that will create a simple event every minute – using the sample provided at the link above.

New Rule > Timed Commands > Execute a Script

Give it a Rule name according to your documented Rule naming standard. I will target my favorite generic target - “Windows Server Operating System”.

Set it to run every 60 seconds (only for testing in a lab!!!)

For the File Name – I am using LogScriptEvent.vbs, set the timeout to 30 seconds (less than the interval!) and paste in the sample script:

Option Explicit
Dim oAPI, oArgs
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oArgs = WScript.Arguments

' Check to see if the required script arguments are there.
' In this example, at least three arguments are required.
' If the arguments do not exist, log a script event.
If oArgs.Count <3 Then
    ' If the script is called without the required arguments,
    ' create an information event and then quit.
    Call oAPI.LogScriptEvent("LogScriptEvent.vbs", 101, 0, "LogScriptEvent script was called with fewer than three arguments and was not executed.")
    WScript.Quit -1
End If

' When it passes the required arguments check satisfactorily, the
' remaining script, located here, is run.

All this script does – is log an error – if there not at least 3 arguments (script parameters) passed to the script – it logs an error in the OpsMgr event log.

Create it, and here is what I start seeing every minute in my OpsMgr event log:

Log Name:          Operations Manager
Source:               Health Service Script
Date:                   7/21/2009 11:32:15 PM
Event ID:            101
Task Category:   None
Level:                 Information
Keywords:          Classic
User:                  N/A
Computer:          OMTERM.opsmgr.net
Description:
LogScriptEvent.vbs : LogScriptEvent script was called with fewer than three arguments and was not executed.

So – it works very simply. See the link above for what you can customize with this. Now – any custom VBscript you like – you can take the output of those scripts, and log events using OpsMgr.

What is even cooler… is testing your SCOM scripts is easier than ever… you can simply run them on any machine that has an OpsMgr agent installed. If they submit data – such as propertybags, you will see those in the command window. If they log events – they will log the event immediately in the OpsMgr event log.

Here is another very simple script… which will take the script parameters as arguments, and log them in the event description:

Option Explicit
Dim oAPI, oArgs
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oArgs = WScript.Arguments

Call oAPI.LogScriptEvent("LogScriptEventArgs.vbs", 102, 2, oArgs(0) & " " & oArgs(1) & " " & oArgs(2))
WScript.Quit -1

When you call the script – you must pass parameters to the script:

cscript.exe LogScriptEventArgs.vbs scriptparam1 scriptparam2 scriptparam3

This creates the following event:

Log Name:            Operations Manager
Source:                 Health Service Script
Date:                    7/22/2009 12:07:09 AM
Event ID:              102
Task Category:    None
Level:                   Warning
Keywords:            Classic
User:                    N/A
Computer:            OMTERM.opsmgr.net
Description:
LogScriptEventArgs.vbs : scriptparam1 scriptparam2 scriptparam3

There are a few things we would LIKE to have with this – but don't:

1. We cannot change the Event Source… it is hard coded to “Health Service Script”

2. We cannot have event parameters in the event description. This method is hard coded to 2 event parameters. The script Name is Params/Param[1], and the “bstrDescription” string value is a single parameter, Params/Param[2]

Still – this method is very useful, when your complex VBScripts have multiple possible outputs… you can use the LogScriptEvent method to log distinct events, and then have other rules and monitors alert, or respond to, those custom events.

Using a Generic Text Log rule to monitor an ASCII text file – even when the file is a UNC path

kevinhol — Sat, 20 Jun 2009 02:23:11 GMT

There are several examples in blogs on how to create a generic text log rule to monitor for a local text file (Unicode, ASCII, or UTF8).

This will be a step-by-step example of doing the same, however, using this to monitor the log file on a remote UNC path instead of a local drive. This is useful when we want to monitor a file/files on a NAS or an a share that is hosted by a computer without an agent.

This is a bit unique… instead of applying this rule to ALL systems that might have a specific logfile present in a specific directly – we are going to target this rule to only ONE agent. This agent will monitor the remote fileshare similar to the concept of a “Watcher Node” for a synthetic transaction. Therefore we will be creating this rule disabled, and enabling it only for our “Watcher”.

In the Ops console – select the Authoring pane > Rules.

Right click Rules, and select Create a new rule. We will chose the Generic Text Log for this example:

Choose the appropriate MP to save this new customer rule to, and click Next.

For this rule name – I will be using “Company Name – Monitor remote logfile rule”

Set the Rule Category to “Alert”

For the target – I like to use “Windows Server Operating System” for generic rules and monitors.

UNCHECK the box for “Rule is enabled”

Click Next.

The directory will be the UNC path. Mine is “\\VS2\Software\Temp”

The pattern will be the logfile(s) you want to monitor. We can use a specific file, such as “logfile.log” or a wildcard, such as “*.log”.

You should not check the “UTF8” box unless you know the logfile to be UTF8 encoded.

Click Next.

On the event expression, click Insert for a new line. Essentially – log file monitors look at each new line in a logfile as one object to read, and this is represented by “Params/Param[1]” This “Parameter 1” is the entire line in the logfile, and is the only value that is valid for this type of monitor – so just type/paste that in the box for Parameter Name.

Since we want to search the logfile line for a specific word, the Operator will be “Contains”.

For the value – this can be the word you are looking for in the line, that you want to alert on. For my example, I will use the word “failed”.

Click Next.

On the alert screen – we can customize the alert name if desired, set the severity and priority, and build a better Alert Description. If you are using SP1 – the default alert description is blank. If you are using R2 – the default alert description is “Event Description: $Data/EventDescription$” HOWEVER – this is an invalid event variable for this type of event (logfile)…. so we need to change that right away. I keep a list of common alert description strings HERE

For this – I will recommend the following alert description. Feel free to customize to make good sense out of your alert:

Logfile Directory : $Data/EventData/DataItem/LogFileDirectory$
Logfile name: $Data/EventData/DataItem/LogFileName$
String: $Data/EventData/DataItem/Params/Param[1]$

Click “Create” to create the rule.

Find the rule you just created in the console – right click it and choose “Properties”. On the Configuration tab, under responses (to the right of “Alert”) click Edit.

Click the “Alert Suppression” button. You should consider adding in alert suppression on specific fields of an alert – in order to suppress a single alert for each match in the logfile. If you don't – should the monitored logfile ever get flooded with lines containing “failed” from the application writing the log – SCOM will generate one alert for each line written to the log. This has the potential to flood the SCOM database/Console with alerts. By setting alert suppression here – we will create one alert, and increment the repeat count for each subsequent line/alert. I am going to suppress on LoggingComputer and Parameter 1 for this example:

Click OK several times to accept and save these changes to the rule.

Now – we created this rule as disabled – so we need to enable it via an override. I will find the rule in the console – and override the rule “For a specific object of class: Windows Server Operating System”

Now – pick one of these machines to be the “watcher” for the logfile in the remote share.

**Note – the default agent action account will make the connection to the share and read the file. In my case – the default agent action account is “Local System” so this will be the domain computer account of the “Watcher” agent which connects to the remote share and reads the file. This account will need access to the share, folder, and files monitored. Keep that in mind.

Set the override to “Enabled = True” and click OK.

At this point, our Watcher machine will download the management pack again with the newly created override, and apply the new config. Once that is complete – it will begin monitoring this file. You can create a log file in the share path, and then write a new line with the word “failed” in it. You need a carriage return after writing the line for SCOM to pick up on the change.

You should see a new alert pop in the console, based on matching the criteria. Subsequent log file matches will only increment the repeat count. Customize the alert suppression as it makes sense for you.

Then – create additional rules just like this – for different UNC paths.

Web Application recorder R2 – the recorder bar missing in IE?

kevinhol — Fri, 19 Jun 2009 18:15:34 GMT

Sometimes getting the web application recorder to capture a web session can be a little tricky. I have blogged about some typical issues you might run into HERE

Something I noticed today, with R2:

When running the R2 console on an x64 machine – the web recorder bar is not coming up.

On my x86 machine – it was working just fine, however. I notice – when I go into IE settings, Tools, Manage Add-ons….. I see this on a working machine:

However – these add-ons are missing on my x64 based consoles.

The problem turned out to be…. that when you install the console on an x64 machine, it registers the x64 version of these add-ons. However – the IE browser launched by default by hitting “Start Capture”, is the x86 version. You have to manually launch the x64 IE shortcut – in order to use the web recorder browser.

So here are some steps to make this work:

1. Open the web application editor

2. Hit “Start Capture”

3. This will launch Internet Explorer in 32 bit mode. Close this browser.

4. From the start menu, run Internet Explorer (64-bit)

5. The web recorder will appear. (If not – choose View > Explorer Bars > Web Recorder)

From there you can record your session, hit stop, and it will populate the web application tool as normal. Just a minor inconvenience of closing one browser, and opening another.

Creating custom dynamic computer groups based on registry keys on agents

kevinhol — Wed, 10 Jun 2009 07:09:48 GMT

I have had a few requests now for this, so I thought I would take the time to write up the process.

Lets say I have three support levels of servers:

Level 1 – servers critical to business operations (ex: customer facing web applications, SQL back-ends)

Level 2 – important servers (ex: messaging, internal apps)

Level 3 – non-essential servers (ex: non-critical or highly redundant internal apps)

Lets say we want to create overrides for certain rules… where we will page on anything in Level 1 group, email notify on Level 2 group, and simply alert for Level 3. Possibly we want to create views, and only see alerts for Level 1 servers. Perhaps we wish to scope users so they only see Level 1 and Level 2 servers in the console?

Well – the first step is to place these servers into groups.

Sure – we can do this manually, with explicit assignments to the group. But that is resource intensive over time, and we might miss one down the road. I’d prefer to dynamically create the groups of Windows Computers based on a name…. but this can be difficult sometimes – where we don't have a solid naming scheme, or other criteria to group by.

I will demonstrate another way to accomplish this… by coming up with a business process to use a registry key on your managed servers, and collect this registry attribute with SCOM. Then – use this Registry attribute for dynamic group memberships.

Ultimately – there are three simple steps to this process:

1. Create registry keys on agents.

2. Extended a class with an attribute, to discover the registry keys and values.

3. Create dynamic groups based on the attribute values from the registry.

It is just that simple.

To get started – lets talk about our custom registry key. For this example, I am going to create a new Key at HKLM\Software\ and call it “CompanyName”

Next – in that key – I will create a new DWORD Value, named “SupportLevel”

Lastly – I will assign a numeric value to “SupportLevel” on each server, either 1, 2, or 3.

In my environment…. my Hyper-V servers are critical. They host all of my VM’s, including many business critical applications. Therefore – they will get Level 1.

My Exchange 2007 servers handle all my mail traffic and notifications, so I will set their registry value to Level 2.

My Exchange 2003 servers have been retired – for MP testing only… so we will set those to Level 3.

Here is a table that shows what I am planning:

ServerName	SupportLevel
VS1	1
VS2	1
VS3	1
EX1CLN1	2
EX1CLN2	2
EXCAS	2
EX2CLN1	3
EX2CLN2	3
OWA	3

So – I get all my registry values set on all computers. This is a big job at first, but it is a one time deal, and you can even script it if you are handy.

Next… we need to discover these registry entries in SCOM, as attributes of a class. Then were can use that attribute to group objects. Since I want Windows Computer objects in my groups (Windows Computer is a good object for most overrides, scoping, notifications…etc..) we would like to have these attributes added to the Windows Computer class.

However – there is a problem. The Windows Computer object is in a sealed MP. We cannot just add information to that class as we would like. Therefore – OpsMgr allows us to “Extend” an existing class… and add our custom attributes to it. This “Extended” class is basically a copy of the existing class… it will have all the built in attributes of Windows Computer, and will also have our custom attribute properties. It’s is easier to see it than to talk about it.

First – in the Ops console – authoring pane – go to Attributes. Create a new attribute. I am going to call this one “SupportLevel”

Next – choose “Registry” for the discovery type.

Next – We need to pick the Target class. We want Windows Computer. Note – this will create a new class, named “Windows Computer_Extended” by default. We can use this name, or you can rename this whatever you want. It is your class. I will leave it at the default.

Most important! Management Pack location.

This is CRITICAL. Spend some time making sure you are creating these attributes in the correct location. If you leave this MP unsealed XML…. then any groups you create that use these attributes, will have to be placed in this same MP. Then – if you use these groups for Overrides – those overrides will be force to go in this same MP. There is a “cardinal rule” in SCOM… objects in one unsealed MP cannot reference another unsealed MP. So – we cannot have a group in one unsealed MP, and then use that group for an override in another unsealed override MP.

So – we have two choices.

1. Keep an unsealed MP… and live with the fact that attribute, group, and override will all have to be placed here.

2. Create the attribute and the dynamic group in the MP, then seal it. Then – you can use this group in ANY of your override MP’s… for Exchange, SQL, etc…

I strongly recommend option #2 for this exercise… but you can make this decision for yourself.

Ok…. I will choose Option #2 (seal the MP), so I will create a new MP just for this extended class, and groups.

On the next screen – we can put in our registry information:

In this example – I am looking for a registry Value (1, 2, or 3), and my attribute type is “Int” for integer.

For the frequency, set this to a reasonable frequency to discover you machines as they come on to you network. Typically, once per day is sufficient (86400 seconds) Remember – this will run against ALL your Windows Computers… so never set this more frequent than once per hour… that creates unnecessary overhead.

Ok – lets examine our work!

Go to Monitoring, Discovered Inventory, and change target type to our new class “Windows Computer_Extended”

If you do this quickly – you may find it is empty. This is what is happening behind the scenes: All Windows Computers are now downloading our newly created MP. They are going to run the registry attribute discovery, and submit their discovery data to the management server. The Management Server will insert this discovery data in the database. Over time, you will start to see all your Windows Computers pop into this class membership. You will notice a new attribute now, in addition to all the existing Windows Computer attributes. This attribute is “SupportLevel” and will be 1, 2, 3, or empty… depending on what each agent find in the registry.

Now – I set my registry discovery to once per day…. so I will need to wait 24 hours before I can expect all my healthy agents to show up in this list. To speed things up – I am going to bounce the HealthService on these example agents. (Agents run all discoveries when a HealthService restarts, and then on their frequency schedule)

Here is an example a few minutes after bouncing the HealthService on some agents:

Next on the list – create the groups. I will create these in the same MP that the attributes exist in.

I will call my first group “CompanyName – Support Level 1 Servers Group”. I like to append the word “Group” to all groups I create as a best practice. This helps us determine this group class is actually a group when we see it in the list of classes in the UI. I sure wish all MP authors would take this to heart, since every group is actually a singleton class.

On the dynamic members screen – I will fins my “Windows Computer_Extended” class – and click Add. What we now see – is that we have a new attribute to use, “Support Level”

I will set this group to “SupportLevel Equals 1” and click OK.

Now – I can right-click my new group – and choose “View Group Members”

Yee-haw! It works! Now – I simply repeat this above step – creating groups for SupportLevel 2, and 3.

Now – that is done. This is the area, that I recommend we stop… take a breather…. then seal the MP. If you seal the MP – we will be able to use the groups for overrides in any other override MP. If you choose not to seal the MP now… any overrides you use the groups for – will be forced into this same MP. Please keep that in mind.

Since I am harping on sealing the MP…. I am going to do a quick example of just that. Jonathan Almquist has an excellent tutorial on sealing MP’s HERE and we will use his example.

**Note – when running the sn.exe commands to create our key…. we only need to do this one… not every time we want to seal an MP.

***Critical note – you need to keep a backup of this key… because it will be required for making updates to this MP in the future, re-sealing, and keeping the ability to upgrade the existing MP in production.

So, I create the folders, create the key using sn.exe, copy over the referenced MP’s from the RMS, and now I am ready to seal.

MPSeal.exe c:\mpseal\input\CompanyName.SupportLevel.MP.xml /I "c:\mpseal\mp" /Keyfile "c:\mpseal\key\PairKey.snk" /Company "CompanyName" /Outdir "c:\mpseal\output"

Works great.

Now – I can delete my unsealed MP from the management group, and import my sealed MP.

Phew. All the heavy lifting is done. Now… I have my groups… I can start setting up overrides using these groups, or scoping notifications.

On my Support Level 1 group – I will use this to set up my pager Notification subscriptions to only page based on specific classes, and this group.

On my Support Level 2 group – I will use this to override important alerts to High Priority… because I am using High Priority as a filter for email notifications, per my previous blog post here: http://blogs.technet.com/kevinholman/archive/2008/06/26/using-opsmgr-notifications-in-the-real-world-part-1.aspx

On my Support Level 3 group – I will use this group for tweaking/disabling rules and monitors for the group… turning off discoveries so they don't discover lab servers, scoping views, etc.

Maybe in my next post…. I will build on this MP… and show a really simple way to add the Health Service Watcher objects to these dynamic groups… for each Windows Computer object that is in the group – so we can use these groups for Heartbeat failure notifications.

Quick tip – using regular expressions in a dynamic group

kevinhol — Tue, 21 Apr 2009 22:29:12 GMT

Here is a quick tip on using a regular expression when creating a group.

OpsMgr dynamic inclusion rules are case sensitive.

If I have a group that I want to contain all computers that START with “OM”…. I can use the following expression:

The “^” tells regex to start a new line… without this – it will search the entire computername for “OM” instead of only servers with a name that starts with “OM”. This shows the following group membership:

However – this is not all my “OM” servers. This is because when some were built, they used a lower case name. If I change the dynamic inclusion expression to “^om” I will only see the lower case servers (the NetBIOS Computer name is lower case… not the display name as shown):

Ok – how do I get them ALL in the same group?

There are a couple ways.

One way is to “OR” the two regex queries:

Bingo!

Another way – courtesy of Tim Helton – is to use the regex modifier (?i:) to make it case insensitive:

Which yields:

This should make dynamic groups a bit easier. We can expand this to add the HealthService Watcher objects, which is typical for groups that we will scope notifications to:

Which yields all my Windows Computers, and their Health Service Watcher components.

Authoring rules for Windows 2008 events, and how to cheat

kevinhol — Wed, 25 Feb 2009 04:56:03 GMT

So…. with the introduction of Server 2008 into OpsMgr… as a monitored agent, you might need to re-evaluate some of your old rules.

Almost all (if not all) of the basic event ID’s and parameters, in the security event log, have changed.

For instance, I had a rule to alert me on every RDP logon to every server in my lab. I did this on Server 2003, using the following data source configuration:

The logon event was 528, I used the Security event source (not really required in this case) and then I only wanted to alert on RDP/Console logon types… so that is where Parameter 4 came in. I had to use LogParser to figure out which parameter is which, and talked about how to do that in these posts:

Using Event Description as criteria for a rule

How to find all possible event ID’s for a given event source

Using OpsMgr to see which servers have not been logged on to via RDP

Now – I realized, since I rebuilt my main Terminal Server with Server 2008, this rule isnt alerting anymore.

It is apparent that the new security event is now this:

So – off I go to update my rule.

I will use Event ID 4624, that part is easy…. but now – which parameter is the logon type of “10” now?

I can certainly use LogParser… and it will tell me, but in Server 2008 – there appears to be a shortcut: Choose the Details Tab of the event you want, and all the parameters are listed, in order… and you simply have to count down:

Counting down from the top – that is Parameter 9. So my new data source expression for the rule looks like this:

So – I will ONLY get alerts on those specific events. But wait – I need to customize my Alert description! I can use the same “cheat”. In my alert description – I want to state something like “Username logged on to ServerName from IPAddress”. I can get all of that right, and the parameters – right from this event:

Counting down – I can see this is parameter 6, 12, and 19. So I make my alert description look like so:

And my alert?

Perfect!

Use this method to quickly figure out which parameters you want for your rule criteria, and your alert descriptions.

UPDATE – 2-25-2009

I have to update this post – based on the comment from Raphael Burri (http://rburri.wordpress.com/)

In addition to the easy way to find out parameters in Server 2008 – he commented on an even better way to bring rich alert descriptions in… without much work.

So for this example – I will create a new rule – which will alert me when someone types a bad password while accessing my Terminal Server:

The event in question – has changed from EventID 528 on Server 2000/2003 – to EventID 4625 on Server 2008:

Now – instead of using event parameter numbers in my Alert Description – I will use the event XPath name straight from the event! Open the event… and choose the details tab. Then choose the XML view. It looks like this:

Now – to capture ANY of these “Event Data” fields… we could use parameters – counting down like the example I posted above. OR – we can simply pull the parameter name – which is given to us right from the event:

Simply use this format:

$Data/EventData/DataItem/EventData/Data[@Name='EventParameterName']$

For instance… I want my alert description for this alert to state:

(Username) typed a bad password accessing directly from computer: (computername) from IP: (IP Address)

So from above – I can simply use the “Data Names” listed in the event data:

$Data/EventData/DataItem/EventData/Data[@Name='TargetUserName']$

$Data/EventData/DataItem/EventData/Data[@Name='WorkstationName']$

$Data/EventData/DataItem/EventData/Data[@Name='IpAddress']$

My alert description now looks like this:

The alert comes in as:

Thanks for the tip Raphael!

How to find all possible event ID’s for a given event source

kevinhol — Tue, 17 Feb 2009 01:09:47 GMT

I recently got this question from a customer… and felt it would be good to blog about this.

The customer wants to create an Alert, anytime there is a event in the System event log, from a USER32 event source:

HOWEVER – it is a best practice in SCOM – to create our event matching criteria to be MOST SPECIFIC as possible.

The problem: How do I know all possible event ID’s that COULD show up under a given event source?

The solution? Use the MOM 2005 resource kit tool, called MPWizard.exe.

NOTE: The MOM 2005 MPWizard states that it needs to be run on a MOM 2005 management server… but I have tested, and it only really needs to be run on a machine with the MOM 2005 console installed…. if you don't have a MOM 2005 environment, simply install only the console and you can use this tool. There might be a “cheat” way to run this tool registering a couple MOM 2005 DLL’s – but I haven't looked into that. If you get a COM error, and cannot get this to run, and the MOM 2005 console is not an option – I recommend you check out using LogParser – which I have a link below.

MPWizard will let us interrogate the local computer, OR a remote computer, and determine ALL POSSIBLE events for a given event source, and has the added benefit of showing us the event parameters as well.

For example, I will launch MPWizard, and choose “Event Source Monitoring”:

Give it a “TEST” rule group name… since we really wont be creating a MOM 2005 Management Pack here.

Click “Add”, and choose the local computer, or a remote computer example.

Choose the event source we are interested in:

As you can see – this will interrogate the Event log source DLL for the USER32 event source, and show all possible events that *could* be created by this event source (dll) and their parameters for each event.

Now – I can create a much more specific rule – and include the event ID’s, and also use event parameters if needed:

Now – if I DONT want this alert on a specific group of machines…. I can create an exception, based on parameter 1:

Using the MOM 2005 MP wizard is a very easy way to find all possible event ID’s for a given event source, AND will show us the parameters that each event uses…. very helpful in keeping with SCOM best practices if being very specific, and using event parameters instead of searching the entire event description, which is resource intensive.

You can get the MOM 2005 reskit download HERE: http://technet.microsoft.com/en-us/opsmgr/bb498240.aspx

Also – be sure to check out how to use LogParser – another free tool – to find event parameters, in this blog post: Using Event Description as criteria for a rule

What is a group anyway?

kevinhol — Thu, 05 Feb 2009 08:52:46 GMT

So – this is a first part, of a multi-post series on creating groups.

The most common reason we create groups in OpsMgr… is to scope Notifications, Views, and to use for overrides.

Most of the groups my customers create are dealing with Windows Computer objects. The reason for this, is that the Windows Computer object class, is a “parent" level” class that works well for the group uses just mentioned. Lets look at what a group really is… in XML:

When we create a simple group to contain Windows Computers in the UI, it creates some basic XML behind the scenes. Understanding this XML – will help us create much more powerful and dynamic groups down the road… doing things that cannot be done in the UI.

Let's get started.

I will create a new empty MP, named “GroupMP”.

With nothing in this MP… let’s look at the XML:

Not much there. We have the <Manifest> section, which contains the name, version, ID, and a single reference – to the System Center Library MP. The <Presentation> section simply contains the UI generated folder name, which will show up in the console, by default. The <LanguagePacks> section contains the friendly names for the MP name and the folder… which will be displayed in the console.

Now – lets add a group. I will create a new group in the UI, named “ATestGroup”. I will not give it any group membership…. and save it to my new MP, and export it. Let’s see what changed:

<?xml version="1.0" encoding="utf-8"?><ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>GroupMP</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>GroupMP</Name>
    <References>
      <Reference Alias="SystemCenter">
        <ID>Microsoft.SystemCenter.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="MicrosoftSystemCenterInstanceGroupLibrary6062780">
        <ID>Microsoft.SystemCenter.InstanceGroup.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
</Manifest>
<TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="UINameSpace66d4622586f2416c804144a081d72995.Group" Accessibility="Public" Abstract="false" Base="MicrosoftSystemCenterInstanceGroupLibrary6062780!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" />
      </ClassTypes>
    </EntityTypes>
</TypeDefinitions>
<Monitoring>
    <Discoveries>
      <Discovery ID="UINameSpace66d4622586f2416c804144a081d72995.Group.DiscoveryRule" Enabled="true" Target="UINameSpace66d4622586f2416c804144a081d72995.Group" ConfirmDelivery="false" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryRelationship TypeID="MicrosoftSystemCenterInstanceGroupLibrary6062780!Microsoft.SystemCenter.InstanceGroupContainsEntities" />
        </DiscoveryTypes>
        <DataSource ID="GroupPopulationDataSource" TypeID="SystemCenter!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="UINameSpace66d4622586f2416c804144a081d72995.Group"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule Comment="EMPTY_RULE_8eadaced-59c8-4ebc-a4e4-b8428a374442">
              <MonitoringClass>$MPElement[Name="SystemCenter!Microsoft.SystemCenter.AllComputersGroup"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="MicrosoftSystemCenterInstanceGroupLibrary6062780!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <Value>True</Value>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>False</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
</Monitoring>
<Presentation>
    <Folders>
      <Folder ID="Folder_ba0b8fceb992416c835fe9d66a6ce0a1" Accessibility="Public" ParentFolder="SystemCenter!Microsoft.SystemCenter.Monitoring.ViewFolder.Root" />
    </Folders>
</Presentation>
<LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="GroupMP">
          <Name>GroupMP</Name>
        </DisplayString>
        <DisplayString ElementID="Folder_ba0b8fceb992416c835fe9d66a6ce0a1">
          <Name>GroupMP</Name>
        </DisplayString>
        <DisplayString ElementID="UINameSpace66d4622586f2416c804144a081d72995.Group">
          <Name>ATestGroup</Name>
        </DisplayString>
        <DisplayString ElementID="UINameSpace66d4622586f2416c804144a081d72995.Group.DiscoveryRule">
          <Name>Populate ATestGroup</Name>
          <Description>This discovery rule populates the group 'ATestGroup'</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
</LanguagePacks>
</ManagementPack>

I have bolded in Red color – the new stuff.

In the <Manifest> section, we added a new reference… to the Microsoft.SystemCenter.InstanceGroup.Library MP, and gave it an alias of “MicrosoftSystemCenterInstanceGroupLibrary6062780”. An alias is just a short way of referring to a management pack… (just not so short when created by the UI) :-)

We also added a new section, <TypeDefinitions> In here – we defined a new class type… for the UI generated group. In this case – it is UINameSpace66d4622586f2416c804144a081d72995.Group. The UI creates a randomly generated name for the group… just to make sure all group ID’s are unique in a management pack. This definition of this group class, is based on the “Microsoft.SystemCenter.InstanceGroup” class, which is called from the recently referenced “Microsoft.SystemCenter.InstanceGroup.Library” MP, using the alias we just talked about. Notice - “Singleton = True”. Without going too deep at this point, this means the Group is a class, but is a single instance class… the only instance of this group class will be the group itself. It may have members in the group at some point…. but those members are NOT instances of the group class. They are simply objects, that have a containment relationship from the group class. Ok, not too deep right now.

We also added another new section to the XML - <Monitoring> Under <Monitoring> we will define the discovery that we need to run – in order to populate the group membership. This discovery by default will call the “Microsoft.SystemCenter.GroupPopulator” (Group populator module) from the “SystemCenter!” alias (Microsoft.SystemCenter.Library MP) This discovery will define what types of objects the group will contain, and any <MembershipRule> expressions we need to use to “match” on those objects. For instance… we might want to match only on Windows Computer objects, with a NetBIOS Name that starts with “EX*” using a wildcard. All this can be done with the UI – but at this point – we left it all blank. What you see is is a basic discovery that does nothing… in this case.

We will also notice – that the <DisplayStrings> section got updated with a friendly name for the new discovery rule… which will be visible in the console for the object discovery.

Ok…. now lets add a simple discovery rule… a dynamic rule, that will place Windows Computer objects that match the example I just used… NetBIOS names that start with “EX”

If I perform a “View Group Members” (after a short wait for the updated MP to be processed by the RMS, and the group populator module to complete)… I will see this when I “view group members”:

So far, so good. I have 4 Windows Computer objects in my group, all matching my criteria. Lets look at the XML now, with the newest updates bold and blue:

<?xml version="1.0" encoding="utf-8"?><ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>GroupMP</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>GroupMP</Name>
    <References>
      <Reference Alias="MicrosoftSystemCenterInstanceGroupLibrary6062780">
        <ID>Microsoft.SystemCenter.InstanceGroup.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SystemCenter">
        <ID>Microsoft.SystemCenter.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="MicrosoftWindowsLibrary6062780">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
</Manifest>
<TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="UINameSpace66d4622586f2416c804144a081d72995.Group" Accessibility="Public" Abstract="false" Base="MicrosoftSystemCenterInstanceGroupLibrary6062780!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" />
      </ClassTypes>
    </EntityTypes>
</TypeDefinitions>
<Monitoring>
    <Discoveries>
      <Discovery ID="UINameSpace66d4622586f2416c804144a081d72995.Group.DiscoveryRule" Enabled="true" Target="UINameSpace66d4622586f2416c804144a081d72995.Group" ConfirmDelivery="false" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryRelationship TypeID="MicrosoftSystemCenterInstanceGroupLibrary6062780!Microsoft.SystemCenter.InstanceGroupContainsEntities" />
        </DiscoveryTypes>
        <DataSource ID="GroupPopulationDataSource" TypeID="SystemCenter!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="UINameSpace66d4622586f2416c804144a081d72995.Group"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule>
              <MonitoringClass>$MPElement[Name="MicrosoftWindowsLibrary6062780!Microsoft.Windows.Computer"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="MicrosoftSystemCenterInstanceGroupLibrary6062780!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
              <Expression>
                <RegExExpression>
                  <ValueExpression>
                    <Property>$MPElement[Name="MicrosoftWindowsLibrary6062780!Microsoft.Windows.Computer"]/NetbiosComputerName$</Property>
                  </ValueExpression>
                  <Operator>MatchesWildcard</Operator>
                  <Pattern>EX*</Pattern>
                </RegExExpression>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
</Monitoring>
<Presentation>
    <Folders>
      <Folder ID="Folder_ba0b8fceb992416c835fe9d66a6ce0a1" Accessibility="Public" ParentFolder="SystemCenter!Microsoft.SystemCenter.Monitoring.ViewFolder.Root" />
    </Folders>
</Presentation>
<LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="GroupMP">
          <Name>GroupMP</Name>
        </DisplayString>
        <DisplayString ElementID="Folder_ba0b8fceb992416c835fe9d66a6ce0a1">
          <Name>GroupMP</Name>
        </DisplayString>
        <DisplayString ElementID="UINameSpace66d4622586f2416c804144a081d72995.Group">
          <Name>ATestGroup</Name>
        </DisplayString>
        <DisplayString ElementID="UINameSpace66d4622586f2416c804144a081d72995.Group.DiscoveryRule">
          <Name>Populate ATestGroup</Name>
          <Description>This discovery rule populates the group 'ATestGroup'</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
</LanguagePacks>
</ManagementPack>

This basically just added a new reference, and modified the discovery rule section – to reflect our updated relationship and criteria.

The new <reference> was because we added the “Windows Computer” object class to the group definitions. This class needs to be referenced, because it lives in the “Microsoft.Windows.Library” MP, which the UI gave a reference alias of “MicrosoftWindowsLibrary6062780”.

The UPDATED <MembershipRule> section now has some new information.

First – it defines the <MonitoringClass> we will use in this membership rule to be Windows Computer objects.

Next – it defines that the group will contain entities in the <RelationshipClass> section, esentially building the containment relationship between the Group Class Instance, and the Windows Computer objects.

Last – it defines the expression to use to “match” on the defined property we chose (NetBIOS name) with a pattern (EX* wildcard) We can match on ANY known attribute of a class… and NetBIOS name is but one of many on the Windows Computer class.

This understand will be a fundamental building block… for the next group posts… which will require that we see what is happening behind the scenes with a basic group, in order to use much more advanced groupings, that prove difficult or impossible to achieve in the console.

Populating groups from a SQL server CMDB – step by step

kevinhol — Tue, 27 Jan 2009 21:54:00 GMT

Boris wrote a cool article HERE on how to populate a group of computers in OpsMgr, from an external source…. such as active directory. In his published example – you run an LDAP query to AD, to return a recordset list if computers, in order to populate them into a group.

This post will extend that, by showing how to do the same thing – but using a SQL database as the CMDB source for populating groups, instead of AD. I had a customer who wanted to do this – to dynamically create groups for the purpose of scoping console views and notifications, to the teams that “owned” the different servers. The CMDB contained this data, but it changes often, so manually controlling this proved to be a pain.

Here is a very simple example of the CMDB, which contains the ServerName, and the team that owns the server, in the “ServerList” table:

As you can see… I can easily write a SQL query to show ONLY servers owned by TEAM 1:

Let’s use this data source… to populate three groups. Team 1 Group, Team 2 Group, and Team 3 group.

First – I will post my finished XML example at the bottom – go grab that and open it – it will help you follow along with the XML requirements.

In the XML… we basically need 4 components:

1. We need to define the name of the MP, and add references to other MP’s we will depend on. (<Manifest> Section)

2. We need to define the groups themselves, and then define the relationships (stating that they will contain Windows Computer Objects) (<TypeDefinitions> section)

3. We need to run a discovery to populate the groups… this will be a script based discovery that runs only on the RMS, queries the CMDB, matches on the servername FQDN, and populates the group with a windows computer object. (<Monitoring> section)

4. We need to modify the display strings in the XML MP – in order to show friendly display names for each of the above, in the UI. (<LanguagePacks> Section)

You can simply take the XML posted below, and just modify each section with your custom group names… or add new groups by adding a new class, relationship, discovery/script, and presentation section to each.

Here we go:

Section 1: <Manifest>

Simply modify the <ID>, <Version>, and <Name> sections based on your custom MP naming standard.

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>SQLBasedGroupDemo</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>SQLBasedGroupDemo</Name>
    <References>
      <Reference Alias="SC">
        <ID>Microsoft.SystemCenter.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Health">
        <ID>System.Health.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.0.6278.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
</Manifest>

Section 2: <TypeDefinitions>

The example below defines 3 groups, and the relationships for those groups (contains windows computer objects). Simply replace the bolded red “Team1Group” example with a short name for your custom groups. (We will define the UI friendly name later, in the <Presentation> section.

<TypeDefinitions>
<EntityTypes>
    <ClassTypes>
      <ClassType ID="GroupPopulation.Team1Group" Accessibility="Internal" Abstract="false" Base="System!System.Group" Hosted="false" Singleton="true" />
      <ClassType ID="GroupPopulation.Team2Group" Accessibility="Internal" Abstract="false" Base="System!System.Group" Hosted="false" Singleton="true" />
      <ClassType ID="GroupPopulation.Team3Group" Accessibility="Internal" Abstract="false" Base="System!System.Group" Hosted="false" Singleton="true" />
    </ClassTypes>
    <RelationshipTypes>
      <RelationshipType ID="GroupPopulation.Team1GroupContainsWindowsComputers" Accessibility="Internal" Abstract="false" Base="System!System.Containment">
        <Source>GroupPopulation.Team1Group</Source>
        <Target>Windows!Microsoft.Windows.Computer</Target>
      </RelationshipType>
      <RelationshipType ID="GroupPopulation.Team2GroupContainsWindowsComputers" Accessibility="Internal" Abstract="false" Base="System!System.Containment">
        <Source>GroupPopulation.Team2Group</Source>
        <Target>Windows!Microsoft.Windows.Computer</Target>
      </RelationshipType>
      <RelationshipType ID="GroupPopulation.Team3GroupContainsWindowsComputers" Accessibility="Internal" Abstract="false" Base="System!System.Containment">
        <Source>GroupPopulation.Team3Group</Source>
        <Target>Windows!Microsoft.Windows.Computer</Target>
      </RelationshipType>
    </RelationshipTypes>
</EntityTypes>
</TypeDefinitions>

Section 3: <Monitoring>

In this section – we define the discovery, and add the script to run. In this example – I am running a VBscript with a SQL query to the CMDB. You will need to modify the group name – just like you did above. This is where we create a discovery to populate each group – so we will need one of these sections for each group in the MP. Each of these sections will run a distinct script, with a different query, depending on which computers you want populated.

I bolded in RED the group name sections you will need to modify, just like we did above… and you will need to modify the SQL DB information, and the script name.

I set the discovery time to every 3600 seconds in this example…. you should probably set this to once or twice a day max…. no need to keep re-running it for groups that wont change that often.

<Monitoring>
    <Discoveries>
      <Discovery ID="Team1Group.Discovery" Enabled="true" Target="SC!Microsoft.SystemCenter.RootManagementServer" ConfirmDelivery="true" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryClass TypeID="GroupPopulation.Team1Group" />
        </DiscoveryTypes>
        <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">
          <IntervalSeconds>3600</IntervalSeconds>
          <SyncTime />
          <ScriptName>Team1GroupDiscovery.vbs</ScriptName>
          <Arguments>$MPElement$ $Target/Id$</Arguments>
          <ScriptBody><![CDATA[Dim SourceId
Dim objConnection
Dim oRS
Dim sConnectString
Dim ManagedEntityID
Dim oAPI
Dim oDiscoveryData
SourceId                = WScript.Arguments(0)
ManagedEntityId         = WScript.Arguments(1)
Set oAPI                = CreateObject("MOM.ScriptAPI")
Set oDiscoveryData      = oAPI.CreateDiscoveryData(0,SourceId,ManagedEntityId)
sConnectString = "Driver={SQL Server}; Server=OMDW; Database=CMDB;"
Set objConnection = CreateObject("ADODB.Connection")
objConnection.Open sConnectString
Set oRS = CreateObject("ADODB.Recordset")
oRS.Open "select ServerName from ServerList where MonitorGroup = 'Team 1'", objConnection
Set groupInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='GroupPopulation.Team1Group']$")
While Not oRS.EOF
Set serverInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='Windows!Microsoft.Windows.Computer']$")
serverInstance.AddProperty "$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$",oRS.Fields("ServerName")
Set relationshipInstance = oDiscoveryData.CreateRelationshipInstance("$MPElement[Name='GroupPopulation.Team1GroupContainsWindowsComputers']$")
relationshipInstance.Source = groupInstance
relationshipInstance.Target = serverInstance
oDiscoveryData.AddInstance relationshipInstance
oRS.MoveNext
Wend
objConnection.Close
Call oAPI.Return(oDiscoveryData)
                     ]]></ScriptBody>
          <TimeoutSeconds>120</TimeoutSeconds>
        </DataSource>
      </Discovery>

Section 4: <LanguagePacks>

Here – we will take ALL of the modifications we made in the prior three steps, and match them up with friendly names to show in the UI:

Essentially – just modify the MP name, group name, relationship name, and discovery name, to match what you did above…. and assign each a friendly name that you want to see in the UI. I will bold in red the sections to modify, for the “Team 1 servers”. You would continue this for as many groups as you used:

<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="true">
    <DisplayStrings>
      <DisplayString ElementID="SQLBasedGroupDemo">
        <Name>SQL Based Group Population Demo MP</Name>
      </DisplayString>

      <DisplayString ElementID="GroupPopulation.Team1Group">
        <Name>Team 1 Servers Group</Name>
      </DisplayString>
      <DisplayString ElementID="GroupPopulation.Team1GroupContainsWindowsComputers">
        <Name>Team 1 SQL Based Group Contains Windows Computers</Name>
      </DisplayString>
      <DisplayString ElementID="Team1Group.Discovery">
        <Name>Team 1 SQL Based Group Discovery</Name>
        <Description />
      </DisplayString>

      <DisplayString ElementID="GroupPopulation.Team2Group">
        <Name>Team 2 Servers Group</Name>
      </DisplayString>
      <DisplayString ElementID="GroupPopulation.Team2GroupContainsWindowsComputers">
        <Name>Team 2 SQL Based Group Contains Windows Computers</Name>
      </DisplayString>
      <DisplayString ElementID="Team2Group.Discovery">
        <Name>Team 2 SQL Based Group Discovery</Name>
        <Description />
      </DisplayString>

      <DisplayString ElementID="GroupPopulation.Team3Group">
        <Name>Team 3 Servers Group</Name>
      </DisplayString>
      <DisplayString ElementID="GroupPopulation.Team3GroupContainsWindowsComputers">
        <Name>Team 3 SQL Based Group Contains Windows Computers</Name>
      </DisplayString>
      <DisplayString ElementID="Team3Group.Discovery">
        <Name>Team 3 SQL Based Group Discovery</Name>
        <Description />
      </DisplayString>

</DisplayStrings>
</LanguagePack>
</LanguagePacks>

That’s it! If you get errors trying to import – you most likely modified a definition incompletely…. the import error should help you figure out what's wrong.

Now I can go to my groups – find “Team 1 Group” and see if it is populated: SUCCESS!

I am attaching my working sample MP below