If you look at the Rule creation screen in the DCM Authoring tool, you will see that the DCM UI tool lets you to create two types of rules. They are the Active Rule or the Passive Rule. Now what’s the difference between these two, how can they be used and in what scenario would you use these different kinds of rules?
Well, not knowing the difference between Active and Passive rules, you cannot appreciate the true potential of the Desired Configuration Monitoring (DCM) Solution. Hence let’s figure out what these rule types are…
A Passive Rule
A Passive rule is meant to retrieve a value from a specified data source / setting pair. It would not evaluate to a Boolean value. A Passive rule is not meant to do a compliance check. Hence, if you look at the rule screen, the moment you select the passive rule radio button, a bunch of properties including Event Description, Event ID and Severity disappear. They disappear because Passive rules are not meant to perform compliance checks. Providing the information for Event logging wouldn’t make sense when a compliance check is not done! Passive rules can be referenced to, while creating more complex rules.
An Active Rule
An Active rule is meant to do the real compliance check. An active rule will always evaluate to a Boolean value (true or false). If an active rule evaluates to true, it would generate an out of compliance. However, if an active rule evaluates to false, then it would not generate an out of compliance. Whenever a rule evaluates to true, it would log the Event logging information you supplied for the rule to the NT Event Log and the WMI Repository. While creating an active rule, you can refer to an already-created passive rule. We call this feature rule-referencing. J
By the way, when I say rule evaluation, I mean to the Query Expression of the rule being evaluated.
Having said this, let’s look at some examples to make our point clear!
- SettingName != “The Real Value”
- “Some value”
- count(SettingName) > 57
In the above collection of Query Expressions,
#1 -> Is an example of an active rule. Because I am trying to check for the value of the SettingName to be “The Real Value”. If they are not equal, the query expression would evaluate to true.
#2 -> Is an example of a passive rule. Because all I am doing here is assigning some string value to the query expression. This does not evaluate to a Boolean value.
#3 -> Again a passive rule. Am assigning 007 to the query expression.
#4 -> An active rule. I am trying to check if the count of instances of a Setting is greater than 57.
#5 -> This is a passive rule. Here I am assigning the value of $Rule1 to the query expression. So what is $Rule1. $Rule1 represents a predefined rule which was created earlier in the same manifest (configuration file).
#6 -> Again a passive rule. The concat function takes 3 parameters as inputs and concat them together and returns the concatenated value. Here if you see, the first parameter to the concat function is $Rule1. That means I have created a rule with the name Rule1 earlier in the manifest and I am using the value of Rule1 in the query expression for this rule. This is an example of rule referencing which I was talking about earlier.
Generally, you would create passive rules to get the values of some settings from some data source. Once the value of a setting in a data source is retrieved, it can be used in another rule (active or passive) for rule referencing. This is not a scenario that would occur often but in case if it does, you have the potential to reach such complexities with the DCM Solution. And you would generally create active rules to check for compliance. You can refer to other already-created passive rules while creating an active rule. A classic example is that of a rule with its query expression containing the count function. Example: count($Rule1) = “2”. This means if the count of the number of instances returned by the rule Rule1 is 2, it would evaluate to true. Else it would evaluate to false.
Just imagine a scenario, where you would need to go to the registry, get some value, now go to the WMI based on the value you got from the registry, get the value and then do compliance check on the value you retrieved from the WMI! You would need to use rule referencing and nested data sources in this scenario. Watch out for a new posting with respect to nested data sources!!!
I hope this makes it clear when to create a passive rule and when to create an active rule. Have further questions? Post a comment or contact me…