CMDB Data Manager is a policy-driven framework for bulk management of CI life cycle operations such as deletion, archival, and attestation. The CMDB Data Manager is a comprehensive and integrated solution, which scales to large CMDBs and copes with rapid changes in a cloud-based world.

Large CMDBs can over time accumulate large amounts of stale CIs that can impact overall performance. Custom mitigating solutions can be difficult to develop and to maintain, and are also prone to errors. The CMDB Data Manager is the tool where you can create, publish, and manage policies. Create policies to automate and govern CI life cycle operations to help maintain the CMDB in a healthy and efficient operational state.

Use the CMDB Data Manager to create policies that represent your organizational processes for managing the life cycle of CIs such as:
  • Retire all computers without owners, which were created more than a year ago ('Retire' policy type).
  • Archive all Linux servers in the Seattle datacenter which haven't been updated for six months ('Archive' policy type).
  • Delete all containers, which haven't been discovered in the past week ('Delete' policy type).
  • Attest all the CIs in a specified location (Attestation policy type).
  • Approve cascade-delete, archive, or retire life cycle tasks generated by dependent CI management.
  • Delete orphan, stale, or irrelevant records in non-CMDB related tables. The non-CMDB Related tables in the Related Entry [cmdb_related_entry] table have references to CMDB tables. A CI in a related table can, for example, become orphan if the referenced CI in the CMDB is deleted ('Delete CMDB Related Entry' policy type).
  • Certify that attributes have a specific value required for the business.

You can apply CMDB Data Manager policies only to classes that extend the Configuration Item [cmdb_ci] table. Therefore, you can't use the CMDB Data Manager to manage classes such as those that were imported by CMDB CI Class Models.

CMDB Data Manager experience in CMDB Workspace

You can use the CMDB Workspace landing page and its views to fully administer CMDB Data Manager, access high-level analytic and counts for its policies and tasks, and review your tasks. For information about using the CMDB Data Manager in CMDB Workspace, see CMDB Data Manager experience in CMDB Workspace.

CMDB Data Manager on Core UI (UI 16)

Starting with the Washington DC release, CMDB Data Manager on Core UI (UI 16) is being prepared for future deprecation. It will be hidden and no longer activated on new instances but will continue to be supported. CMDB Workspace provides the latest experience for this functionality.

CMDB Data Manager built on Core UI (UI 16) is available by navigating to All > Configuration > CMDB Data Manager. For information about using the CMDB Data Manager legacy build on Core UI, see CMDB Data Manager on Core UI (UI 16).

Terms

Policy

A CMDB Data Manager policy captures the overall management plan for a life-cycle event, such as CI retirement. A policy is associated with a subflow (the policy subflow) which creates the tasks (the policy tasks) for the target CIs of the policy. A policy is configured with a policy type and the policy tasks perform operations associated with that policy type, such as archiving or deleting a CI record. Also, you can configure a policy to require an approval.

The policy type, policy subflow, and the policy tasks, are all aligned to a specific life cycle event of CIs. For example, a policy set with the delete policy type, is associated with the delete subflow, and its policy tasks handle the deletion of CIs.

A daily scheduled job processes all published CMDB Data Manager policies.

Policy subflow

The policy subflow contains the underlying logic to process a life cycle event such as retire or delete. If the policy is configured to require approval, then the policy subflow runs only after a policy task is approved.

The base system provides several common subflows, such as delete, archive, and retire, which you can use with policies. You can also create custom subflows that are needed in the organization.

Policy task

A separate task is created and assigned to each unique Managed By Group value within the set of target CIs in a policy. A policy task triggers the policy subflow, tracks the set of target CIs for the task, and handles the approval of the task, if necessary.

If a policy requires an approval, the policy tasks don’t trigger the policy subflow until a member of the group assignment in the Managed by Group attribute of the target CIs, approves the tasks. If a task is rejected or if the Managed by Group attribute is empty, the task is assigned to an administrator who must manually intervene to resolve the task.

If a policy isn't configured to require an approval, then the policy tasks are automatically approved.

CI exclusion list
A set of CIs to which policies of a specified type don't apply.

Policy types

You can create policies of the following types:
Delete
Use to remove a CI from its current table with no option to restore the CI into an active state.
Retire
Use to retire a CI while keeping the CI active in list views and in processes such as CMDB Health.
Attestation
Use to assign and process attestation tasks that verify the existence of actual IT infrastructure and applications that you own. As CIs are continuously ingested into the CMDB from various data sources, attesting CIs support the integrity of the CMDB. For more information about using the Attestation policy type, see CIs attestation.
Archive
Use to remove a CI from its current table and store the CI in a separate archive table for temporary retention. Archiving a CI excludes the CI from views and from features such as maps and the relations formatter. During the retention period, you can restore CIs into active state. At the end of the retention period, archived CIs are deleted from their archive table.
Delete CMDB Related Entry

