How to identify and validate CIs created via Discovery?

Nia McCash
Mega Sage
Mega Sage

We are implementing Discovery for the first time and were quite surprised (and impressed, and overwhelmed) by the amount of information that Discovery was able to pull in. 

For example: Running a quick discovery on 1 windows server alone created 68 CIs in 15 different classes.

Breaking down the problem:

  1. How do you identify the CIs that were created via that particular scan?  The discovery status shows only the main device. Filtering the cmdb_ci list by created date is not helpful if you are discovering more than one device at a time on a given day:
    find_real_file.png

    The ability to identify the CIs created via a particular scan is also important in the case we want to delete all the CIs related to this scan to attempt a fresh scan - since we are just starting out with Discovery and performing a lot of different tests.

  2. Once you can identify a list of CIs that were created via a particular scan/a list of CIs associated to that particular device, how do you get a list of all the field values that were populated via Discovery for each CI? 

    Is there a more efficient way than going to each CI type, viewing or exporting a list of CIs created for that class including the fields specific to that class?

    If 15 different CI classes were created, that's 15 different lists to manually check -- and that's just for 1 windows server scan alone.  This number increases significantly the more types of devices are scanned. How have other organizations tackled this challenge?

12 REPLIES 12

We currently only have a handful of test servers that we are experimenting with.  So we can scan a particular un-hardened windows server, see what info is retrieved by Discovery. Then we want to harden the server and run Discovery again to see if the retrieved information changes based on hardening.

Nia McCash
Mega Sage
Mega Sage

Thanks for the information to all who have contributed to this thread.  I'm getting the sense that there is a lot of 'manual' work in implementing CMDB with Discovery - by which I mean a lot of checking of different lists (or JSONs), kind of what people refer to as 'swivel chair' activity. 

More generally, I would continue to be interested in any information/processes that help limit this kind of swivel chair activity.

The way I'd approach is first to understand what CI classes and CI attributes are required. Once you've determined what you're looking to get out of Discovery it's easier to validate the required information is being captured.

Just as a function of Discovery you're almost always going to these additional CI classes discovered. I.e. disks, network, running applications, as well as ADM (which is a big benefit of the product).