Recently, I was involved in helping customer to resolve some data issues. There were duplicate data in different CMDB classes populated in the ADDM dataset as well as in the production dataset. The consuming applications were impacted due to inaccurate data in CMDB. While analyzing this, we found that the root cause of duplicate CIs in the production dataset (i.e. the asset dataset) was mainly due to improper reconciliation identification rules. The ADDM reconciliation job was using ADDMIntegrationid as part of identification rule which caused duplicate CIs E.g. there were two identical computer system CIs in the asset dataset with different ADDMIntegrationIds. This is an example of how critical the reconciliation process is to maintaining the quality and accuracy of configuration items in your CMDB.
Before we go further on ADDMIntegrationId use, let’s understand how the ADDMIntegrationID is used by ADDM and CMDB.
The ADDMIntegrationId attribute in CMDB class holds a unique key populated by ADDM as part of CMDB Sync operation. This ADDM specific key helps the CMDB sync operation to decide whether a CI already exists in CMDB before performing the insert or update operation.
Knowing that the ADDMIntegrationid is a unique Key to identify a CI, it’s tempting to use it in reconciliation identification rules. This is the most common mistake seen in CMDB data issues. This attribute has in the past been used as work around in CMDB reconciliation rules for Software Server, Database and Cluster CI classes. But with the fix described in KA411090 and this work around is no longer needed.
For reconciliation identification activity, it is very important to use attribute(s) which can provide CI uniqueness in reconciliation identification rules, and it’s equally important to use discoverable CI attributes. E.g. for computer System, serial number, host name & domain attributes to determine CI uniqueness.
Here are the few rules I follow when investigating issues like this:
1) Make sure you understand why there are errors before implementing changes to RE rules.
2) Avoid using ADDMIntegrationId for strong member CIs e.g. Computer System. If I am tempted to do this, revisit rule 1 above.
3) Using ADDMIntegrationId for weak class members is less risky because they don’t have sufficient information in attributes to identify CIs uniquely e.g. weak member like Processor, Monitor, Product etc. You can learn more about how to investigate data issues here
I hope this helps. Please rate my blog to let us know if it was useful. For more like this, see BMC Remedy Support Blogs