Imagine What would happen if your IT Asset reports reported dozens of extra machines in the data center that didn't exist? Your company might pay tens of thousands of dollars on extra maintenance. Decisions for future software license purchases based on the number of computers in your data center are just as badly affected by having stale data in your CMDB. Or consider all the effort that goes into configuration management on your data center and how important it is the CMDB be accurate for IT processes to work.
Just as meats and vegetables will go bad in your refrigerator, configuration items can go bad in your CMDB. We must discard the rotting CIs in the CMDB and ensure all CIs are fresh and healthy. The reason this is such a serious issue in the CMDB is that it causes your CMDB to be inaccurate. An inaccurate CMDB is the cause for serious problems in an organization's IT processes.
Identifying out-of-date CIs and removing them from the CMDB is just one of several on-going processes the CMDB management team needs to run in order to keep the CMDB as accurate as possible.
Why do Configuration Items go stale?
If a CI of a particular class is stale, this means that CIs exist in the CMDB but it may or may not exist in the data center. What we do know is that whatever process we use to populate CI data in the CMDB has not verified that these configuration items actually exist in the data center for some time. Here are possible reasons why this is the case:
- The device may no longer exist. It may have been taken off the network.
- The device may still be on the network but, due to problematic network connectivity, our automated discovery process cannot connect to the device to re-discover it.
- The device may still be on the network but our automated discovery process may not be able to connect to the device to rediscover it. Maybe our access credentials do not work anymore or there is a problem with a discovery pattern.
- The device may exist on the network and be accessible but our identification process may not be recognizing it uniquely. We might be creating duplicate CIs in the CMDB for this device and so we need to fix our CI identification mechanism and remove the duplicated CIs.
How does ServiceNow measure Stale Data?
In the ServiceNow CMDB (as of Helsinki release), the field "most_recent_discovery (last_discovered)" is used to measure just how stale a CI is. This is governed by rules for the classes of CI in the CI Class Manager.
Where you can click down into the CIs
What do I do with all these Stale CIs?
- In the ServiceNow CMDB, there exists a remediation capability that will allow you to run a script against CIs determined to be stale. The script should either remove stale CIs or at least mark the CIs as non-operational. You can find this under Configurations ® CMDB Remediations. This is where you can configure a Remediation Task that will run a workflow script. The most likely remediation would be to either delete the CI or to set its status to "non-operational". Before running a remediation, the CMDB management team should consider the above reasons why the CI might be stale and evaluate whether or not there is a discovery problem or a network problem before getting rid of that CI.
Here is how to define a CI Remediation Workflow in ServiceNow:
Remediation can run automatically or manually. The advantage of running the workflow automatically is that it will run automatically against a large batch of stale CIs. You wont have to click on each CI individually to remediate. The disadvantage is that there might be CIs that you don't want removed or archived but need to be evaluated. The remediation is an Orchestration workflow.
Here is an example simple remediation workflow to delete the stale records:
The Delete Record is a simple step with JavaScript code as shown here. This is the code to remove the CI:
if the desire is to make the CI non operational rather than remove the CI, the following javascript code can be substituted for the above:
var gr = new GlideRecord ( 'cmdb_ci');
gr.get (current.cmdb_ci);
gr.operational_status = 0;
gr.update();
27 Comments
