SCCM Permissions

Overview

Seven products in the TontonTools suite connect to a Microsoft Configuration Manager (SCCM / MECM) site to read, write, or both. This page is the centralized reference for the SCCM permissions required by each of them. Three products in the suite (Obsolete Device Management, Duplicate Device Management, Orphan Device Cleaner) are cloud-only and do not appear in this page — they only need Microsoft Graph permissions, documented separately.

The page is structured in two layers. A short quick-start section lists the built-in SCCM Security Role that satisfies each tool — the fastest path for evaluators and small environments. A detailed reference section then specifies the exact WMI classes accessed and the precise least-privilege custom role per tool — the right level for enterprise SCCM administrators following Microsoft's principle of least privilege.

Connection model

TontonTools products connect to the SCCM SMS Provider via WMI over RPC. The target namespace is root\sms\site_<SiteCode> on the SCCM site server. Connectivity is established with the standard .NET ManagementScope / ManagementObjectSearcher classes from System.Management, without any third-party library.

Quick-start — Built-in SCCM Security Role per tool

For pilots, lab environments, or small SCCM sites where role granularity is not a concern, assigning the operator a built-in SCCM Security Role is the fastest way to get a tool working. The table below maps each TontonTools product to the smallest built-in role that grants all required operations.

WMI classes and operations performed — by tool

The following sections specify, for each of the seven SCCM-touching tools, every WMI class accessed, the operation type (read or write), and the precise SCCM Security Operation required on each class. This is the data needed to build a minimum-privilege custom role.

DDE — Delete Device Everywhere

DDE removes a device resource from the SCCM database by ResourceID. It first reads SMS_R_System to resolve the device name to its ResourceID, then calls .Delete() on the resource. No collection-level operation is performed — the resource is deleted from the database entirely.

Minimum custom role: a single permission group with Read Resource and Delete Resource on the Collection class, scoped to the security scopes containing the devices that DDE is allowed to delete. Pair with the Default security scope plus any custom scope covering the target devices.

AUC — Add User To Collection

AUC resolves user accounts via three fallback strategies on SMS_R_User (UserName domain\sam pattern, then UniqueUserName, then UserName plain), then checks USER collection existence via SMS_Collection filtered on CollectionType = 1, verifies non-duplicate membership via SMS_FullCollectionMembership, creates the rule, and invokes AddMembershipRule followed by RequestRefresh on the target collection. Include and Exclude rules use SMS_CollectionRuleIncludeCollection / ExcludeCollection.

Minimum custom role: Read and Modify on Collection objects (User scope), scoped to the security scopes containing the target user collections. No site-level permission needed.

ADC — Add Device To Collection

ADC mirrors AUC but operates on devices and Device collections (CollectionType = 2). It resolves devices via SMS_R_System on Name, then performs the same membership rule operations as AUC on the target Device collection.

Minimum custom role: Read and Modify on Collection objects (Device scope), scoped to the security scopes containing the target device collections.

CDS — Create Device In SCCM

CDS pre-stages computer records via SMS_Site.ImportMachineEntry (the official method for creating an SCCM device resource by Computer Name + SMBIOS GUID or MAC), then polls SMS_R_System to confirm the discovery propagated, and optionally adds the new resource to a target Device collection via the same AddMembershipRule pattern as ADC.

Minimum custom role: Create Resource at site level (required for ImportMachineEntry, which has no scope-level equivalent), plus Read and Modify on the target Device collections. This is the only TontonTools tool that requires a site-level permission rather than a scope-level one.

GPDEU — Get Primary Device And Email From User

GPDEU reads three SCCM WMI classes. No writes. The signature class for GPDEU is SMS_UserMachineRelationship, which holds the primary user / primary device pairs maintained by SCCM's Asset Intelligence and User Affinity discovery.

