How to maintain the CMDB in an OrganizationIssue A Configuration Item, or CI, is the fundamental structural management unit of the CMDB and it serves as the basis for the language for effective communication within your IT community. Everything IT supports is ultimately expressed in terms of CIs: incidents are expressed in terms of degraded CI(s), problems are expressed in terms of which CIs are root causes and are impacted, changes are expressed in terms of which CIs are changing or are potentially impact / at risk for a specific change, etc. Thus, the quality of CI data will be an essential tenet of your ability to communicate effectively. As you work to define your CIs, you can initially expect to capture CI data from your current data sources. Most organizations find their current data may or may not be clear, concise, or complete – it is almost always of inconsistent quality. However, at some point during their initial implementation of a CMDB, most organizations decide to load their CMDB with the best data available and embark on an ongoing effort to steadily improve data quality over time. The Configuration Management team should be relentless in challenging the IT organization to improve CI data quality. The configurations are stored in a configuration management database (ServiceNow® CMDB) which consists of entities, called Configuration Items (CI), that are part of your environment. A CI may be: A physical entity, such as a computer or routerA logical entity, such as an instance of a databaseConceptual, such as a Requisition Service In each case, there are attributes about the CI that you want to maintain, and there is control you want to have over the CI. There are changes that may need to be made and tracked against the CI. Also, a CI does not exist on its own. CI's have dependencies and relationship with other CI's. For example, the loss of a bank of disk drives may take a database instance down, which affects the requisition service that the HR department uses to order equipment for new employees. It is this relationship data that makes the CMDB a powerful decision support tool. Understanding the dependencies and other relationships among your CIs can tell you, for example, exactly who and what is affected by the loss of that bank of disk drives. When you find out that a router has failed, you will be able to assess the effect of that outage. When you decide to upgrade the processor in a server, you can tell who or what will be affected during the outage. Organizations now need to regularly monitor CIs and their relationships to identify ongoing problems that can cause inaccuracies in reports. Regular monitoring can alert the CMDB manager of these issues and allow for repair processes to adjust the CMDB data as necessary. Here are examples of some of the problems with CIs that might be detected: • Stale CIs: A CI becomes stale when its existence has not been verified for a determined period of time. This could be one or two weeks for a host or network device. It could be as little as a few days for a network dependency connection. A CI may become stale in the CMDB because it has been physically removed from the network and thus can no longer be found by automated discovery processes. The CI may still exist, but it may be damaged or intentionally taken off the network. In any case, the CMDB manager must investigate the situation with all concerned parties and initiate a fix either to the CMDB or to the hosts on the network. • Duplicate CIs: If the identification rules for CIs do not ensure that each CI is uniquely identified with parameters that do not change, then duplicates of the same CI will appear in the CMDB. This data must be cleaned up and the identification rules and processes modified as necessary in order to ensure that this problem does not occur again. servicenow.com ServiceNow / 12 • Overloaded CIs: An opposite problem of duplicate CIs exists when different CIs are identified as the same CI and one CI is created when several CIs should have been created. This can indicate a problem with the identification rules and processes and must be handled as soon as possible to fix the CI data in the CMDB. • Unidentified/Orphaned CIs: CIs can appear in the CMDB that are not identified. They are seen on the network as an IP Address but no other information is available for them. In addition, these orphan CIs have no relationships with other CIs. This is usually an issue with access rights for automated discovery processes. The discovery process is not able to log into the newly appearing host to identify its existence and to inventory it as required for all the processes established in the CMDB. We can report the health of the CIs using the CMDB Health Dashboard. These jobs are disabled by default. Enable the respective job for the CMDB health metric for which you want data collected and aggregated. You can schedule a job (/sysauto_script_list.do?sysparm_query=nameLIKEhealth) to run on a recurring schedule, or execute it once at any time. Please refer to docs more on this. https://docs.servicenow.com/search?q=cmdb+health