Duplicate Device Management

Overview

Duplicate device registrations are a quiet but corrosive problem in cloud directories. The same physical laptop or phone ends up registered two, three, or ten times — usually after a reset, a re-enrollment, or a join-leave-rejoin sequence. Every duplicate inflates license counts, distorts compliance dashboards, and creates ambiguity when an analyst tries to identify "the" record for a device.

Duplicate Device Management (DDM) scans a directory by device name, groups records that share the same name, and applies a deterministic algorithm to recommend which record to KEEP and which records to DELETE. You review the recommendations, optionally adjust the selection, and clean up in bulk.

The KEEP / DELETE recommendation algorithm

This is what distinguishes DDM from a plain "list all duplicates" query. For every duplicate group, DDM applies a deterministic three-criterion sort and assigns recommendations automatically. The top record after sorting is the KEEP; every other record in the group is a DELETE candidate.

The three sort criteria, applied in order

1. 1

   Most recent activity (primary criterion)

   Last Sync date for Intune records, or Approximate Last Sign-In for Entra ID records, converted to UTC. The most recently active record wins. Records with no activity date are demoted to the bottom of the group.

2. 2

   Managed status (tiebreaker)

   Among records with identical or unknown activity dates, those flagged as Managed = true rank higher than those that are not. Unmanaged shadow records lose to managed records in any tie.

3. 3

   Compliant status (tiebreaker)

   When activity and managed status are equal, compliant records win over non-compliant records. This brings the cleanest record to the top whenever ties cannot be broken by the first two criteria.

What the recommendation reasons say

Each row carries a textual explanation of why it received its recommendation, visible in the data grid and in the Device Details dialog:

• KEEP reasons Concatenation of the criteria that matched, joined by " · ". Examples: "Most recent activity · Managed · Compliant", "Most recent activity · Managed", or simply "Best in group" when none of the three criteria produced a positive signal but the record was still ranked first.
• DELETE reasons Almost always a quantified comparison with the kept device: "Inactive 47 day(s) longer than kept device". If the record has no activity date at all: "No activity date recorded". As a final fallback: "Older duplicate registration".

When to use DDM vs Obsolete Device Management

DDM and Obsolete Device Management (ODM) share most of their UI surface — same Source toggle, same filter ComboBoxes, same data grid pattern. They solve different problems though, and many administrators end up running both as part of the same monthly hygiene routine.

Prerequisites

Microsoft Graph permissions

The exact application permissions DDM requires on your App Registration. Grant admin consent after assigning them.

Initial configuration

On first launch, DDM verifies the license, then asks for Microsoft Graph credentials via the standard TontonTools credentials dialog. Credentials are shared across the suite — if you already configured them for another tool on the same workstation and user profile, DDM picks them up automatically.

DDM supports the three standard TontonTools Graph authentication modes: Client Secret (App-only), Certificate (App-only, JWT client assertion — recommended for production), and Interactive (Delegated, with PKCE). The credentials flow is identical to the other Graph-backed tools in the suite. For the full mode-by-mode setup including App Registration prerequisites for Interactive, see the Delete Device Everywhere documentation.

Main features

Source selection: Entra ID or Intune

The Source drop-down switches the entire view between two data sources. Entra ID groups by displayName, Intune groups by deviceName. The data grid columns adapt automatically: Entra shows Trust Type, Account Enabled, Object ID, On-Prem sync data; Intune shows User Name, Manufacturer, Model, Compliance, Enrolled Date, and Intune Device ID.

Switching the source clears the current results and resets the column visibility. DDM scans one directory at a time — the two have different identifiers and different obsolescence semantics, so combining them in one grid would mislead more than help.

Minimum duplicates threshold

The "Minimum duplicates" drop-down controls which groups are reported: ≥ 2 (default — every duplicate), ≥ 3, ≥ 4, ≥ 5, or ≥ 10. A higher threshold is useful when you want to focus on extreme cases first — devices that appeared four or more times deserve immediate attention, and processing them surfaces the worst data quality issues quickly.

Other filters

• Operating System Windows, macOS, iPhone, iPad, Android, AndroidEnterprise, AndroidForWork, Unknown. Useful to scope a campaign to a single platform — Android resets in particular generate large quantities of duplicates.
• Recommendation filter (all devices) by default. Switch to "✅ KEEP only" to review which records DDM thinks should stay, or to "🗑 DELETE only" to see all candidates for deletion across every group.
• Free-text filter Matches device name, OS, version, user name, model, manufacturer, Trust Type, IDs. Case-insensitive substring search.

Detect Duplicates (the main button)

Clicking 🔍 Detect Duplicates triggers the scan: DDM queries the selected source with $top=999 per page, follows @odata.nextLink until all records are retrieved, applies the OS filter on the workstation, groups by name in lowercase trimmed form, and runs the KEEP / DELETE algorithm on every group of size ≥ the configured threshold. Results populate the grid with row colour coding: green pale for KEEP rows, red pale for DELETE rows.

The status bar at the bottom shows the total number of devices in groups, the number of duplicate groups found, and the current selection count. Sort by clicking any column header — Group # is shown first to keep duplicates visually clustered.

Select All DELETE (one-click bulk selection)

The "🗑 Select All DELETE" button is a productivity feature: it automatically selects every row that the algorithm has marked as a DELETE candidate, leaving every KEEP row untouched. For a routine cleanup where you trust the algorithm, this is a one-click prelude to "Delete Selected".

You remain free to fine-tune the selection afterwards: deselect specific DELETE rows you want to keep for now, or manually add a KEEP row to the selection if you have a specific reason. The selection is yours; "Select All DELETE" is a starting point.

KEEP protection during deletion

When you click "Delete Selected", DDM inspects the selection. If any rows marked KEEP are present, a dedicated warning appears before the final confirmation:

This two-step pattern protects against accidental Ctrl-A selections, but never blocks legitimate edge cases where you do want to delete a KEEP record — it just forces a deliberate decision.

Delete Selected (final destructive action)

The final confirmation shows the count, lists up to 15 device names with their KEEP / DELETE marker for visual scan, and ends with an explicit "IRREVERSIBLE. Confirm?" prompt. Deletions are sequential, with per-device CMTrace logging — including the HTTP status code and response body on failure. The KEEP vs DELETE breakdown is logged at the start. Aggregated success and failure counts are summarised at the end.

Two CSV exports

DDM offers two distinct exports, side by side in the action bar:

• 📥 Export CSV Exports the current filtered view of the grid — exactly what you see, after the Recommendation filter and the text filter have been applied. Useful when you want to capture a specific slice of the results.
• 📥 Export DELETE list Exports every DELETE candidate across the entire detection, ignoring the on-screen filters. This is the file you generate before a cleanup campaign — it captures the full list of records that the algorithm thinks should go.

Both exports use the configured separator (semicolon by default; comma or pipe also available), UTF-8 with BOM for Excel compatibility, and a meaningful default file name like Duplicates_EntraID_DELETE_Candidates_20260615.csv.

Device details dialog (double-click a row)

Double-clicking any row opens a detail window with five tabs: Duplicate Info (group number, total in group, recommendation, reason), Identity, Status, Dates, and All Properties. The top of the window shows a coloured banner — green for KEEP, red for DELETE — with the recommendation text and reason at a glance. The "Copy All" button copies a plain-text dump of every field, suitable for pasting into a support ticket.

CMTrace logging

DDM writes a CMTrace-compatible log to C:\TEMP\DuplicateDeviceMgmt.log — a single cumulative file, appended across sessions. Every entry includes the operator (DOMAIN\User), the auth mode, the tenant, and timestamp with millisecond precision. Major operations are marked with section separators: APPLICATION STARTUP, SEARCH, DELETION, DELETION SUMMARY. Open the log with CMTrace.exe (shipped with SCCM) for colored, real-time viewing.

License & read-only mode

DDM follows the TontonTools licensing model. It validates against the Lemon Squeezy License API on activation, then caches the result locally for 7 days. After that, a successful validation extends the cache; an unreachable license server triggers a 7-day grace period during which DDM continues to operate normally. After 14 days without a successful validation, the product moves to read-only mode.

What read-only mode does in DDM

• Disables Detect Duplicates — no Graph scan can be launched.
• Disables Select All DELETE and Delete Selected — destructive paths are blocked.
• Keeps Export CSV and Export DELETE list active — useful for audit and post-incident review.
• Keeps the Credentials dialog accessible — you can still update tenant or App Registration settings.
• Displays a persistent banner offering to enter a license key or contact support.

For the full licensing model — Trial mechanics, machine and tenant binding, moving a license between workstations, subscription cancellation behavior — see the Licensing reference.

Typical workflow — a routine duplicate cleanup

1. 1

   Configure credentials once

   Click ⚙ Credentials, fill in Tenant ID, Client ID, and your chosen auth mode. If credentials are already configured for another TontonTools product, DDM picks them up automatically.

2. 2

   Pick a source

   Use the Source drop-down to choose Entra ID or Intune. Most teams run two passes — Intune first (the larger volume of duplicates), then Entra ID.

3. 3

   Pick the minimum duplicates threshold

   Start with ≥ 2 to see every duplicate. If the result is overwhelming, switch to ≥ 5 or ≥ 10 to focus on the worst cases first.

4. 4

   Click Detect Duplicates

   The grid populates with groups, each tagged with a Group #. KEEP rows show in pale green, DELETE rows in pale red. Recommendations and reasons are visible per row.

5. 5

   Review a few groups manually

   Open the Device Details (double-click) on the largest groups to spot-check the algorithm. The Recommendation reason explains why each row was ranked the way it was.

6. 6

   Export DELETE list before destructive actions

   Click 📥 Export DELETE list to get a CSV of every record the algorithm wants to remove. Keep this file as your audit trail.

7. 7

   Click Select All DELETE

   One click selects every DELETE candidate across all groups. Adjust manually if specific records should be kept for now.

8. 8

   Click Delete Selected and confirm twice

   If your selection includes any KEEP rows by mistake, the KEEP-protection prompt fires first. Then the standard "IRREVERSIBLE" confirmation. The CMTrace log captures the full per-device result.

Limitations and design choices

• Detection is name-based only DDM groups by displayName (Entra) or deviceName (Intune) in case-insensitive trimmed form. It does not match by MAC address, hardware serial, SMBIOS GUID, or SID. In typical Microsoft cloud directory data, the device name is the only field reliably populated across re-enrollments — alternative matching criteria are absent or unreliable.
• One source at a time DDM scans Entra ID or Intune, not both at once. The two have different identifiers and different timing semantics; merging them in a single duplicate group would conflate distinct registration concepts.
• No rollback snapshot Unlike Delete Device Everywhere, DDM does not capture a JSON snapshot before deletion. Use the Export DELETE list as your pre-deletion audit trail.
• Recommendations are starting points, not commands The algorithm pre-selects nothing. You always click Select All DELETE (or pick rows manually) before deletion. The KEEP / DELETE recommendation is an aid, not an automated decision.
• No Active Directory or SCCM coverage DDM is a cloud-directory cleanup tool. For on-premises AD or SCCM duplicate cleanup, the Orphan Device Cleaner (coming) and Delete Device Everywhere cover those systems.

Technical notes

• Graph API versions Entra ID search uses /v1.0/devices. Intune search uses /beta/deviceManagement/managedDevices to retrieve the full set of fields the algorithm needs. Both deletions use /beta — the Microsoft-recommended channel for device deletion today.
• Page size and pagination DDM requests $top=999 per page and follows @odata.nextLink until exhaustion. There is no client-imposed cap on the total number of records returned. The algorithm runs after every page has been retrieved, so the grouping is consistent across paginated results.
• Sort stability The three-criterion sort is performed in memory on the workstation, after all records have arrived. Within a group of records that are tied on all three criteria, Microsoft's response order determines the KEEP — which is non-deterministic across calls. In practice, ties on all three criteria are rare for real duplicates.
• Credential storage DPAPI-encrypted under the current Windows user profile at %AppData%\TontonTools\credentials.dat — shared across all TontonTools products on the same user account on the same workstation.
• No telemetry, no agent DDM runs entirely from the administrator workstation. The only outbound connections are to graph.microsoft.com (for the scans and deletes) and to api.lemonsqueezy.com (for license validation, at most weekly).