Previous Topic: Configuration Audit and Control Facility (CACF)

Next Topic: How Change Analysts Define Change Specifications

More information:

How Change Analysts Define Change Specifications

Change Verification

How Change Managers Use Change Specifications

How Configuration Audit and Control Facility Works

CACF Administration and Policy Definition

The CMDB Administrator defines CIs and attributes which are managed as well as the policy for updating those CIs and attributes. You administer the CACF components in the Configuration Control node in the CA CMDB section of the Administration tab and define and view CACF change specifications from the Change Order, CI, Incident forms, or the Configuration Audit node in the Administration tab.

The administrator must consider allowing standard changes, defining authoritative and trusted sources of data, as well as defining which CIs and CI attributes are under CACF management. If an incorrectly executed change or rogue change occurs (also referred to as a variance), CA SDM can accept the new value, create an Incident, or copy the data to the TWA for later processing. CA SDM can use any combination of these actions.

Important! The Configuration Administrator must establish a change verification strategy for your environment. The default policy for CACF allows all changes to all CIs, even if the change is rogue, or if the change does not match a change ticket.

You can implement change verification policies dynamically or scheduled in advance. You can define these policies as generic or highly specific. The change verification policy describes how CA SDM responds to the following events:

Updates from Unauthorized MDRs

Indicates that specific MDRs are authoritative for specific attributes. CI attribute updates from unauthorized MDRs can be selectively accepted or rejected.

For example, define policies to prevent [assign the value for acm in your book] from updating the IP address of a CI, even if a matching Change Order exists. Allow updates to the IP address to occur only if the source MDR is Spectrum.

Rogue Changes

Detects and manages updates to CIs when no corresponding Change Order exists. Specify a policy that manages rogue changes requesting inserts or updates of CI data.

For example, define a policy whenever a CI named like server* in New York changes, but does not have a matching Change Order, do not update the CI but instead load the data to the TWA.

Incorrectly executed changes

Detects whenever a Change Order is not implemented correctly.

Auditing facilities provide the Configuration Manager with capabilities to view changes to policies and CACF object definitions. CACF logs each attempted update to the CI, whether or not the update was allowed. This log helps you determine which policy allowed or disallowed a change to a CI.

The Configuration Administrator defines which Change Order statuses represent editable changes, and which Change Order change states represent verification states. By default, you can edit change specifications when the Change Order is in the RFC change state, and change verification occurs when a Change Order is in the Verification in Progress state. Optionally, change tickets can be automatically promoted or closed when all associated change specifications execute successfully.

Important! Possible performance degradation can occur if the Configuration Administrator enables the Create Incident option with more than one active verification policy.

Note: By default, CACF considers updates to attribute values to Change Orders with change verification active as non-rogue changes which is in effect in the Verification in Progress status. The Configuration Administrator can modify this behavior.