This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Atrium Discovery and Dependency Mapping
BMC Discovery (Formerly Atrium Discovery and Dependency Mapping)
Why are duplicate hosts sometimes created in ADDM and synchronized to CMDB?
In general, there is no way to avoid duplicates altogether, as there is no single definition of what is a new and distinct host or which is a new set of data for an existing host. Our algorithm attempts to balance conflicting scenarios as best it can for the widest range of customer scenarios.
A new Host is created when the host node's identity has changed sufficiently that ADDM determines that a separate host node should be created, with a new host key. These changes could include serial number, discovered OS, etc. A serial number change carries the greatest weight. At this point ADDM "carries on" with the new host record, and the old host begins to age out since it is no longer being updated. When the aging limit is reached, the host is destroyed in ADDM, and an update is sent to the CMDB to mark this host as deleted. So any "duplicate" hosts only exist for a short time. For more information about Host node life cycle, see https://docs.bmc.com/docs/display/DISCO111/Host+node.
Please note: In certain circumstances, the "duplicate" hosts in the BMC.ADDM dataset can cause the CMDB reconciliation task to fail. In this case, the workaround is to destroy the old host in ADDM. Assuming that continuous CMDB sync is active, the destroy will be propagated to the CMDB and the old host will be MarkAsDeleted. However, please be aware that there may be asset/change management items (trouble tickets, etc) attached to the old host. In this case, it may be necessary to manually move the items from the old host to the new host.