IRE Resurrecting Retired CIs During Hardware Refreshes - Anyone Solved This Cleanly?

Bobby Campbell
Mega Sage

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.

1 ACCEPTED SOLUTION

vaishali231
Kilo Sage

Hey @Bobby Campbell 

Instead of only blocking the match silently, many mature CMDB implementations combine:

  1. Exclude retired CIs from weak-name matching
  2. 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:

  1. Discovery post-processing rule
  2. Business Rule on CMDB tables
  3. IRE extension logic
  4. CMDB Health/Duplicate dashboards
  5. 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



View solution in original post

1 REPLY 1

vaishali231
Kilo Sage

Hey @Bobby Campbell 

Instead of only blocking the match silently, many mature CMDB implementations combine:

  1. Exclude retired CIs from weak-name matching
  2. 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:

  1. Discovery post-processing rule
  2. Business Rule on CMDB tables
  3. IRE extension logic
  4. CMDB Health/Duplicate dashboards
  5. 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