Serial Number changing on CI records, causing duplicate records

[Donna Olsen]

Our CMDB is using both Discovery and SCCM-SG for populating CIs.  Recently we started noticing few duplicates coming across our remediation duplicate tasks.  As we researched we noticed that SCCM is changing the SN fields as well as Discovery.  We have our identification rules to match on Serial Number Type and Serial Number, first and foremost so unsure of why any data source would update the SN field.  Is there a way to prevent these sources from updating the SN?  I threw a screenshot of what SCCM is doing daily.  Not all of our records are doing this, but enough to cause confusion  impacting field support operations.

[Maik Skoddow]

Hi @Donna Olsen 

this is a complex topic and no simple answer is possible. It would require access to your instance to assess all configurations.

At the moment, I only can provide you a good article with some remediation tips: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0869861 

Maik

[ersureshbe]

Hi,

1. You should check the Class manager and review the unique id config to understand the CI create/update.

2. Identify the same serial number exists before run the discovery

It's a big clean up work. You should get complete inventory list to review the CIs and configure the correct identifiers to manage the CI flows. If any integration exist to manage the CI life cycle,  you should define coalese for that attrbute and manage it properly.

[ptishberg-bcbst]

Hi Donna,

That was happening to our Windows Servers where both SCCM and SN Discovery was finding the server and rather than updating the SCCM (primary, highest priority- lowest number value) in our identification rules, it was in fact creating a new CI despite our reconciliation rules about only updating the 8 fields we identified that we wanted the SN Discovery of Windows servers to update the record. 

We identified those 8 fields by looking at CMDB 360 data (used for multiple sources of data being run through the IRE and determined how values were flipping based on fields in the cmdb360 view by the column of which source was changing the data.

Hope that this helps to start your troubleshooting to make the right choices on which data source has priority and which fields are updated and by what source.

[Ashok Sasidhara]

You need to review both the identification & reconciliation rules for the affected CI classes. Then refine those rules as required after finding the root cause. Following URL has more information on this topic:

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1064718