Targeting Rules and Monitors
The concept of what target to use for a particular rule or monitor in OpsMgr 2007 seems to be one that people are struggling with. The confusion is most prevelant among people who have had experience with MOM 2005 since the methods have completely in changed. In MOM 2005, you would apply rule groups to computer groups. If a computer was in the group, it would get the rule - it was that simple. In OpsMgr 2007, we do not use groups to target rules/monitors. What adds to the confusion though is that groups are available in the list of targets when creating a rule/monitor in the console. Let's see if I can explain this.
The main conceptual difference between MOM 2005 and OpsMgr 2007 in this respect is that in MOM 2005 we thought about which computer we would retrieve a particular piece of information from, and we targeted rules at groups containing those computers. We had to think about the individual agents and view the environment in terms of the physical computers being managed. We had formulas for the groups to identify which computers held different components, but we were ultimately targeting groups of agents. In OpsMgr 2007, we think about what component is generating the information. That’s a distinctly different concept and ultimately more powerful. OpsMgr will figure out which agents hold instances of that component, deliver the rule/monitor to the appropriate agents, and execute the rule/monitor for each instance.
In 2007, we also work against multiple instances of a class on a particular agent. In MOM 2005, we only had a single rule sent to the agent, and that rule had to do the enumeration. A good example is SQL databases. The SQL scripts in MOM 2005 were enormous because they had to enumerate the whole list of databases and other SQL objects every single time they executed. In 2007, we just apply those rules to the SQL Database class, and OpsMgr executes the rule for each database instance discovered.
How does a rule get to an agent?
For any particular rule/monitor, OpsMgr will enumerate all instances of the target class and apply the rule to each. If there are no instances of the target class on a particular agent, then the rule will do nothing. It's that simple.
If I can't target groups, why are they listed when I select a target for a rule?
Groups are classes just like any other. They’re singleton classes where the class and the instance are one and the same, but they are classes nonetheless which is why they show up in the list with all other classes. There are really very few circumstances where you will target a rule at a group though .
What if I do target a group?
You can apply a rule/monitor directly to a group, but it will execute against the group object itself. OpsMgr will not enumerate members of the group and apply the rule to each. Any rules targeted at groups will actually operate on the Root Management Server since groups have no host and unhosted objects are managed by the RMS.
How do I target some group of objects then?
To the specific question of how to get a particular rule/monitor to a subset of components, you have two basic options. Let’s say for example, you have a particular subset of web sites that you need a particular rule to apply. You could target that rule at the IIS 2003 Web Site class for example, but that would apply the rule to all instances of that class. It would probably apply to sites that you didn’t want.
Option 1 would be to create a new class and target the rule at the class. In the case of an IIS site, this would mean that you would need to go to the Authoring Console or raw XML and create a new class and discovery. That’s a more advanced solution that most customers will do and probably overkill anyway.
Option 2 is the create a rule target at the whole class and disable it. Create a group with the sites you want and create an override for that group to enable your rule. This might sound like a workaround, but it's a completely valid solution.
How do I know if I'm selecting the right target?
The easiest method to validate you are using a target that actually has instances is to use the Discovered Inventory view in the Operations Console prior to creating your rule/monitor. In the Actions pane is an option called "Change target type..." that will bring up the same Select a Target Type dialog box that you see when you select the target for a rule/monitor. This view will list all instances of the target class you select. You can validate which agents have an instance of that class and how many instances each has. If there are no instances listed, then the rule isn't going to do anything. If there are instances, then you not only be confident that the rule/monitor will execute on the agent, but you can also view the properties of the instance that will be accessible to any rules/monitors targeted at it.
Comments
- Anonymous
January 01, 2003
I was given a challenge recently to come up with a solution for an organization that wanted to suppress