Reconcile the identity before deleting the duplicate.
Two RMM records do not always mean two agents, and one device that changes identity is not always a harmless naming problem. Use these 24 checks to preserve the evidence, identify whether a golden image, reinstall, shared key, stale import, or integration created the conflict, contain privileged automation, and restore one authoritative identity per endpoint.
1. Confirm the duplicate
- Describe the visible conflict: two console objects, one endpoint changing identity, a stale record, or a naming collision.
- Capture platform device IDs, local agent or enrollment IDs, tenant, site, hostname, serial number, and hardware UUID from both sides.
- Build a timeline for imaging, installation, reinstallation, restore, first and last heartbeat, inventory, jobs, and user activity.
- Define the system owner, customer authority, maintenance window, stop conditions, rollback, and communication before cleanup.
2. Preserve identity evidence
- Capture the local agent ID, device key or certificate reference, enrollment metadata, install path, and version without modifying them.
- Compare serial number, hardware UUID, supported storage identifiers, operating-system install date, and other durable hardware evidence.
- Record hostname, domain, IP, MAC addresses, adapters, DHCP history, site, and proxy or NAT context so naming and identity collisions stay separate.
- Export record creation, tenant moves, last-seen data, inventory, scripts, patches, alerts, and audit actors before any retirement or merge.
3. Find the root cause
- Prove whether the agent was installed or enrolled before a golden image, virtual-machine template, or task sequence was sealed.
- Correlate uninstall, reinstall, reimage, or snapshot-restore behavior with the old and new platform records.
- Check whether enrollment tokens, keys, certificates, or device identifiers were shared, copied, expired, rotated, or revoked.
- Review API requests, imports, connectors, CMDB mappings, retries, and webhooks for duplicate creates or missing idempotency.
4. Contain safely
- Pause high-risk scripts, patches, alert actions, and remote access on ambiguous records so one endpoint cannot receive conflicting work.
- Quarantine any identity-bearing image, installer, deployment rule, or integration that is still creating duplicates.
- Protect tenant boundaries: disable access and automation until customer ownership, tenant, and site placement are proven.
- Preserve linked tickets, alerts, patch state, audit history, attachments, and approvals before archiving or retiring anything.
5. Reconcile records
- Choose one authoritative endpoint identity using current heartbeat, durable identifiers, ownership, workload, and historical value.
- Use only the vendor-supported identity reset, image-preparation, repair, or re-enrollment path; pilot it on one endpoint.
- Archive, merge, or retire the non-authoritative object with a reason, approver, retained links, and final evidence; avoid destructive deletion when possible.
- Repair downstream CMDB, ticketing, billing, backup, EDR, PSA, documentation, and integration mappings.
6. Validate and prevent
- Prove every endpoint has one unique active identity in the correct tenant and site after the documented ingestion interval.
- Test current inventory, monitoring, a bounded script, patch scan, and remote support separately and retain their audit evidence.
- Sweep the affected image, deployment, agent-version, tenant, and site cohorts for hidden duplicates or cross-tenant exceptions.
- Correct image timing, enrollment handling, API idempotency, duplicate detection, runbooks, owners, and review dates.
Primary documentation to pair with this workflow
This checklist organizes evidence and decisions; it does not replace the current procedure for the operating system or installed agent. Microsoft documents that a Windows image must be generalized before deployment to another computer. Datto RMM documents how locally stored agent identity and reused network adapters can create cloned or duplicate records. Liongard documents detection and supported reset behavior for duplicate agent identities. Before changing an identifier, key, certificate, file, registry value, enrollment, or platform record, use the exact current procedure for the affected product and retain the evidence required by your customer and security controls.
When is a duplicate RMM device resolved?
Resolution requires one unique active identity for each managed endpoint, correct customer and site placement, current functional results, preserved operational history, repaired downstream mappings, and an owned disposition for every stale or conflicting object. A renamed duplicate, hidden record, or deleted object without retained evidence is not reconciliation.