Need help in CMDB Maintanance

[Priya Singh9]

Hi All,

I do see the duplicate CIs when I checked the CMDB health dashboard. And also the completeness and correctness score is not 100%, we are getting the data into cmdb tables from multiple sources. Can anyone please help me on how to fix those issues.

[Dr Atul G- LNG]

Hi @Priya Singh9 

I am not expert here but stil i can say

- Review IRE rules

- Check the different sources and their pattern to find out the cause of half cooked data.

- Set up the half yearly audit.

- Set up a process to update data in cmdb.

Adding @AJ-TechTrek who can provide more inputs.

[Ashok Sasidhara]

To reduce the possibility of creation of duplicate CIs, review the identification rules for each of your CI classes and modify as needed. I have explained this topic in detail in the following article:

https://servicenowguru.com/cmdb/servicenow-cmdb-identification-and-reconciliation-engine-ire/

For already existing duplicate CIs, process deduplication tasks. Also if any wrongly populated duplicate CIs are identified which does not have any reference in incidents, problems, changes etc., you can even consider deleting them. Otherwise CIs should never be deleted and should only be archived or retired.

Also in the following articles, I have explained some data management best practises to improve CMDB data quality:

https://medium.com/@ashoksasidharan/best-practices-for-cmdb-data-management-in-servicenow-9cb6ae18eb...

[Priya Singh9]

Hi Ashok,

Thanks for the response, we were using OOB identification rules and we have many integrations in place like SCCM, apart from discovery to load the data into CMDB.

[Kris Moncada]

This sounds like an instance I was once administering, where by the CMDB was being populated by SCCM, Discovery, Qualsys, and home grown solution (leveraging php).  The problem in my cause was the home grown solution, where by the developer was querying the CMDB API to see if the CI existed, then if not, it would create CI.  I forget the particular details about the problem, but I knew the query part response took longer, because it was creating duplicates; thus a snowball effect. 

In a lower environment:

1. Address the duplicates by deleting the CIs that do not have relationships with other incidents, problems, etc.
2. Disable all integrations enabling them one by one to see which process is creating duplicate CIs. 
3. Address the problematic integration by looking into how that integration determines if a new CI needs to be created or not.