agent failed to dedupe sccm query returning duplicate host records

TL;DR

ConfigMgr can legitimately hold multiple records that look like one host: discovery data from several sources, a reimaged machine with a new resource ID but the same name, or a WQL join that multiplies rows. The agent must dedupe on a strong identity (resource ID after resolving duplicates, or the client GUID or machine SID) and prefer the active record (the one with a live client and recent heartbeat). Where duplicates are real database duplicates, clean them at the source with the duplicate hardware ID tooling and merge behavior.

agent failed to dedupe sccm query returning duplicate host records

Use this when

• The same hostname appears two or more times in the agent target list from one collection.
• One entry has a client and recent heartbeat; its twin is stale with neither.
• Counts from the agent exceed the console visible device count for the collection.

Not for this skill when

• Duplicates come from two different collections in two waves. That is wave overlap, handled by target claiming.
• The duplicates are genuinely separate VMs with the same name in different domains. Identity must include the domain or resource ID, not the short name.

Steps

1. Export the collection membership the agent sees and group by hostname to find the duplicate pattern and which fields differ (resource ID, GUID, client status, last heartbeat). Verify: the distinguishing fields between twins are identified
2. Choose the dedupe rule: key on the ConfigMgr resource ID after collapsing records that share a client GUID or hardware ID, keeping the record with an active client and the freshest heartbeat. Verify: the rule reduces the test list to unique physical hosts
3. Implement the dedupe in the agent target builder, logging every collapsed record with both IDs and the reason. Verify: the log makes each collapse auditable
4. Clean the source where duplicates are database artifacts: use ConfigMgr duplicate record handling (automatic merge settings and the client re-registration behavior) so future lists are cleaner. Verify: console device count and agent count converge
5. Add a target-list sanity check comparing counts to the collection count with a tolerance and alerting on breach. Verify: a planted duplicate in a test collection triggers the alert

Variant phrasings

sccm duplicate device records collection query dedupe agent

The main phrasing.

same hostname twice configmgr resource id stale record

The twin-record phrasing.

dedupe key client guid hardware id patch targets

The identity phrasing.

Compatibility: Compatibility: Configuration Manager current branch collections, WQL and SDK queries; duplicate handling settings live in site hierarchy settings.

Why it happens

ConfigMgr discovery is multi-source by design (Active Directory, heartbeat, network discovery), and it errs toward keeping records rather than deleting a real machine. Reimaging and hardware swaps multiply records for one physical box. A human browsing the console mentally merges the twins; an agent counts rows, so the dedupe rule has to encode the same judgment: same machine identity, freshest live record wins.

Edge cases / pitfalls

• Merging records in ConfigMgr affects inventory history and reporting beyond patching; coordinate the cleanup with the ConfigMgr admin rather than scripting deletions unilaterally.
• A duplicate where both records show active clients can mean two agents or a cloned VM with a duplicated client identity; that is a host-side fix (regenerate the client GUID on the clone).
• Keep hostname-only dedupe out of the code; in multi-domain estates it will eventually merge two different live machines.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstbkJLBnMFIkc2i5kyHa7Xg