Ask the Expert: Setting up the CMDB Health metrics and applying them to a real world CMDB

[Lisa Latour]

Join us on this discussion page for a YouTube Live Presentation on setting up CMDB health metrics and how to apply them.

It's an opportunity to see how the new CMDB Health Dashboard can help you manage the data quality of server and network device data. This new dashboard provides an actionable view of CI health and a remediation framework to take corrective actions.  

Please Like and Share!   Find More Events on the Community!

---

Featured Expert

Presented by Richard Brounstein, ServiceNow Solution Architect for ITOM, specializing in IT Operations and crafting CMDB solutions for customers, based in the New York City area. He will be hosting a CMDB lab at Knowledge 2017. Before joining ServiceNow, Richard has more than 10 years experience as a System Engineer with Hewlett-Packard.

Watch the Demo Below and Read the Q&A below!
(Be sure to change your YouTube Setting to 720HD)

[richardbrounste]

If you manually update and save a CI, it will not update the most_recent_discovery field.

[imcarly]

Hi Do you know if its possible to use a different field to track staleness, like Last Updated Date?

[richardbrounste]

No. It is hard coded to use the most_recent_discovery (last_discovered) field. This field gets updated with the date/time that the CI was discovered even if there were no changed detected to any data. The Updated (sys_updated_on) field has the last date/time that the CI was discovered and at least one changed attribute was detected. It is possible for a CI to not be stale but not to have been updated for a long time so most_recent_discovery is the better field.

[Philip Tormanen]

If you manually update and save a CI, it will not update the most_recent_discovery field, but the Staleness metric is based upon the "Updated" field (sys_updated_on).  This means that the Staleness metric will show that the CI is not stale after a manual update even if the most_recent_discovery was long ago.

[richardbrounste]

Duplicate records are measured by running the CI identification rules for the particular classes against the existing CIs for those classes.   If the CIs that you know are duplicate are still uniquely identified by the CI identification rules, then they will not be found as duplicates.