Step 1: Open SCOM Operator’s Console
Step 2: Go to the Authoring Tab
Step 3: Create New Rule
Basic Performance Metric Collection for Group
This entry was posted in Generic SCOM Information, Management Pack Authoring. Bookmark the permalink.
Things that I have picked up while using SCOM — Posts in this blog are provided "AS IS" with no warranties, and confers no rights
Living with SCOM 
I don’t mean to sound nitpicky, but the use of groups for target anything other than an override is not best practice. I see this happen all the time, though. I’ve even done this in the past, but only because I didn’t realize the potential impact this could have on a management group. It is never necessary to create a monitoring workflow disabled and enable for a group. It is always possible to discover the computers you really want to target, and then create your monitor or rule enabled at that class or type.
Hey Johnathan,
If you notice this whole post is done in the Operators Console. Not all of our application owners need to know about classes / discoveries. This post is targeted at that group of people (people who know what perf counter / event they want to collect and can define a group of servers based on naming standards to collect it for). It is all about making the initial steps into SCOM easy for our application owners and moving them along the steep SCOM learning curve as needed.
“Jonathan Almquist says:
I don’t mean to sound nitpicky, but the use of groups for target anything other than an override is not best practice.”
I just completely disagree with that statement. Groups are used for scoping views, notifications, overrides, used in reports, even used for monitoring by rolling up state.
The simple use of targeting a generic class with a workflow as disabled, and enabling it for a group, is very much valid, in my opinion. It does have drawbacks, especially in relation to monitors and seeing this monitor in Health Explorer. Targeting a custom class is almost always better…. but this approach is certain not invlaid, and certainly a LOT simpler for a team to enable something as simple as performance collection for a group of servers, where a group already exists and a class does not.
Let me rephrase. The use of groups for targeting *monitoring workflows* is not best practice. I wasn’t referring to views, notifications, etc… We can agree to disagree, but I do understand that this is the easiest way to implement some types of monitoring or collection for a set of servers.
Incidentally, the reason it is not the best practice is because there are in fact some drawbacks. Think about where this workflow will be delivered after you create it. Whether the monitoring workflow is created disabled or enabled, the management pack will be delivered to all agents that have discovered the class your targeting. If you’re targeting some generic class for this collection rule, like Windows Operating System, now all your agents (except xplat) will have a copy of that MP and will get a new copy of that MP anytime *anything* changes in that MP. That’s a significant config update for something seemingly so harmless and basic.