- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We've got an IRE behavior causing real data quality problems and I'm hoping someone's cracked this already.
The scenario: Infrastructure teams refresh a device and keep the same hostname, though it is new hardware. They retire the old CI, we run Discovery on the new box. Different serial number, so IRE correctly gets no serial match. But then it falls through to name matching, finds the retired CI, reactivates it, and overwrites the serial number. No new CI created. The transition never happened as far as the CMDB is concerned.
I get why the Name fallback exists - serial numbers are unreliable enough that a name match probably does mean "same device, bad serial data" in most cases. But during a hardware refresh, same name + different serial means definitely a different device. The fallback is working against us.
Our current best idea: Add operational_status!=6 as a condition on the name-based identifier entry, so retired CIs can't be matched against. Simple, no process change required from the infra teams.
The problem with that: Our Discovery Admin raised a valid concern - what about CIs that were accidentally retired while the device was still live? With this condition in place, Discovery would just create a duplicate instead of correcting the mistake. We'd have two CIs for the same device with no obvious flag.
What we'd actually prefer is something more like an alert - flag the situation for human review rather than silently blocking or silently resurrecting. Better to catch the problem before the damage is done than discover it later in an audit.
Has anyone implemented something like that? Or found a cleaner solution to the refresh problem altogether? We can't be the only shop where infra teams reuse hostnames.
Solved! Go to Solution.
- Labels:
-
Data Health Tools
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hey @Bobby Campbell
Instead of only blocking the match silently, many mature CMDB implementations combine:
- Exclude retired CIs from weak-name matching
- Add exception monitoring/review workflow
Recommended pattern:
Keep serial number as primary trusted identifier
Prevent fallback matching to retired CIs
Generate alert/task when:
Same hostname
Different serial
Existing retired CI found
This gives you:
Proper new CI creation
Historical preservation
Visibility into potential duplicate/retirement mistakes
Human validation before cleanup
Possible implementation options:
- Discovery post-processing rule
- Business Rule on CMDB tables
- IRE extension logic
- CMDB Health/Duplicate dashboards
- Event or notification generation
In practice, this usually works better than allowing silent CI resurrection.
Another recommendation:
If hostname reuse is common in your organization, consider reducing reliance on name-only fallback identifiers for those CI classes where serial numbers are generally reliable.
Because:
Same hostname + different serial
often indicates:
New hardware instance
rather than bad serial data.
Overall, your idea is directionally correct — the missing piece is adding governance/review handling instead of relying only on automated matching behavior.
Hope this helps.
*********************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.
Regards
Vaishali Singh
Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hey @Bobby Campbell
Instead of only blocking the match silently, many mature CMDB implementations combine:
- Exclude retired CIs from weak-name matching
- Add exception monitoring/review workflow
Recommended pattern:
Keep serial number as primary trusted identifier
Prevent fallback matching to retired CIs
Generate alert/task when:
Same hostname
Different serial
Existing retired CI found
This gives you:
Proper new CI creation
Historical preservation
Visibility into potential duplicate/retirement mistakes
Human validation before cleanup
Possible implementation options:
- Discovery post-processing rule
- Business Rule on CMDB tables
- IRE extension logic
- CMDB Health/Duplicate dashboards
- Event or notification generation
In practice, this usually works better than allowing silent CI resurrection.
Another recommendation:
If hostname reuse is common in your organization, consider reducing reliance on name-only fallback identifiers for those CI classes where serial numbers are generally reliable.
Because:
Same hostname + different serial
often indicates:
New hardware instance
rather than bad serial data.
Overall, your idea is directionally correct — the missing piece is adding governance/review handling instead of relying only on automated matching behavior.
Hope this helps.
*********************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.
Regards
Vaishali Singh
Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb