CMDB Health

[OMT]

Hello Community,

We are using ServiceNow Discovery with multiple MID Server zones and are facing challenges regarding CI lifecycle management and CMDB Health.

Our environment is highly dynamic (SDDC/virtualized infrastructure), where servers and VM instances can be intentionally powered off for extended periods and later powered on again.

We previously enabled CMDB Health retirement processes, but had to disable them because a significant number of CIs were moved to "Retired" although they were still valid assets. Typical reasons included:

- Temporary shutdown of servers/VMs

- Discovery credential issues

- Discovery configuration problems

- Naming changes or infrastructure changes causing temporary discovery gaps

One observation is that retirement decisions seem to rely on CI update timestamps rather than exclusively on the "Most Recent Discovery" date. As a result:

- Some CIs that are no longer discovered remain Operational because they continue to be updated by other processes.

- Other valid CIs may become Retired because Discovery does not see them for a certain period.

We also experimented with a custom "Unretirement" job based on the Most Recent Discovery Date (<22 days). However, this introduced another problem: CIs that had been intentionally retired (decommissioned) were automatically moved back to Operational when rediscovered.

Our main questions are:

1. How can we manage CI retirement in environments where servers can legitimately be powered off for weeks or months?

2. Do you use CMDB Health retirement rules, custom lifecycle states, or other mechanisms?

3. How do you distinguish between:

- a temporarily undiscovered CI,

- a truly decommissioned CI,

- and a CI affected by Discovery issues?

4. Is there a recommended ServiceNow approach for handling rediscovered retired CIs without creating false unretirements?

5. Have you implemented intermediate states such as "Absent", "Pending Retirement", or "Candidate for Retirement" before moving to Retired?

We would appreciate hearing about best practices, especially from organizations operating large virtualized or cloud environments.

Thank you.

[vaishali231]

Hey @OMT 

This is a common challenge in large Discovery environments, particularly in SDDC, VMware, cloud, and other highly dynamic infrastructures. One of the biggest lessons we've learned is that "not discovered" does not necessarily mean "decommissioned." A server may be intentionally powered off, inaccessible due to Discovery issues, or temporarily unavailable while still being a valid configuration item.

From our experience, Discovery should primarily provide technical evidence of a CI's presence, while lifecycle decisions should be driven by operational or asset management processes rather than Discovery alone.

1. CI retirement for temporarily unavailable servers

Rather than retiring CIs immediately after a period of Discovery inactivity, consider introducing intermediate lifecycle stages such as:

Operational
Not Seen
Candidate for Retirement
Pending Review / Pending Decommission
Retired

For example:

30 days without successful Discovery → Mark as Not Seen

60 days → Candidate for Retirement

90+ days → Create a review task for the infrastructure or asset owner

Move to Retired only after confirmation that the CI has been decommissioned

The exact timeframes will vary based on business requirements.

2. CMDB Health retirement

CMDB Health retirement can be valuable, but many organizations use it as a governance and reporting mechanism rather than enabling automatic retirement.

In environments where Discovery may occasionally miss devices due to credential failures, MID Server issues, cloud API problems, network segmentation, or infrastructure changes, automatic retirement can produce false positives.

Instead, many teams use CMDB Health to identify stale CIs and then validate them before changing lifecycle status.

3. Distinguishing different scenarios

Rather than relying on a single field, combine multiple indicators:

Most Recent Discovery

Last Successful Discovery

Discovery status or last scan result

Discovery source

Asset lifecycle status

Change or decommission requests

Identification and reconciliation results

Typical outcomes might be:

Discovery missing but infrastructure still expected → Not Seen

Credential or MID Server failures → Investigate Discovery, not the CI

Planned decommission confirmed through operational process → Retired

Large numbers of missing CIs simultaneously → Treat as a Discovery or infrastructure issue

4. Rediscovered retired CIs

Automatically changing a Retired CI back to Operational can create governance issues, especially if the CI was intentionally decommissioned.

A safer approach is:

Discovery identifies a matching retired CI.

Raise an exception or review task.

Validate whether the CI was intentionally restored or whether a new CI should be created.

Reactivate only after operational confirmation.

This prevents false unretirements while still allowing legitimate reactivations when appropriate.

5. Intermediate lifecycle states

Many mature CMDB implementations introduce states such as:

Not Seen

Candidate for Retirement

Pending Review

Pending Decommission

These states provide time for validation, reduce accidental retirements, improve auditability, and better reflect the actual lifecycle of infrastructure in dynamic environments.

*************************************************************************************************************************************

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

[drbob]

I don't have an answer but...

One observation is that retirement decisions seem to rely on CI update timestamps rather than exclusively on the "Most Recent Discovery" date.

This is true, it's called out in various CMDB training/documentation items. I find that odd. Both discovery and ServiceGraph methods update the "most recent discovery" and they are the processes attesting to the CI's existence so I don't understand why the retirement is based on any update.

It would be nice to have a system property define which field is used but I'm still not sure what the best answer is here - both have the same issue...

If discovery is working well then the "Most recent discovery" is regularly updated ...but that also means "updated on" is updated so either method will work.

If discovery is not so good then  "Most recent discovery" is not updated ...and unless there is anything else touching the records that also means "updated on" is not updated.

So there's no immediate advantage to using either except that "Most recent discovery" is more logical to the observer.

However, if there is some attestation process in place (at a higher frequency than the retirement one) that would ensure the "updated on" is regularly updated. ...and there could be plenty of other activities that could touch a CI. So in the "discovery is bad" case these other updates would help keep a CI active.

Thus "updated on" _does_ seem to make more sense. Unless you have a lot of bad data (which you might if discovery isn't working well) because then someone is likely to run a script to fix data and if that's run regularly it might keep updating a record and prevent it from retiring.

In my previous experience we started off with auto-retirement (I think in our initial naïve approach, this was over a decade ago, we wrote our own script rather than using the OOTB). We also auto-unretired if discovery found a retired thing. Eventually we switched it off as we just didn't know what was active and what wasn't ...and we even got divergence between CI and asset records (one active, the paired on inactive) due to some business rule blocking an update on one side but not the other. We switched it all off, got everything back in sync and set up reports to identify things which were stale and a process where those reports ended up in tasks ...so, yes, an attestation process. We had a decommission form in the catalog and that was the only way things were retired.

I don't think that's the best way but I'm not sure what actually _is_ the best way unless you have 100% robust discovery.