CMDB Health - Orphan Remediation

[Tom104]

Hi All,

I'm looking into remediating several health issues with our CMDB.

One significant issue is the number of Orphan Records on the estate, currently circa 50k+

Will using remediation rules therefore generate 50k tasks, one per CI, or just one task?
I've tried to report on this in list view, but can't find any way to generate the list of CIs to allow manual deletion. 

Failing this, is there any suggestion as to how I can bulk delete the Orphan CIs, we're only targeting the application class currently?

Current Metric is "Application" has no Runs "On:Runs" relationship.

Thanks

[Mark Manders]

You could query to the Health results and from there to the cmdb_ci table for the found CI's to do a multi delete, but you are correct. The answer given deletes the health result records. Not very helpful from a ServiceNow Employee.

[Sandeep90]

The health result has classname and ci value and multi delete that is suggested is on the classname of the ci and not on the health result. Nothing needs to be deleted from the health result, when the health job runs again it automatically deletes the invalid(deleted CI) records. 

Script would look something like this and replace required class names and would suggest to do a dry run before deleting records. 

gs.trace(true);

var cis = [];

var gr = new GlideRecord('cmdb_health_result');

gr.addQuery('class_name','cmdb_ci_linux_server');//linux class

gr.addQuery('metric','bac72b5137130200f212cc028e41f1b8'); //required metric

gr.query();

while(gr.next()){

cis.push(gr.getValue('ci'));

}

var deleteGr = new GlideRecord('cmdb_ci_linux_server');

deleteGr.addQuery('sys_id', cis);

deleteGr.deleteMultiple();

gs.trace(false);

[IanCox]

Orphan CIs are usually a symptom, not the disease. Before mass-remediating, split them into three buckets, because each needs a different fix:

1. **Truly obsolete** — decommissioned hardware/software still showing as active. These should be retired via the asset lifecycle, not just deleted, so you keep the audit trail. A staleness rule (last-scanned > N days) plus a retirement flow handles most of these.

2. **Discovery gaps** — the CI is real but Discovery/Service Mapping never built the relationship. Fixing these at the CI level is whack-a-mole; fix the pattern instead. Check your Discovery schedules, credential coverage, and whether the relevant relationship-forming probes/sensors are actually running. Orphan counts usually drop sharply once Discovery is healthy.

3. **CSDM misalignment** — the CI exists and is discovered, but it isn't tied into a service via the CSDM structure (no application service, no technical service mapping). These are the ones that quietly break Service Mapping, impact analysis, and event correlation downstream.

For the remediation tasks themselves, a UI macro / form annotation on the CMDB Health task with the specific "what to check" per rule type dramatically improves completion rates versus a generic task — the earlier suggestions in this thread about linking KB articles are spot-on.

One habit that helps: track CI accuracy and orphan % as a trended KPI, not a one-time cleanup. Orphans regenerate if the upstream Discovery/CSDM cause isn't fixed, so the cleanup only sticks if you close the source.

*(Disclosure: I run a ServiceNow consultancy focused on CMDB/CSDM — happy to share our CMDB Health Check framework if useful: https://fourdragons.com/cmdb-health-check/ )*