Rediscovered CI remains Retired - Why doesn't OOTB Discovery change Install Status back to Installed

[Community Alums]

I am trying to understand the expected OOTB behavior for CI lifecycle status during Discovery.
I have a printer CI (cmdb_ci_printer) that was previously marked as Retired.

After running Quick Discovery:

The same CI was identified (no duplicate CI created)
last_discovered / Most Recent Discovery was updated
discovery_source was updated
The CI IP address was updated correctly
Discovery completed successfully

However:

Install Status remains Retired
It is not changing back to Installed

My questions are:

1. Is it expected OOTB behavior that a rediscovered CI remains in Retired status?
2. Does OOTB Discovery ever automatically change Retired → Installed when the same CI is rediscovered?
3. If not, what is the recommended approach, how to fix this issue?

[Vikram Reddy]

Hello @DeebikaS1775775,

Yes, this is expected OOTB behavior, not a bug, and no, standard Discovery does not flip Retired back to Installed on its own.

Here's the part that trips people up: Discovery's identification step and its field-update step are two separate things. Identification matches your printer against the existing cmdb_ci_printer record using identifier rules, and that matching happens regardless of the CI's current install_status. That is exactly why you saw the correct behavior on the pieces that did update: same CI reused, no duplicate, last_discovered and discovery_source refreshed, IP corrected. Discovery does not care that the CI was Retired when it goes to identify it.

Install status is different. It is a lifecycle attribute, and the OOTB discovery patterns for printers (and most hardware classes) simply do not include install_status in the payload they hand off to the Identification and Reconciliation Engine (IRE) during an update. IRE only reconciles attributes that actually arrive in the payload for that class. If install_status was never part of what the pattern collects and sends, there is nothing for IRE to compare it against, so it leaves whatever value is already sitting on the record, in your case Retired, completely untouched. It is not that Discovery evaluated the field and decided to leave it alone: the field was never in play for the update.

This cuts both ways, by the way. The same reason OOTB Discovery won't reactivate a Retired CI is why it won't retire an active one either. It sets install_status to Installed at creation time and then generally stays out of that field afterward. Community threads on this exact topic land on the same conclusion: "OOTB discovery sets to install. It never flips the status to retired OOTB," and that holds true in the reverse direction too.

For the fix: don't try to make Discovery own this field, build a small deliberate control around it instead. A Business Rule (or a scheduled job, if you'd rather batch it) on cmdb_ci_printer that watches for last_discovered or discovery_source changing while install_status is still Retired, and flips it to Installed when that happens, gives you the reactivation without pretending Discovery does it natively. Keep it narrow and logged, because a rediscovered "retired" asset is sometimes exactly what it looks like (someone put it back in service without going through CMDB​), but it can also mean a different device picked up the old IP, or the retirement itself was premature. I'd rather that get flagged and reviewed once than silently auto-flip every time, especially on a printer fleet where IPs get reused a lot.

If you want this to scale beyond printers, check whether your other CI classes' discovery patterns actually collect install_status at all before you build the same logic there. For most hardware classes they don't, which is the whole reason this thread exists.

Thank you,
Vikram Karety
Octigo Solutions INC