Summary

Importing a Discovery scan results into Assets (Cloud / DC / Server) creates duplicated Host objects, instead of updating the existing Host.

These may be "legitimate" duplicates, if the Object Hash value is not the same between two 'duplicated' Host objects - see below.

If the Object Hash of two 'duplicated' Hosts is the same, and the Import configuration was never changed from the default settings - please open a ticket with our support team.

Diagnosis

To better troubleshoot the issue;  you can start by navigating to your Host object type>List View, order the Host objects by Name or Hostname (click the header of the Name column), and add the following columns (attributes):

Hostinfo

FQDN

Model

Serial Number

UUID

Vendor

Network Interfaces

Object Hash

(you may hide Created and Updated)

First thing to look for - are there different Object Hash values between two instances (objects) with the same Hostname?

If you see different values for the Object Hash attributes of two objects with the same Hostname - well, technically, these are not duplicates, as they each have a different Unique identifier (Object Hash) calculated for them during a scan.

In this case - see which other Attributes listed above are showing different values between two objects with the same Hostname. These differences will be the reason for the different Hash value, resulting in "legitimate duplicates".

Most probable cause is the Network Interface, but another example can be: In the screenshot above - one scan was not able to get the Host's Model, hence a different Object Hash value was calculated, and a duplicate was created. (Later, the duplicated object was tagged as a Missing Object, it got its Status set to Not Found, and the Network Interfaces removed)

Cause

The columns/attributes added to the list view, correspond to the default settings in the Discovery ObjectHashSettings.xml file (see here, and your Discovery installation folder):

<!-- HostInfo Attributes -->
 <HostInfo_Hostname>true</HostInfo_Hostname>
 <HostInfo_FQDN>true</HostInfo_FQDN>
 <HostInfo_Model>true</HostInfo_Model>
 <HostInfo_Serialnumber>true</HostInfo_Serialnumber>
 <HostInfo_UUID>true</HostInfo_UUID>
 <HostInfo_Vendor>true</HostInfo_Vendor>
 <HostInfo_Virtual>false</HostInfo_Virtual>
 <HostInfo_SystemUpTime>false</HostInfo_SystemUpTime>
 <HostInfo_SystemUpTimeMinutes>false</HostInfo_SystemUpTimeMinutes>
 <HostInfo_RAM>false</HostInfo_RAM>
 <HostInfo_FirstNICMAC>true</HostInfo_FirstNICMAC>

The value of any attribute set to 'True' will be taken into account when calculating the Object Hash during a scan.

The Object Hash will be used as a unique identifier to establish references between different discovered objects, and by default, to identify Objects in Assets by the discovery import itself.

Note that any change to this file (e.g. changing an Attribute to False) will result in a duplicated object created once the next scan is imported (see how to prevent this, below).

Solution

Identify the Attribute showing different values between two instances of the Host object.

The cause might be a Pattern file was recently disabled/enabled - in which case the duplicate is 'legitimate' - so no need to change the objectHashSettings (proceed to "How to avoid duplicates" section bellow).

In many cases, the FirstNICMAC may be the reason for the duplicated objects - if using MAC Swapping or NIC swapping when spanning a new VM.

The way to workaround this is to edit the objectHashSettings.xml file:

 <HostInfo_FirstNICMAC>false</HostInfo_FirstNICMAC> 

This will result in Host objects with new Object Hash created.

How to avoid duplicates

So, to avoid Duplicates, please do the following, before importing this new scan results:

1. Navigate to the Schema Configuration > Import Tab > Discovery Import, and expand the Host object type map to see all the attribute maps.
2. The Object Hash should be indicated as the only identifier (a checkbox at the leftmost column of an Attribute map).
3. Set Hostname, UUID and Serial Number as the Identifiers. Once done, uncheck the Object Hash attribute from being the Identifier.
4. Now you may run the import, to update your Host objects, to be identified based on these 3 attributes, and not the Object Hash. The Object Hash itself will get updated during the import - with the new value that should be consistent from now on.
5. Once the import is complete, you may revert to using the Object Hash as the only identifier in the import.

You may still want to manually delete the duplicated Host objects - after revising them, by filtering on either their Creation Date or their Status (e.g. 'Not Found'), and bulk deleting the results.