Unable to find how my ESX server got Decommisioned

[ChitraT13630579]

Hi All,

I'm new CMDB & discovery. In our production environment, few of the ESX Server CI's install_status is changed to "Decomminsoined". This activity supposed to update another field called "Decommissioned Date". This is written on a BR runs on "cmdb_ci" and for every installed_status changes. In the script they are checking if the "installed_status " is "decommissioned" then populate the current time in the "Decommissioned date" field.

In this case, Recent discovery is less than 10 days(10-07-2026) and the CI marked it as Decommissioned on 10-Jul-2026.

Here I have 2 queries.

1. Based on what these CI(ESX server CI) servers are getting decommissioned. Where can i go and check the configuration. (I have checked the Retired rule. But the condition mentioned in that role and this CI field values are not matching).

2. How to debug this issue and find the root cause.

Any help would be appreciated.

Thanks

Chitra

[Vikram Reddy]

Hello @ChitraT13630579,

First thing worth flagging: "Decommissioned" is not a stock choice value on install_status. Out of the box you get Installed, Retired, Absent, In Maintenance, Missing, and a handful of others, not Decommissioned. That tells you this value almost certainly came from a customization on your instance, not from the standard CMDB Identification and Reconciliation (IRE) engine, which is why the Retire Rule you checked doesn't line up. IRE's Retire and Absent rules only drive the stock Retired/Absent transitions based on last discovered, so if your choice list has a custom "Decommissioned" entry, something else is setting it.

For query 1, before you go deeper into the BR itself, check these sources for where the value actually gets written:

• Retire Rules and Absent Rules under CMDB Identification and Reconciliation, just to fully rule out (you've already looked, but confirm the rule is scoped to the ESX server class or a parent class, not just cmdb_ci generically)
• Transform Maps tied to any vCenter or VMware discovery data source, since a field map or transform script could set install_status directly during import
• Scheduled Jobs (sys_trigger) with scripts that reference install_status or run against cmdb_ci_esx_server
• Flow Designer flows or other Business Rules on cmdb_ci_esx_server, since multiple rules can fire on the same field change and the one you found may not be the only one
• Any CMP or asset lifecycle integration that might be reconciling ESX hosts against a source system and marking removed hosts as decommissioned

For query 2, the fastest way to nail down root cause is the field level audit trail rather than guessing from the BR code. Right-click the form header on one of the affected CIs and go to History > Audit (confirm install_status and Decommissioned Date are both audited fields first, Configuration > Dictionary if not). That gives you the exact timestamp and the updated_by user for the install_status change. If updated_by is a MID Server service account or an integration user rather than a person, you know it's coming from Discovery or an import, not a manual edit or a UI action. You can pull the same detail directly from sys_audit filtered on tablename=cmdb_ci_esx_server and fieldname=install_status if you want to check several CIs at once. Once you have that timestamp, cross reference it against the Discovery schedule run or the transform history for that window and you'll land on the actual trigger fast.

Thank you,
Vikram Karety
Octigo Solutions INC

[Animesh Das2]

Hi @ChitraT13630579 ,

You mentioned you have checked the retired rule but still I'd request you to verify two things here.

Open CMDB data manager (I hope your instance is in Yokohama) from the CMDB workspace and check the

1) retire policy and 2) subflows configured there.

If this address your question, please don't forget to mark this response correct by clicking on Accept as Solution and/or Kudos.

You may mark this helpful as well if it helps you.

Thanks, 

Animesh Das