OpsMgr R2 and Service Level Tracking (SLT): Targeting explained.

27-01-2010 Update:
The part of this posting where an example of a SLT is built has been updated since it wasn’t spot on.

Out of the field I do get a lot of questions about setting up SLT and more specific how to get the Service Level Objectives (SLOs) with the Collection Rules (Collection rule SLO) functional.

Many times the SCOM Administrators end up with an empty Performance Collection Rule screen, like this:

And soon they say: ‘Duh! SCOM is broken!’. But wait! That’s not the case. It is all about targeting.

When that isn’t done properly, one ends up with an empty screen like the one above. And before targeting can be done properly one needs to get a better understanding about HOW SCOM operates and HOW Classes relate to each other.

Sure, you can click till you drop and hope that on a certain moment you have selected the correct Class at random, but wouldn’t it be nice to approach it in a more intelligent way?

So it is back to the drawing board AND to RTFM the related MP guide(s) as well.

Why RTFM the related MP guides you ask? Good question!

Lets take a look at the Server OS MP Guide for instance. Like every MP Guide it contains a section Understanding Management Pack Operations. This section contains much worthwhile information, like the subsection Classes. A table shows all available Classes in the related MP and describes every Class. So What?

By just looking at the table you get a better understanding of what a certain Class might or might not contain:

I have highlighted some Classes since the Description tells me these Classes do contain other instances as well. Perhaps even some Performance Counters (aka Performance Collection Rules)?

For this we need to go back to the SCOM R2 Console to investigate it further. Lets start the SCOM Console, log on as a SCOM Administrator and select the Wunderbar Authoring and go to Authoring > Management Pack Objects > Rules.

Whenever a collection happens and is to be found back in a Report it is done by a Rule. So this is the place to be. Lets apply some filtering and use the two highlighted Classes we found earlier. Click on the Change Scope link displayed on the top right in the midsection of the SCOM Console. The Scope Management Pack Object screen is shown: 

Select the option View All targets and select the two Classes (Windows Server 2008 Full Computer and Windows Server 2008 Full Operating System) and click OK. Now all related Rules for these Classes are shown:

Whoa! That’s a difference! The first Class shows only 6 rules many of which are contained within the MOM 2005 Backward Compatibility MP which isn’t interesting at all for our quest for Collection Rules.

The second Class shows 44 Rules! That’s more like it! But not EVERY Rule is a Collection Rule. And we need Collection Rules. Lets take a clearer look at these Collection Rules related to this Class:

Thirteen I have counted. So now we know what Class to select for the SLT in order to get a filled Collection rule SLO. Lets make one!

Go to Authoring > Management Pack Objects > Distributed Application > right click > Create a New Distributed Application. Give it a name like WebApp and use as a Template the Line of Business Web Application. DO NOT USE THE Default MP but create a new one instead and click OK.

Now you are in the Distributed Application Designer window. In this example I have added the SCOM Web Console as the Web Site and the OpsMgr DB as SQL Database. Also I have added an additional Component and selected the Component Operating System > Windows Operating System and added the RMS to that Component.

Now the Distributed Application model looks like this:

Save this DA.

Go to Authoring > Management Pack Objects > Service Level Tracking > right click > Create > give it a name > Next > hit the button Select for the option Targeted Class, leave the Search Result Filter as it is (Distributed Application) and select the DA we just created (WebApp) and click OK.
 

Now we are back in the main screen. The earlier created MP is automatically selected and can’t be changed. This is because the selected DA is contained within that MP and any unsealed MP cannot be referenced by any other MP. Click Next.

Click Add > Collection Rule SLO. Now the Service Level Objective (Collection Rule) screen is opened. Give it a logical name. Change the Targeted class to Windows Server 2008 R2 Full Operating System. 

Click on the Select button of the Performance Collection Rule box and the Select a Rule screen is opened. Tada! There are the thirteen Performance Collection Rules: 

Select the the Collection Rule Processor % Processor Time Total 2008 and click OK. Adjust the Aggregation Method and the Service Level Objective Goal as needed and click OK.

While we’re at it, we add a Monitor State SLO to it as well, a bit like this:

Click OK > Next > Finish > Close. 

Now the SLT is built.

Go to the Reporting Wunderbar > Reporting > Microsoft > Service Level Report Library > Service Level Tracking Summary Report. Open this report. Add the earlier built SLT, select a proper start date:

Run the Report: