Targeting a computer group in Operations Manager 2007 produces unexpected results because the computer group target (that is, the class of objects that are computer groups), only exists on the root Management Server. Therefore, any rule that you target to this object class attempts to collect event information from the root Management Server. In some cases, the root Management Server might not have the instrumentation that the rule depends on. For example, a rule that depends on IIS metrics will not be able to collect any information on a root Management Server that has no IIS server on the computer. In other cases, you might collect information that is not what you expect because the rule is intended to collect data on a machine other than the root Management Server.
The only way to send rules to specific computers is to target the rule to an object that exists on the computer, such as a SQL Server object or an IIS Web site object. You can then use overrides to specify the places where the rule works.
For example, consider the scenario where you want to target a rule to all Windows Server 2003 servers that are in a particular computer group. To do this, complete the following steps:
1. Create a rule that is targeted to the Windows Server 2003 class.
2. Set the rule so it is not enabled by default.
3. Create an override that will enable the rule only for objects that are members of the desired group.
Two good bits on targeting in Operations Manager 2007. Part one is about the differences between MOM
The only thing that i am really missing is a wizard to add classes. The detection rules only seem to work for object properties. The only way I can currently create classes is through custom XML mp's that I fill in with the GUI. This would also stop the need to target groups.
Will this ever come?
One issue we still seem to see a lot of confusion about is the way that you use System Center Operations
So basically, SCOM 2007 is data type driven from the ground up and attempting to use a non-data type organization is considered arbitrary and does not function predictablly. So either use one of Microsoft's sealed management pack classes or whip open the authoring console.
I see the strength in a data-type approach and this approach is good for Microsoft applications. It is not necessarily good for benign 3rd party applications. The assumption we are making with a data-type driven system is that there is always a piece of discoverable data that defines the organization of rules and monitors.
My customers resist this because it forces them to dig down and discover their own environment to make these kinds of data-type driven classes. And a lot of time they do not know what seperates a 3rd party application A server from a 3rd party application B server. And to make matters worse the tools are not that friendly or stable for seamlessly creating classes.
Why this need to create classes from discovery infomration?
Because for my customers it impacts the subscription notification process. If all my notifications could be divided up neatly (especially for non-Microsoft application) and sent to the correct teams exclusively based on the existing classes in SCOM 2007 MPs that would be great.
Life is not that simple and this is where a better GUI interface with more options in subscription creation would have been greatly appreciated.