Conditions are the second step in the
chain and provide the logical connection between facet properties and
policies. Most of the key policy design decisions are made while
To begin building a new condition, use either the
Management → Policy Management → Conditions context menu and choose New
Condition or Object Explorer Management → Policy Management → Facets →
Database context menu.
You can open an existing condition by
double-clicking the condition or by using the Property command in its
context menu. A condition may have multiple expressions, but each
condition is based on only one facet, so every property in all the
expressions in a condition must belong to the same facet.
Condition expressions use facet properties in boolean expressions that can be evaluated as true or false. The expression consists of a facet property, a comparison operator (such as =, !=, in, not in, like, not like), and a value.
To construct a condition that tests a database's autoshrink property, the expression would use the database facet and the @AutoShrink property, as shown in Figure 4. In this case the full expression is:
Figure 4 This condition includes an expression that tests the Database Facet's @AutoShrink. The condition evaluates as True if @AutoShrink = False.
@AutoShrink = False
Think of condition expressions as
positive statements. Instead of thinking, “No database should be set to
autoshrink,” think “All databases should have autoshrink set to False.”
The ellipsis button under Field and Value opens the Advanced Edit dialog box, as shown in Figure 5.
The Cell value is typically a property, function, or a literal value;
however, it is possible to build more advanced expressions that
reference DMV or system tables.
Use the Advanced Edit dialog to create each side of the expression. In
this case it shows the left side of the AutoShrink expression.
A condition may include multiple expressions, in which case the AndOr column defines how they are evaluated.
In the entire policy design scheme,
the only place that enables multiples is designing multiple expressions
within a single condition. Therefore, if every expression should indeed
be tested, encapsulating multiple expressions in a single condition can
reduce the number of conditions and policies.
The open condition's description page may be used
to record a description of the condition, and the dependent policies
page lists the policies based on the condition. After the condition is
created, it may be enforced by one or more policies. To
programmatically view the created conditions, query the dbo.syspolicy_conditions view in the MSDB database:
select * from msdb.dbo.syspolicy_conditions
To build advanced conditions that check factors other than the built-in facets, look into the executeSQL and executeWMI functions.