Policies Overview

A policy enables you to define the expected configuration of a view. By applying policies to your managed views, you set standards for the views. The policies help to ensure that the views adhere to the standards and make your IT environment more predictable.

The Policies module controls the policy groups and policies you define for the managed views. There are three types of policies you can define:

• Baseline policies

  In a baseline policy, you define a baseline for a composite CI with selected attributes to be compared to the CIs of the relevant views. For instance, you could define a baseline policy stating that every production server in the view must contain at least two CPUs. All server CIs in the view are compared to the baseline CI. If any one does not satisfy the policy, the view is said to be in breach of the policy.

  Note If you identify an existing CI in your environment with the desired configuration, you can select that CI to serve as the baseline.

  Detailed information about the CIs in baseline policies can be seen in the Explore Views, Review/Authorize changes, Changes History, and Authorization History modules.

• Topology policies

  In a topology policy, you define a condition TQL query that determines the configuration of the view. For instance, the condition TQL could stipulate that every cluster of a production J2EE include at least two servers. If the view satisfies this condition, it satisfies the topology policy. If it does not, it is said to be in breach of the policy.

  In some cases, it is easier to define a TQL query representing a problematic topology rather than the desired configuration. In that event, there is an option to set the condition of the topology policy as negative, which inverts the satisfaction of the policy (in the above example, only clusters with less than two servers would satisfy the condition).

  You are not able to view detailed information about the CIs in topology policies.

• Similarity policies

  In a similarity policy, you select CIs and attributes that enforce similarity between either all CIs of a certain type in a view, or groups of CIs in a view (where each group is connected to a defined CIT). For instance, you could define a similarity policy stating that all UNIX machines in a lab, which are connected to an Oracle database, must have the same OS version. Another example is to specify that all servers in each cluster are running the same application version.

  A similarity policy is not static (it has neither a fixed number of components nor set attribute values, unlike a baseline policy). You choose attributes and/or components without specifying any value. The policy calculation compares the current values or components among all of the compared CIs (or the CIs in each group, if grouping has been selected), and decides the policy status accordingly - either all of the compared CIs satisfy the policy, or they all breach the policy.

  Detailed information about the CIs in similarity policies can be seen in the Explore Views (on the latest snapshot only) and Review/Authorize changes modules.

In all three types of policies, you can also define the following settings:

• Validity. Set the time period for which the policy is valid

• Filter. Limit the policy to a subset of CIs in the view. For example, if the baseline CI is of type Oracle, the filter could limit it to Oracle version 9.

All three types of policies can be applied to all of the managed views in Configuration Manager.

In addition, UCMDB provides, out of the box, a group of out-of-the-box policies to be used in Configuration Manager. For details, see Policies.

Related Information