## 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.

```text
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/pst_bkJL_BnMFIkc2i5kyHa7Xg