Delete Device Everywhere

Overview

When a Windows endpoint is decommissioned, IT teams typically have to clean it up in four places: AD Users and Computers, the SCCM console, Intune, and Entra ID. Doing this manually is slow, easy to forget, and impossible to audit consistently across sites and analysts.

Delete Device Everywhere (DDE) consolidates the four cleanups into one workflow:

Prerequisites

The administrator running DDE needs:

• Account Operators or equivalent delegated rights in AD to delete computer objects in the relevant OUs.
• Full Administrator or a custom SCCM role that grants Delete on the Collection and Resource securable object types in SCCM.
• Graph identity an effective app or user identity holding the permissions listed in the permissions matrix.

Installation

1. 1

   Download

   After purchase, you receive an email from Lemon Squeezy with a download link and your license key. Download the installer ZIP from the customer portal.

2. 2

   Extract

   Extract the archive to a folder of your choice. The application is portable — no MSI installer is required for the standalone edition.

3. 3

   Unblock

   Right-click DeleteDeviceEverywhere.exe, choose Properties → Unblock if the file is flagged by SmartScreen, then click Apply.

4. 4

   Launch

   Launch DeleteDeviceEverywhere.exe. On first start, the license dialog appears.

5. 5

   Activate license

   Paste the license key from your purchase email and click Activate. The product validates against the Lemon Squeezy License API and caches the validation locally for 7 days.

6. 6

   Configure credentials

   The credentials dialog appears next. Configure Graph (Tenant ID, Client ID, Client Secret or Certificate Thumbprint), SCCM (Site Server FQDN and Site Code), and AD (LDAP root). Click Save.

Initial configuration

The credentials dialog is unified across the TontonTools suite. For DDE, all three sections must be filled in if you intend to delete from all four systems.

Microsoft Graph section

DDE supports three Microsoft Graph authentication modes. Choose the one that matches your security policy. All three use the same Tenant ID and Client ID; only the secret material changes.

Mode 1 — Client Secret (App-only)

Classic application authentication. DDE acquires a token via client_credentials grant against /oauth2/v2.0/token. Suitable for lab environments and small deployments. The secret is stored DPAPI-encrypted locally.

App Registration setup: Certificates & secrets → Client secrets → New client secret. Copy the value immediately (it is shown only once). API permissions → Microsoft Graph → Application permissions (see permissions matrix). Grant admin consent.

Mode 2 — Certificate (App-only, JWT client assertion) — Recommended for production

Stronger than client secrets, no secret to rotate. DDE signs a JWT client assertion with the certificate private key (RS256, RFC 7523) and exchanges it for an access token. The private key never leaves the workstation.

App Registration setup: Certificates & secrets → Certificates → Upload certificate. Upload the .cer public key only. Keep the matching private key in Cert:\CurrentUser\My on the administrator workstation. API permissions → Application permissions (same as Client Secret). Grant admin consent.

In DDE: open the credentials dialog, switch Auth mode to Certificate. The dialog scans Cert:\CurrentUser\My and lets you pick a certificate from the list. Expired certificates appear in red. Only the thumbprint is stored in the credentials file.

Mode 3 — Interactive (Delegated, with PKCE)

The administrator signs in with their own Microsoft 365 account through a browser. All Graph operations execute under the user's own permissions and are fully auditable in Entra ID sign-in logs. No secret is stored at all.

How it works internally: DDE opens a local HTTP listener on http://localhost:<random-port>/, launches the default browser to the Microsoft authorize endpoint with PKCE (Proof Key for Code Exchange, RFC 7636), receives the authorization code on the loopback redirect, and exchanges it for an access token. The 3-minute timeout cancels the operation if you do not complete sign-in.

Delegated scopes requested: DeviceManagementManagedDevices.PrivilegedOperations.All, Device.ReadWrite.All, and offline_access. Microsoft will prompt for consent on first sign-in.

SCCM / MECM section

Active Directory section

Credentials are saved to %AppData%\TontonTools\credentials.dat, DPAPI-encrypted under the current Windows user. See Security & Data Handling for details.

Main features

Single device deletion

Enter the device name (NetBIOS name — without domain suffix) in the Single Device tab. Tick the systems you want to clean (AD, SCCM, Intune, Entra ID — any combination). Click Preview to scan, then Delete to commit. A confirmation dialog requires explicit consent before any deletion is performed.

Bulk deletion (CSV / TXT import)

Switch to the Bulk tab. Click Import file and select a .csv or .txt file with one device name per line. The grid displays the loaded names and validates them. Tick the target systems and click Delete bulk to process the list sequentially. A progress indicator and an aggregated success / failure count are written to the activity log and the CMTrace file.

Preview / Dry-Run mode

The Preview button performs a read-only scan of all selected systems and reports the result per device, per system:

• FOUND the device exists; deletion would proceed.
• NOT FOUND the device does not exist; nothing would be deleted.
• ERROR the lookup failed (connectivity, permissions, throttling).
• SKIPPED the system was not selected for scanning.

Preview makes zero changes. It is safe to run repeatedly, including against production tenants, before approving a deletion campaign.

Rollback snapshot

