Discovery Scan CI and duplicates

[aleck_lin]

We've recently revamped the way Discovery works largely due to the DHCP issue at a lot of customers' environments. Well, we've named the new way "Scan CI", which basically gathers enough information for a CI and then tries to correctly identify it in the CMDB. There are really three possible outcomes of this.

One, we find it and continue Discovery.
Two, we don't find it, so we create a CI and continue Discovery.
Lastly, we found multiple matches and we don't do anything since we can't positively figure out which one we should update.

Now, some of our early adopters of scan CI have run into issues with identifying the CIs in their CMDB. The issues are mostly the combination of identification logic that didn't work quite perfectly and identifier scripts not being customized correctly. In the Spring release that is coming up in a week, we will have the identification logic work like it ought to and also have a whole slew of identifiers that we've come across from different customers' environments out of the box. This means that you will have the opportunity to look through the identifiers and choose what works best for you. However, depending on how complex the rules are in your environment, further customization might still be needed.

One of the things about Scan CI is that we've forgone the CI Consolidation, which was an attempt to to automatically consolidate duplicates. However, there were issues where we would occasionally delete the wrong duplicate. Therefore, it has become evident that we can never figure out what the duplicate(s) are 100% of the time and we're really better off leaving the duplicates alone and letting customers who know their CMDB the best to decide what to do with it.

Having said that, in Scan CI, it is possible to create duplicates if the identifiers weren't able to identify a CI that was already in the CMDB, but it should never continue to create more duplicates of the same CI. At any rate, one of the common issues is to figure out what the duplicates are since there's no OOB support for figure this out other than running some type of report. If you are an admin and have access to scripts - background module, you could potentially run this little script to get a quick idea of what the duplicates are in your CMDB. And if you're comfortable with scripts, you could even modify it to delete the duplicates!

This example basically looks up the duplicates in the computer table based on name...
----------------------------------------------------------------------------------------
gatherDupes();

function gatherDupes() {
var gr = new GlideAggregate('cmdb_ci_computer');
gr.addAggregate('COUNT', 'name');
gr.groupBy('name');
gr.addHaving('COUNT', '>', 1);
gr.query();

var dupNames = [];
gs.log("The following " + gr.getRowCount() + " CIs has duplicates based on name field...");
while (gr.next()) {
gs.log("Duplicates: " + gr.getAggregate('COUNT', 'name') + " => " + gr.name);
}
}