Credential less discovery creating duplicate CI

[snowenthusiast]

Hi,

We were running some tests and ran into an issue. We have a configured discovery schedule which pulled in the ESX server (as expected) along with associated VM's and other details. 

Now when we fired a "quick discovery" just on that IP, it did return response (with all the OID's) on SNMP query but failed to correlate with already existing ESX server. Now since OID's were not mapped it followed the expected next step and fired a credential-less discovery and created a "hardware" CI with CI (FQDN) name (ciname.org.com). As mentioned, CI already existed with ciname (and DNS Domain=org.com) under "ESX Server" class.

Can someone please tell me if this is the expected behavior? Or how can we make the credential-less discovery to check for existing CI and not duplicate it?

Thanks.

[vNick]

That is somewhat expected behavior, though I assume that when you did the quick discovery you specified port 161 to get it to run SNMP instead of SSH (not sure which originally may have populated your ESX CI).

Credential-less is a bit limited out of the box in terms of controlling how it populates attributes.  If you have "name" as a valid CI identifier on the ESX Server class (i.e. hardware class), and you populate it with shortname of the host, then yes, credential-less only populates with FQDN and you would get a duplicate.  The IP and mac should also be populated, but the mac may only if the MID server is on the same domain as the ESX server, so you can't always count on the IP + mac identification rule.

You can look at the pattern used by credential-less and see what all it is querying and populating on the shell CI that it will create / lookup. 

[snowenthusiast]

@vNickNOW

Thanks for your response. I did look at the credential-less pattern and it is populating the name with FQDN (servername.org.com), however, the regular ESX CI has name (servername) and domain (org.com) populated. Do you think if we populate FQDN on hardware, discovery will be able to consolidate? 

Also, what happens if things were other way round i.e. First, credential-less discovery is fired it creates a CI under hardware class (because of a credential issue). After that, we resolve the credential issue and run the discovery again, after successful discovery what happens to the generic hardware CI? Shouldn't it be consolidated into 1 CI? 

Again, thanks for all your help on this.

[vNick]

Yes - if you populate the name of your existing record with the FQDN, then credential-less would find the match.  

If credential-less creates the CI, and then discovery can successfully login to the device on subsequent runs, then it will find the match (again, only if the FQDN is the name value when discovery runs with credentials as that is how credential-less will populate the CI if you don't change the pattern) and reclassify the CI if necessary (maybe from the hardware table to the actual server type table... cmdb_ci_win_server for example).