Before performing any deletion, DDE captures a full metadata snapshot of the target device across all four systems and writes two files to C:\TEMP\DWE_Rollback\:

LAPTOP01_2026-04-18_16.30.00.json         ← Full metadata snapshot
LAPTOP01_2026-04-18_16.30.00_REBUILD.ps1  ← Auto-generated reconstruction script

The JSON snapshot captures, per system:

• Active Directory distinguishedName, OrganizationalUnit (parent OU extracted from DN), samAccountName, dnsHostName, operatingSystem and version, description, whenCreated, whenChanged, lastLogonTimestamp, userAccountControl, objectGuid, objectSid, and the complete memberOf list (every group the computer belonged to).
• SCCM ResourceID, Name, ClientVersion, IsClient flag, IsActive flag, ADSiteName, LastActiveTime, OperatingSystemNameAndVersion, MAC addresses, IP addresses, and the complete list of CollectionMemberships.
• Intune a list of all matching managed devices (a single device name can yield multiple Intune records). For each: ManagedDeviceId, DeviceName, AzureAdDeviceId, OperatingSystem and version, ComplianceState, ManagementAgent, EnrolledDateTime, LastSyncDateTime, UserPrincipalName, SerialNumber, Model, Manufacturer, DeviceCategory.
• Entra ID a list of all matching directory devices. For each: ObjectId, DisplayName, DeviceId, OperatingSystem and version, TrustType, MDM app ID, registration time, approximate last sign-in, and group memberships.

CMTrace logging

DDE writes a CMTrace-compatible log to C:\TEMP\DeleteDeviceEverywhere.log. Open it with CMTrace.exe (shipped with SCCM) for colored, real-time viewing. Every entry includes timestamp with millisecond precision, executing Windows user, component (DWE), severity, and a free-text message.

License & read-only mode

DDE 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 DDE continues to operate normally. After 14 days without a successful validation, the product moves to read-only mode.

What read-only mode does

• Disables the Delete buttons (single and bulk).
• Disables the Preview button.
• Keeps the Credentials dialog accessible — you can still update your tenant or SCCM settings.
• Keeps the Activity Log and Export Log buttons working — for post-incident review of past operations.
• Displays a banner offering to enter a license key or start a trial.

In other words: DDE never silently stops working. The destructive operations stop, but the diagnostic surface stays available. You can restore full functionality at any time by entering a valid license key or by reconnecting to the license server.

Typical workflow

1. 1

   Identify stale devices

   Use the Obsolete Device Management Tool to produce a CSV of devices inactive for more than 90 days.

2. 2

   Review and approve

   Share the CSV with the requester (line manager, asset owner). Trim the list as needed.

3. 3

   Preview

   In DDE, open the Bulk tab, import the approved CSV, tick all four target systems, and click Preview. Verify that each device appears as expected.

4. 4

   Snapshot review

   DDE will have written rollback snapshots to C:\TEMP\DWE_Rollback\ for each device. Spot-check a few to confirm metadata capture is complete.

5. 5

   Delete

   Click Delete bulk. Confirm the destructive action in the dialog. Watch the activity log for any errors.

6. 6

   Archive logs

   Copy the CMTrace log and the rollback folder to your standard ticketing attachment location for audit purposes.

Troubleshooting

AADSTS70011: scope is not valid

You are using delegated scopes with an app-only configuration, or vice versa. Recheck the Auth Mode in the credentials dialog and the permission type in the App Registration.

AADSTS50105: user is not assigned to a role

Conditional Access is blocking the App Registration. Adjust your Conditional Access policies, or use a different authentication mode.

SCCM: The RPC server is unavailable

The SMS Provider is unreachable. Verify the Site Server FQDN is correct, that the WMI service is running on the site server, and that no firewall blocks DCOM (TCP 135 + dynamic range).

AD: Insufficient access rights

The signed-in user does not hold sufficient delegated rights on the OU where the computer object lives. Either elevate, or have an Account Operator handle the deletion.

Intune: HTTP 404 on deletion

The device was already deleted from Intune (orphaned Entra ID record). Untick the Intune target and re-run for the remaining systems.

For any other issue, capture C:\TEMP\DeleteDeviceEverywhere.log and send it to support@tontontools.com.

Security notes

• DDE does not require any agent on the devices being deleted. The product only talks to your AD domain controllers, your SCCM site server, and Microsoft Graph.
• All credentials are stored DPAPI-encrypted on the administrator workstation.
• Every deletion is recorded in your Entra ID audit log, your SCCM SMSProv.log, and your domain controller security event log, attributed to the App Registration (app-only mode) or to the signed-in user (interactive mode).
• TontonTools never receives, stores, or transmits device names, tenant data, or rollback snapshots.

Limitations

• DDE does not unenroll a device locally. If the device is still online and the user has access to it, the device may re-register itself with Entra ID and re-enroll with Intune on next sign-in. Use an Intune retire/wipe action first if the endpoint is still in service.
• The SCCM deletion path requires the SCCM console PowerShell module on the workstation. A future release will offer a WMI-only path for workstations without the console.
• Rollback snapshots capture metadata, not state on the device itself. Re-enrolling a wiped endpoint still requires the endpoint to be online and reachable.