Active CIs Updated in Last 90 days

This play lists the methods you can use to refresh the stale CIs.  Choose one of five methods (described below), based on the output of your analysis using the CMDB Data Foundations Dashboard “Active CIs Not Updated in 90 Days” metric. 

1. Review the detailed records associated with the historical graph widget for the “Active CIs Not Updated in 90 Days”.  

Important:   Careful review helps you identify the root causes, which then helps you decide which refresh method to use.  If you have more than one root cause, you need to address all of them. 

Refresh the category with the largest number of stale CIs first, or refresh the stale CIs in your most important CI classes.  

2. Choose the method you want to use, based on the root cause. 

The table below lists the root cause and the corresponding method to choose. 

Method A: Root cause  — Discovery does not refresh the CIs 

1. Work with your Discovery Administrator to refresh this data and fix the root cause.  Examine one CI class at a time. 

1. 1. Verify that the Discovery schedules are active and are completing successfully. 

1. 2. Check for any Discovery errors, such as problems with credentials, or firewalls. 

1. 3. If you are using custom patterns, see if they are set to update the Last Updated timestamp. 

2. (Optional) Consider using a business rule that retires CIs that are not discovered. 

3. Review the IP exclusion ranges. 
   Note:  If the CI is no longer in the system, consider the answers to these questions: 

• • Is your asset-decommissioning process updating the CMDB when appropriate? 

• • Have you set up a deletion strategy for the related CI classes? 

Method B: Root cause  — Third party applications are not refreshing the CIs 

1. Contact the third-party application owner and review how the data is sent to the CMDB.  

2. Ask the following questions: 
    

1. 1. How are they managing the lifecycle of a CI and how are those updates sent to ServiceNow? 

1. 2. Are only the deltas sent over periodically? 

3. Was the data sent as a one-time only activity? Can it be set up to happen more frequently? 

4. Can a "refresh" job be performed? 

3. Check if the third-party application supports passing the data though the Identification and Reconciliation Engine (IRE). 

4. (Optional) Consider using Discovery as a validation mechanism for your CIs. 
    

Method C: Root cause  — ImportSets are not updating the CIs 

CIs that have been manually imported but are now stale may fall into one of two categories.  

The first is that the CIs may be hardware that really should be discovered automatically. If this is the case, consider identifying if Discovery or another discovery tool that is already in use at your company can instead be used to discover the CIs. This is ideal as state of CIs may change, and automated tools often are able to discover more attributes than whatever was in a manually populated data set. 

The second is that the CIs may be legacy hardware that cannot easily be discovered. For example, some customers have a handful of mainframe computers that are still operational and need to be tracked in the CMDB.  

In the out of the box Data Foundations Dashboards all hardware CIs are included in the score calculation, so the stale legacy CIs will be included. These typically make up a small portion of an organization’s overall hardware footprint. You may however consider excluding these classes from detailed analysis described earlier in this playbook. 
 
When setting up Data Manager policies for retiring CIs, specific classes can be excluded. In this case those legacy classes (e.g., mainframes), should be excluded from Retirement policies. More information on using Data Manager is in the Data Governance Play section of this KB. 
 

Method D: Root cause  — Manually entered CIs are not being updated 

1. Confirm that the CI has not been updated recently.  

2. If you know who manually entered the CI, find out why.  

3. See if there's a way to automate adding the CIs, or see if there's a way to certify periodically any records entered manually. 
     

Method E:  Root cause — Stale CIs are remnants of the legacy CMDB records 

1. Are the legacy records still valid?  Use Data Manager to mark them as retired or non-operational, and/or consider archiving them.  

2. For information on archiving the records, see the Governance Play. 
    

Step 2: Review Retirement Definitions and adjust as needed. 

Review the default Retirement Definitions within Data Manager. Retirement Definitions serve two purposes.  

First, they allow you to specify what lifecycle fields on a CI are set, and to what values, when Data Manager policies ‘retire’ a CI.  

Second, the definitions are used when an Archive policy is looking for ‘retired’ records. It will select all records that match the active Retirement Definitions. 

Update your Retirement Definitions as needed for your environment and lifecycle management processes. Note that out of box only the root cmdb_ci Retirement Definition is ‘Active’. All other Definitions are inactive unless set otherwise.  

In the out of box example above, when a Retirement Policy is triggered on a CI, it will set the Life Cycle Stage to End of Life and the Life Cycle Stage Status to Retired, in accordance with the Retirement Definition above. In addition, when an Archive Policy is run, it will Archive any CIs that meet the Retirement Definition (Life Cycle Stage is End of Life and Life Cycle Stage Status is Retired). 

A Retirement Definition at a more granular level overrides any retirement definitions higher up in the hierarchy. 

Step 3: Create your Retirement Policy 

A Retirement policy will Retire (set fields identified by your Retirement Definitions) CIs that match the filter criteria you set in the policy. 

Typically, you should retire CIs that have not had been updated (Updated / sys_updated_on field) for more than 60 days, and that are currently in an operational state. 

Refer to ServiceNow docs for full details on creating a Retirement policy. In general you will: 

1. From Data Manager, select Policies and then Create New Policy  
    

2. Fill out the general information for the policy and select type Retire 
    

3. Set the policy filter to identify the criteria for CIs to retire. Two key fields to set are: 
    

1. 1. “Updated” which should be greater than 60 or 90 days depending on your discovery cycle. If your hardware and CM instance CIs are discovered on a daily basis, then 60 days is more than enough time. If a hardware or VM instance has not been seen for 60 days, it should be Retired.    
       

1. 2. Life cycle fields. You should only look to Retire ‘Operational’ records. For example, the CI is “In maintenance” we do not want to set to Retired even if it has not been discovered for more than 60 days. 
       
      “Operational status” is a common (legacy) field that is used, so you would set a filter condition to check if this status is Operational. Alternatively if you are using Life Cycle Stage and Lifecycle Stage Status, set the filter to check these fields. 
       
      A sample policy: 
       
       
       

4. Select which User or Group (either specifically named, or a field associated to the CI such as “Managed By Group”) should get assigned.  
    
   Note: in the next step you denote whether the CIs need Approval before being retired. If you will not require approval, it does not matter what you set in this step. 
    

5. Choose the subflow (there should be only one choice: Retire Configuration Items), and whether Approval is required. 
    
   Note: CIs to be retired are grouped into Tasks. Each task may have up to 10,000 records, and each task will also group CIs together with one approver. So if you had 50,000 CIs that all had the same Approver, that Approver would receive 5 tasks.  
    

6. Click through the final Scheduling notification and Review. Finally if things look good, Publish the policy.