question ITOM discovery in CMDB forum

ITOM discovery

priyaadhikarla — Mon, 12 Jan 2026 06:29:40 GMT

We’re encountering a situation where certain servers are incorrectly marked as “retired” in discovery tools due to terminated VM instance relations. However, these VMs are still active and running in production. This appears to stem from a prior migration activity, after which the VM status remained “terminated,” causing the operational status to reflect “retired.”

We’ve raised a HI case and were informed that this is expected out-of-box behavior—once a VM instance is marked terminated, it cannot be automatically updated back to “up.”

Is this behavior standard and meant to be managed manually?
Has anyone implemented a technical workaround or automation to restore accurate operational status in such scenarios?

Re: ITOM discovery

Fabian Kunzke — Thu, 15 Jan 2026 09:07:17 GMT

Hey,

This is indeed standard behavior, but it is not meant to be managed manually. To understand where this status comes from, feel free to take a look here: https://www.servicenow.com/docs/bundle/zurich-it-operations-management/page/product/discovery/reference/vm-instance-state-and-status-fields.html

Outside of that, the logic is, that terminated instances are retired for good (hence why it is a separate state from "just" retired). They are not meant to go back to a running state. To correct this, i'd propose you update all impacted instances once to be in the correct state. From then on onwards, the automation through the VM discovery/events should work correctly again.

This should not be a reoccurring issue - at least from my experience.

On a side note: I find the documentation here a bit irritating, as it leads to believe that "terminated" instances are indeed allowed to go back into a running state - which seems unreasonable.

Hope this helps,

Regards

Fabian

Re: ITOM discovery

Its_Sagnic — Thu, 15 Jan 2026 10:07:21 GMT

Hi @priyaadhikarla ,

Yes, this is standard out-of-box (OOB) behavior in ServiceNow Discovery . Once a VM instance state is set to "Terminated" by a cloud provider or vCenter event, the platform's logic typically prevents it from automatically reverting to "on" or "off" because termination is considered a final lifecycle state.

The issue often persists because Discovery schedules for the underlying server (e.g., Windows or Linux patterns) may not trigger if the associated VM Instance CI is marked as Retired, effectively orphaning the server record.

Recommended Solutions and Workarounds :

1. Use a Scheduled Job for Bulk Recovery :

If this issue stems from a one-time migration event, a script can be run to "force" the recovery of these CIs. This is the most common technical workaround.

Logic: Identify records where the VM Instance state=terminated but the associated Server CI was recently updated by an IP-based Discovery or is known to be active.

Script :

var gr = new GlideRecord('cmdb_ci_vm_instance');
gr.addEncodedQuery('state=terminated^install_status=3'); // '3' is typically 'Retired'
// Add your logic to filter by your specific migration datagr.query();while (gr.next()) {
    gr.state = 'on'; // Or 'off' based on your requirement    gr.install_status = 1; // Set to 'Installed'    gr.operational_status = 1; // Set to 'Operational'    gr.update();
}

Use code with caution.

2. Implement a "Discovery Source" Reconciliation Rule

You can use the Identification and Reconciliation Engine (IRE) to prevent the "Retired" status from being locked. Create a Reconciliation Rule that allows your specific IP-based discovery to overwrite the status set by the Cloud/vCenter event-driven discovery.

3. Adjust Pattern Post-Sensor Scripts :

For a more permanent automation, customize the post-sensor script of your cloud patterns (e.g., "Amazon AWS - Virtual Server").

Modify the script to check if a "Terminated" VM instance actually still exists in the provider's response during a full horizontal discovery.
If the VM is found during a full scan, force the state field to update regardless of its previous value.

4. Verification with Cloud Operations Workspace :

In 2026, use the Cloud Operations Workspace to review "Stale CIs". If the VM is still active in production, it should appear as a "discrepancy" between the Cloud Inventory and the CMDB, allowing you to remediate it directly from the workspace.

Would you like a more detailed script to identify exactly which CIs are currently "terminated" but still have an active server relationship ?

If you find it helpful please mark it as helpful.

Regards,

Sagnic

Re: ITOM discovery

priyaadhikarla — Mon, 19 Jan 2026 17:22:23 GMT

Thankyou @Its_Sagnic for detailed explanation.

We now see that these servers are migrated from ON prem to cloud with change. Hence we see two relations one with VMware virtual machine instance( whcih state is terminated) and one with VM instance (which state is ON). But usually as per our understanding and collective information from documents available ,If anyone relation is active the CI status should be updated as operational status. But Here we see the CI status is still retired.

We tried below steps:

1.) We removed on prem VMware virtual machine Instance relationship which is terminated and then tried discovery which is running as expected.

2.) But without removing the relation even if we update CI status as operational it is updating back to retired state once next discovery runs.

Hence it confirmed the issue.

Now I have few questions on this:

why operational status is not updated to operational based on ON state Virtual machine instance relation ?

Is it expected / usual behaviour that we should remove relation manually or it will be updated through discovery?

Please provide any further suggestion for us to handle this scenario