How do you handle stale CIs for which Discovery does not set the "Most recent discovery"

[cloudyrobert]

I'm working through our rather sizable list of stale CIs by class. For classes, such as Disk Partitions, where the OOB probes/patterns do not set the "Most recent discovery" and "Discovery source" and the stale metric is being created based on the sys_updated_on field, how do you remediate? The sys_updated_on field isn't updated every time the CI is found, so we have valid CIs that have no changes, are therefore not updated, and show as stale. I wish the discovery fields were set for every discovered class, but since they are not, how do you handle this?

[Ashutosh Munot1]

Hi,

I think something is wrong then, because for me at least the most recent discovery field is updated whenever the computer is discovered. See this for Disk partitions.

Thanks,

Ashutosh

[cloudyrobert]

Well, this is good to know...

[Ashutosh Munot1]

Hi,

I agree that if the partition is deleted related to that Server,etc then in servicenow it remains as is. In this case you need to use Health rules and task to solve this right. As Patrick said you can adopt deletion strategy as well.

I think you should increase the stale record days and create stale record rule on this specific table.

Thanks,
Ashutosh

[Patrick DeCarl1]

Hi, 

I would recommend setting up health inclusion rules for the main CI classes you care about. Example, CI class is a hardware type and status is not retire or stolen. This will reduce a lot of the noise of the "supported" ci types like disk partitions.  

https://docs.servicenow.com/bundle/london-servicenow-platform/page/product/configuration-management/...