Matching duplicate records: identifiers that hold up

Why do duplicates appear?

Each source names an asset by whatever key it has. Discovery may know a hostname and an IP address. The MDM knows a serial number. The EDR console has its own device ID. Without a rule that says these keys describe the same machine, the CMDB creates one record per source.

Which identifiers are stable?

Some keys survive the life of a device; others change often.

• Serial numbers are stable for physical hardware and are the strongest single key when present.
• MAC addresses are useful but can change with network adapters, docks and virtualization.
• Hostnames are convenient but get reused and renamed.
• IP addresses change with DHCP, VPN and moves between networks, so they are weak on their own.
• Cloud instance IDs are stable for the life of an instance, which may be short.

Lansweeper documents deduplication on "MAC, serial, and hostname". runZero profiles each asset against nearly 1,000 attributes, which gives more evidence for a match.

How do you match when keys disagree?

Use several keys and weigh them. A serial number match is close to certain. A hostname match with a matching MAC address is strong. A hostname match alone is a hint. Platforms that correlate many sources, such as Axonius, exist largely to do this weighing across dozens of tools at once.

What about virtual and cloud assets?

Short-lived resources need a different approach: match on the provider's own identifiers and retire records when the provider reports the resource gone. ServiceNow describes event-driven configuration updates for cloud environments for this reason.

How do you check matching quality?

Take a sample of fifty records and trace each one by hand to the sources. Count how many are true duplicates the system missed and how many were merged wrongly. Both numbers matter: aggressive matching removes duplicates but can merge two different machines, which is worse. Lesson 9 turns this sample into a regular measure.

Who should own the rules?

Matching rules are configuration, and configuration needs an owner. Name one person or team who approves changes to the rules, keeps a short written list of the keys in use and their order, and reviews wrongly merged records when someone reports them. Without that owner, the rules drift the same way the records do.

Where does matching show on this site?

The MATCHED line of each record card shows whether the vendor's pages describe merging records from several sources. The matrix on the home page counts which options document it fully.