What’s causing the new CI to be created (and the retired CI to keep getting updated)

[ShauntaR]

I

I have an issue with the data in the CMDB of ServiceNow. We reuse the hostnames when we are complete a technical refresh on our servers in our environment. We have configured the our identification rule for hardware to check the name and serial number with a priority of 100, then the serial number and serial number type with a priority of 200, next is the serial number with a priority of 300 and lastly, the mac address and name. The reconciliation rule is configured to prioritize ServiceNow at 100, SCCM at 200, and Intune at 300. The windows servers have inherited the independent rules from Hardware Rule that applies to Hardware. When we clicked Discover Now from the retired CI record, it initially created a new record, however, it continued to update the retired record with the new record's information. We noticed that the old record was tagged with SCCM and we moved the tag to the new record. In addition, we changed the serial number, installed status and removed the new serial number from the table on the record. When we ran discovery again, a new record was created instead of updating the existing record. Now we have 3 records in the CMDB: the retired record and 2 new records with the same serial number and hostname. From the information above, please provide a cause that might be the reason a new record is created. In addition, provide specific steps on how to resolve the issue in ServiceNow.

[boteeuwen]

The main cause here looks like IRE matching the retired CI during identification, combined with the manual changes made afterward. Retired CIs can still be considered by IRE unless you explicitly exclude them, so the first Discovery run may have matched the old record by serial number or name and updated it.

After the serial number and other identification values were changed or cleared, the next Discovery run likely found no valid match and created a new CI. The third record was probably created because another source such as SCCM, Intune, or Discovery sent different identification data, for example a different MAC address, missing serial number type, or another value that caused the identification rules to fail.

I would add an Identification Inclusion Rule for the relevant hardware class so retired CIs are excluded from IRE matching. You can configure this from CI Class Manager under the Identification Rule for the Hardware or Windows Server class, using a condition such as Install status is not Retired.

For the existing records, review the IRE identification results first and compare the serial number, serial number type, name, and MAC address across all three CIs. Also check the cmdb_serial_number table for stale or duplicate entries. Once you know which CI is the correct active record, use the Duplicate CI Remediator to clean up the duplicates rather than deleting records manually.

I would also review the MAC address and name fallback rule, especially if SCCM, Intune, and Discovery are reporting different adapters.

If this helped, could you mark it as a solution or helpful?