Use to clean up any irrelevant or stale data from related tables to help keep CMDB data healthy and relevant as the state of referenced CIs change.

Related tables, such as the Serial Number [cmdb_serial_number] table, aren't part of the CMDB hierarchy but still qualify as CMDB data. Related tables don't inherent from the Configuration Item [cmdb_ci] table, but have at least one column that references a CMDB CI. Related tables are specified in the Related Entries [cmdb_related_entry] table.

Certification
Use to certify that specific attributes are of a specific value.

You can implement your Retire, Delete, and Archive policies so that they follow Common Service Data Model (CSDM) standards where for example, CIs are archived and deleted only when a CI is already in retired state. When you create these life cycle policies, the system applies processes to manage any dependent CIs that might be left behind. For more details about these processes and about verifying that the feature is enabled, see Dependent CIs management.

Now Platform® data archiving

The functionality that the Archive policy type in CMDB Data Manager provides, relies and extends the Now Platform® data archiving feature, applied specifically for CMDB CIs. While processing an Archive policy to archive CMDB CIs, CMDB Data Manager uses components and processes of Now Platform® data archiving in the following ways:
  • The Archive Rule [sys_archive] table contains the Now Platform® archive rules including the Archive Configuration Items CMDB archive rule which CMDB Data Manager Archive policies use.
  • Data Manager relies on the Archive scheduled job to run (every hour by default) and process CMDB Data Manager archive policies. The Archive scheduled job is stored in the Schedule Item [sys_trigger] table.
  • In the Now Platform® table Archive Job Execution Chunks [sys_archive_run_chunk], the Keys attribute contains the sys_ids of the CMDB CIs to be archived (where Rule ID is the CMDB archive rule ID).

  • Archived records are stored in the Now Platform® archive tables, which are prefixed by 'ar_'. In a similar way, the first time that a CMDB archive job runs, it creates an archive table for each CMDB class (prefixed by 'ar_cmdb'). Therefore, that initial CMDB archive task takes longer than subsequent CMDB archive tasks.

    For each Data Manager archive policy, the system batches the policy CIs to be archived into batches of 1000 CIs. The sys_archive_run_chunk table contains a record per each of those batches.

    CMDB archive tables, such as ar_cmdb_ci_computer, are listed under All > System Archiving > Archive Tables.

When using the CMDB Data Manager to archive CIs, you can also directly apply Now Platform® data archiving features, such as restoring archived records during a CIs retention period.

Life cycle state rules and retirement definitions

Life-cycle state rules define the retirement state for classes in your organization and support the transition of CIs through life cycle stages when using the CMDB Data Manager. After retiring CIs, CMDB Data Manager configures the retired CIs according to the retirement definitions specified by life-cycle rules for the CIs class. Using a Retire, Archive, or Delete CMDB Data Manager policies requires that an active life-cycle rule exist for each targeted class in the policy. You can activate life-cycle rules in the base system to apply the default definitions, customize those rules, or add life-cycle rules for classes needed in your organization.

The life cycle state of a CI affects the CIs visibility and inclusion in ongoing CMDB processes:
  • A retired CI isn't excluded from any views or processes such as CMDB Health.
  • An archived CI no longer exists in its active table and instead it's stored in a separate archive table. Archived CIs are no longer visible or included in processes such as list views, maps, and relations formatters. Archived CIs can be retained for a specified retention period before being deleted from the archive table. During that retention period, archived CIs can be manually restored into an active state by using the Now Platform® feature to restore archived records.
  • A deleted CI no longer exists in the table that it belonged to and there's no way to restore it into an active state. Deleting a CI is an irreversible operation.

For more information about accessing and managing life-cycle rules, see Life-cycle rules and retirement definitions.

Configure the environment for CMDB Data Manager

Prepare your environment for using the CMDB Data Manager:
  1. Some policy types such as the life cycle policies Retire, Archive, and Delete, require that an active life cycle rule exists for each targeted class in the policy. This requirement doesn't apply to all policy types. For example, this requirement doesn't apply to the Attestation policy type. If you attempt to create a policy of a policy type for which this requirement applies but isn't met, an error message appears and the operation fails.
  2. You can streamline approval of policies by populating the Manage by Group attribute of CIs that you plan to target in policies. Use the CI Class Manager to populate that attribute for an entire class, in a single synchronization operation. For more information about this data synchronization, see Set the group for a CI or an entire class of CIs. If the Managed by Group attribute isn't populated for a CI, then the approval process is directed to the administrator.