Minimum custom role: Read Resource on user resources (scope: any security scope containing the queried users), plus optional Read on User collections if the operator uses the SCCM User Collection input method. The Read-only Analyst built-in role is a clean match.

GPUED — Get Primary User And Email From Device

GPUED is the symmetric counterpart of GPDEU. Same three WMI classes, but the lookup pivots from device to user. SMS_UserMachineRelationship is queried by ResourceName (the device side) instead of UniqueUserName (the user side).

Minimum custom role: identical to GPDEU. Read Resource on user resources, plus optional Read on Device collections. The Read-only Analyst built-in role is sufficient.

SIM — SCCM to Intune App Migrator

SIM is the only Application-focused tool in the suite that touches SCCM. It enumerates the application catalog via SMS_Application (filtered to IsLatest = 1 AND IsHidden = 0) and lazily parses each application's SDMPackageXML blob to extract deployment type metadata. No writes to SCCM ever — the application data is exported toward Intune, not modified in place.

Minimum custom role: Read Application on the security scopes containing the applications that the operator is allowed to migrate. The Application Administrator built-in role is a clean match and is the standard role for any tool that reads the SCCM application catalog.

Consolidated minimum custom role per tool

For SCCM administrators who prefer to express the entire permission set in one table per tool — for inclusion in change-management tickets or RBAC documentation — here is a consolidated summary. Each row shows the smallest set of SCCM Security Operations that grants exactly the access each tool needs, no more.

Creating a dedicated SCCM service account (optional)

A dedicated service account for TontonTools is not required — every product runs under the operator's Windows session. However, in tightly governed environments, organizations sometimes prefer to delegate the suite's SCCM access to a single named account that operators "Run as" instead of using their own privileged session. This pattern is fully supported.

1. 1

   1. Create the Active Directory account

   Create a standard AD user account named (for example) svc-tontontools-sccm. Disable interactive logon if your security policy demands it (the account only needs to be impersonated by the operator via runas or Save Credentials, never logged on directly).

2. 2

   2. Assign the SCCM role

   In the Configuration Manager console, navigate to Administration → Security → Administrative Users. Add the new account. Assign the custom role(s) built from the tables above, or a built-in role from the Quick-start section, scoped to the appropriate security scopes.

3. 3

   3. Test connectivity from the operator workstation

   On the operator's workstation, run the tool with the new account: right-click the executable → Run as different user → enter svc-tontontools-sccm credentials. Verify that the tool starts, that the SCCM connection succeeds, and that the expected scope of devices / users / collections is visible.

4. 4

   4. Audit periodically

   Review the SCCM site server SMSProv.log file regularly to confirm that the service account is being used as expected. Cross-reference with each tool's C:\TEMP\*.log on the workstations to validate the end-to-end audit trail.

Verifying SCCM connectivity before using the tools

Before deploying any TontonTools product that touches SCCM, verify that the operator workstation can reach the site server and that the operator account has at least read access to the SMS Provider namespace. Three quick PowerShell checks cover the entire end-to-end:

If the first check fails, RPC connectivity is blocked (firewall, network ACL, or DCOM port range mismatch). If the second check fails but the first succeeds, the operator is missing SMS Provider basic access. If the third check fails or returns nothing, the operator is missing scope or role assignment in SCCM RBAC.

Common errors and how to fix them

For tool-specific log files, each TontonTools product writes a CMTrace-compatible log to C:\TEMP\<ToolName>.log. Open with CMTrace.exe (shipped with the Configuration Manager console) for coloured real-time viewing. Cross-reference with the SCCM site server's SMSProv.log (under <SCCMinstall>\Logs\ on the site server) to see the WMI calls as received by the SMS Provider.

For the Active Directory permissions required by the three tools that also touch AD (DDE, GPDEU, GPUED), see the Active Directory permissions reference. For the Microsoft Graph permissions required by every cloud-touching tool in the suite, see the Microsoft Graph permissions reference. For the overall security and data-handling model, see Security & Data Handling.