|
What makes the behaviour of the Processing Rule Group
hierarchy sometimes puzzling is that it is not really a
hierarchy. If you have ever tried to Disable a Processing
Rule group expecting all subgroups to 'inherit' that disablement you will
already know that it might seem to work and it might not seem to work. It
depends. So this article tries to straighten out the confusion.
The algorithm for applying the rule depends on:
-
Is it enabled
At the lowest level is Disabling\Enabling the rule. This does what it
says it's going to do and can be relied upon to stop a rule across all machines
where it is implemented. The only possible complication is where two or
more rules share the same name and the wrong one is disabled by mistake.
Examples of these for example exist in the Microsoft Distributed Transaction
Coordinator management pack where pairs of identically named rules deal with
the same event but being generated out of two different message Dlls.
-
Is the Processing Rule to which it belongs Enabled
This is also easy to understand. If the Processing Rule group is
disabled, then none of its rules will apply. There is no hierarchical
effect here. The table relationship is simply between rules and
groups. If the rule is in the disabled group it is also effectively
disabled. If a rule is in an enabled subgroup it itself is enabled, then
it will be implemented. This means that disabling a group does not
disable the rules of any sub groups.
-
Is the Processing Rule to which it belongs associated with this computer
(and is it enabled)
This is more difficult to understand because Mom handles computer group
associations with some degrees of inheritance. In other words if you
associate the Windows 2000 Domain Controllers computer group with the top most
node in (for example) the Microsoft Windows 2000 Operating System Management
Pack, all the rules throughout the hierarchy will be applied to these
computers. Cursory examination of this management Pack shows that
internally it is divided into All Computers, Domain Controllers, Dr Watson,
Servers etc etc. so that applying DC's to the root node would be a
mistake. However the principle is sound. Computer group association
is 'inherited' within a processing rule group hierarchy. This mans that
lower down the hierarchy a processing rule group may show no computer group
associations in its properties but nevertheless the association has been
implemented at a higher level.
For Example:
Imagine a simple group hierarchy of three levels.
|
Processing Rule Group 1(Associated with Computer Group 1
Rule1
Processing
Rule Group 2 (Not Associated with any Computers)
Rule 2
Processing
Rule Group 3 (Associated with Computer Group 3)
Rule
3
|
-
A computer that belongs to computer group 1 would have Rule1, Rule2 and Rule3
implemented even though it does not specifically have any association with
Processing Groups 2 and 3. This is because the computer association
appears to be 'inherited'
-
A computer that belongs only to Computer Group 3 would only receive Rule 3
-
If you disabled Processing Rule Group 2 then a computer that belonged to
Computer Group 1 would only receive Rule1. The Computer Association
inheritance has been stopped at the level 2 node. The Computer Group 3
members continue to implement Rule 3.
It's not hard to see that AD HOC administrator editing of Processing Rule Group
hierarchies would lead to a completely chaotic situation where it would be very
difficult to tell what rules were being applied where. Stringent control
and documentation maybe called for! The Dump Rules series of scripts were
intended to help this situation.
DumpMomKb
DumpMomRules
DumpMomRulesForComputer
|