Create Device In SCCM

Overview

A common SCCM workflow needs device records to exist in the database before the physical machines have ever booted: pre-staging laptops for an OSD task sequence, registering virtual machines ahead of provisioning, recreating a record that was deleted by mistake. The SCCM console exposes this via Assets and Compliance → Devices → Import Computer Information, one record at a time, with manual collection assignment as a separate step.

Create Device In SCCM (CDS) does both operations in one pass and supports it in bulk. Provide a list of devices with their Computer Name and a hardware identifier (SMBIOS GUID or MAC/Serial), pick the target collection, click Create — and CDS imports every record, waits for SCCM to propagate it, then adds it to the chosen collection. The whole transaction is logged to CMTrace for audit.

The OSD pre-staging use case

The most common reason to create a device record in SCCM before the machine exists is Operating System Deployment (OSD). When a new laptop arrives unboxed and is plugged into the network for the first time, it has no SCCM client, no OS, nothing — just a UEFI BIOS that can boot from PXE. For SCCM to deliver the right task sequence to that machine, the database must already know about the device, and the device must be a member of the collection that the task sequence is targeted to.

Pre-staging is the workflow that bridges this gap. Before the laptops arrive physically, the IT administrator:

1. 1

   Gets the hardware inventory from the manufacturer

   A CSV or spreadsheet listing every Computer Name (decided in advance by the naming convention) and the corresponding SMBIOS GUID or MAC address (collected by the manufacturer during burn-in).

2. 2

   Creates the SCCM records in advance

   CDS imports every device into SCCM via ImportMachineEntry. The records exist in SCCM but are linked to no hardware yet — they wait for a matching SMBIOS GUID or MAC to appear on the network.

3. 3

   Adds the records to the OSD targeting collection

   CDS auto-adds every newly-created record to the device collection that the OSD task sequence targets (typically named something like "OSD-NewLaptops-2026Q2"). The task sequence is already deployed to this collection; it is now armed and waiting.

4. 4

   The laptops arrive and boot from PXE

   Each laptop hits the SCCM PXE service, presents its SMBIOS GUID or MAC, gets matched to the pre-staged record, and immediately receives the targeted task sequence. The machines image themselves overnight with no human intervention.

When pre-staging makes sense — and when it doesn't

SCCM supports three OSD onboarding patterns, and CDS only helps with one of them. Knowing which pattern fits your environment before buying the tool is the honest first step.

For environments using the pre-staging pattern (whether exclusively or as part of a hybrid setup), here is the workflow CDS enables.

Other valid use cases for CDS include re-creating a device record that was deleted by mistake, pre-staging virtual machines before vCenter provisions them, and creating bare-metal records for lab and testing environments. The workflow is the same; only the source of the hardware identifiers changes.

Discovery polling — what to expect during execution

SCCM's ImportMachineEntry call returns success as soon as the record is written to the database — but the new device does not appear in SMS_R_System (the discovery table that collection membership checks against) immediately. Internal SCCM replication takes anywhere from a few seconds to several minutes depending on site topology, replica group activity, and database load. Until that propagation completes, the device cannot be added to a collection by name.

CDS handles this transparently with a polling loop. After every successful ImportMachineEntry, the tool polls SMS_R_System every 30 seconds, watching for the new device name to appear. Up to 10 minutes (600 seconds) of polling is allowed per device. Once discovered, CDS resolves the ResourceID, creates the direct-membership rule, calls RequestRefresh on the target collection, and moves on to the next device.

What happens on timeout

If a device is not discovered within 10 minutes, CDS reports a TIMEOUT for that device and moves to the next one. The record itself was still created successfully — only the auto-add-to-collection step did not complete. On the next run of CDS (or via the SCCM console) the device will be discoverable and can be added to the target collection manually, or re-run CDS with the same input and it will detect the existing record (idempotent path) and add it to the collection.

Bulk run timing expectations

For a bulk run of N devices, plan on roughly 1-3 minutes per device on a healthy SCCM site, occasionally longer on busy days. A batch of 50 devices typically completes within 1-2 hours. CDS processes the list sequentially — one device at a time, polling each one until discovery before moving on — so the run time scales linearly with the input. For larger batches, schedule the run during off-peak hours and let CDS run in the background while you do something else.

Prerequisites

Required SCCM permissions

CDS writes to SCCM — both creating records via SMS_Site and modifying collection membership. The recommended grant pattern is the built-in "Operating System Deployment Manager" role for the import-machine-entry permission, combined with "Operations Administrator" or a custom role for the collection modification. The signed-in Windows user must hold the following effective rights:

• SMS_Site.ImportMachineEntry Execute. The exact RBAC permission is "Import Computer Information" on the site object. The built-in "Operating System Deployment Manager" role includes it by default.
• SMS_R_System Read. Needed to check whether a device already exists (idempotence pre-check) and to resolve the ResourceID after import for the AddMembershipRule step.
• SMS_Collection (CollectionType = 2) Read + Modify Resource (the WMI permission that gates AddMembershipRule). Must apply to the specific target collection or to a parent security scope.
• SMS_FullCollectionMembership Read. Needed for the idempotence pre-check (is this device already in the target collection?).
• SMS_CollectionRuleDirect Write. Needed to create the direct-membership rule that adds the device to the target collection.

Initial configuration

On first launch, CDS verifies the license, then asks for SCCM 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, CDS picks them up automatically.

CDS only needs the SCCM section of the credentials dialog:

The SCCM Auto-detect button scans the local registry and WMI for a previously-configured SCCM console; if found, it pre-fills both fields automatically. The Microsoft Graph and Active Directory sections of the credentials dialog can be left empty — CDS does not use them.

Main features

Select Target Collection (mandatory, every session)

Above the tabs, a "Select Collection" button opens the Device Collection picker. The picker queries SMS_Collection via WMI for collections with CollectionType = 2, shows them in a searchable list, and returns the chosen collection. The target collection name is then displayed and used for every device created in the session.

Unlike AUC and ADC, CDS treats the target collection as required. Without one, the Create button refuses to proceed — there is no meaningful "create a device but do not add it anywhere" workflow in the OSD pre-staging use case, so the tool enforces the discipline.

Tab 1 — Single Device

A form with three fields: Computer Name (required), SMBIOS GUID (optional), MAC Address or Serial Number (optional). At least one of SMBIOS GUID or MAC/Serial must be provided — SCCM rejects ImportMachineEntry calls without a hardware identifier. The fields accept the same formats the SCCM console accepts; no client-side regex validation is enforced, so the verbatim SCCM error surfaces in the log if a value is malformed.

Tab 2 — Bulk from File

Browse to a CSV or TXT file. The file is parsed line by line; each line represents one device. Three columns are expected per line, in this order:

ComputerName;SMBIOSGUID;Serial/MAC
WS-MIL36-001;1234ABCD-5678-9012-EFGH-345678901234;ABC123XYZ
WS-MIL36-002;;00:1A:2B:3C:4D:5E
WS-MIL36-003;9999AAAA-1111-2222-3333-444455556666;

Per-column rules:

Accepted separators: semicolon (recommended for European locales because commas can appear in data), comma, or tab. Blank lines and leading/trailing whitespace are tolerated. A confirmation prompt shows the count and target collection before processing starts.

Tab 3 — Paste Devices

For ad-hoc input: paste a list copied from Excel, an email body, or a ticket comment. The same per-line format as Tab 2 applies (ComputerName + SMBIOSGUID + Serial/MAC, separated by ; or , or tab). Useful when the hardware vendor sends the inventory in the body of an email instead of as an attached file. Confirmation prompt is identical to Tab 2.

Three result statuses

Every device processed by CDS ends with one of three outcomes, summarised at the end of the run in the activity log and the status bar:

• Success The device was created (or already existed), discovered by SCCM, and successfully added to the target collection. The standard happy path.
• Skipped The device already existed in SCCM at the start of the run. CDS did not call ImportMachineEntry, but it still attempted to add the existing device to the target collection (success or already-member). Treated as a non-failure: re-running a CSV after a partial failure is safe.
• Error ImportMachineEntry failed, discovery timed out at 10 minutes, or the AddMembershipRule call returned an error. The CMTrace log captures the verbatim WMI return code or exception message for troubleshooting.

Activity log and CMTrace logging

The on-screen activity log is a coloured live transcript of every step: blue for informational messages, dark green for successes, dark orange for skips, red for errors. The same content is written to C:\TEMP\CreateDeviceSCCM.log in CMTrace format, cumulatively across sessions. Open with CMTrace.exe (shipped with SCCM) for coloured real-time viewing. The log captures every Computer Name, every WMI return code, every Discovery polling tick, and every collection rule creation — useful for an audit trail of an OSD pre-staging campaign.

License & read-only mode

CDS follows the TontonTools licensing model: 7-day cache + 7-day offline grace, then read-only mode. In read-only mode, the Create Device button is disabled — no ImportMachineEntry call can be issued and no collection membership can be modified. The credentials dialog and the collection picker remain accessible so you can review your configuration. A persistent banner offers 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 — pre-staging a wave of new laptops for OSD

1. 1

   Receive the hardware inventory

   The hardware vendor sends a CSV listing every Computer Name (decided by your naming convention) and either the SMBIOS GUID or the MAC address for each unit. Save it locally.

2. 2

   Configure credentials once

   Click 🔐 Credentials, fill in the SCCM Site Server FQDN and Site Code. Use Auto-detect if you have the SCCM console installed locally. The Graph and AD sections can stay empty for CDS.

3. 3

   Click Select Collection and pick the OSD target

   The Device Collection picker opens. Filter by name, double-click the collection that your OSD task sequence is deployed to (typically something like "OSD-NewLaptops-2026Q2"), OK. The target name is now displayed above the tabs.

4. 4

   Pick Tab 2 — Bulk from File

   Click 📂 Browse and select your hardware inventory CSV. Verify the file path and the device count. Click Create Devices. Confirm Yes on the prompt that summarises the count and the target collection.

5. 5

   Watch the progress in the activity log

   For each device, CDS reports "Importing...", then either "Already exists" (SKIPPED) or "Discovery pending" with a counter, then "Created and added to <collection>" on success. Discovery polling can take 30 seconds to a few minutes per device — this is normal SCCM propagation latency.

6. 6

   Verify in the SCCM console

   Once the run completes, open the SCCM console → Assets and Compliance → Devices. Filter on a Computer Name from your CSV; you should see the record with the correct SMBIOS GUID or MAC, and it should be a member of the OSD target collection.

7. 7

   Hand over to OSD

   When the physical laptops arrive and boot from PXE, each one finds its pre-staged record by SMBIOS GUID or MAC, gets matched to the OSD task sequence deployed to the collection, and images itself without human intervention. Keep the CMTrace log as your audit trail of which devices were pre-staged and when.

Limitations and design choices

• Target collection is required Every CDS session must specify a target collection. There is no "just create the record" mode without collection assignment. This is a design choice rooted in the OSD use case — pre-staged records without collection membership are functionally useless for task-sequence targeting.
• One target collection per session Every device created in a session goes to the same target collection. To populate multiple collections from the same input list, run multiple sessions of CDS or use ADC (Add Device To Collection) for the follow-up additions.
• Sequential processing with discovery polling CDS processes one device at a time and waits for SCCM discovery before moving to the next. For 50 devices on a healthy site, expect 1-2 hours of total run time. Sequential processing keeps the CMTrace log readable and avoids overwhelming the SCCM SMS Provider with parallel ImportMachineEntry calls.
• No client-side validation of SMBIOS GUID or MAC format CDS does not enforce hex-string or colon-separator patterns on the identifiers. Verbatim values are passed to ImportMachineEntry; SCCM validates and returns an error if a value is malformed. The error message is captured in the CMTrace log.
• 10-minute discovery timeout per device If SCCM has not discovered a newly-imported device within 10 minutes, CDS reports a TIMEOUT and moves on. The record itself was still created — re-running CDS with the same input will detect the existing record and add it to the collection.
• Idempotent on Computer Name only Existence check uses SMS_R_System.Name. If your environment has two devices with the same Name (different SMBIOS GUIDs or MACs), CDS sees the first one as "already existing" and skips creation. This is a known SCCM constraint: device names are expected to be unique within a site.

Technical notes

• WMI method used CDS calls SMS_Site.ImportMachineEntry with NetbiosName, SMBIOSGUID, and MACAddress as input parameters. The MACAddress parameter accepts either a MAC address or a serial number — SCCM's ImportMachineEntry treats both interchangeably as fallback hardware identifiers when SMBIOSGUID is absent.
• Polling configuration Polling interval: 30 seconds. Maximum elapsed time: 600 seconds (10 minutes). Per-tick existence check: SMS_R_System WHERE Name = '<device>' plus a SMS_FullCollectionMembership check against the SMS00001 All Systems collection (the universal SCCM root collection that every newly-discovered device joins by default).
• Collection membership creation After discovery, CDS resolves the ResourceID via SMS_R_System, then creates an SMS_CollectionRuleDirect with ResourceClassName = SMS_R_System, RuleName = the ResourceID as a string, and the matching ResourceID property. AddMembershipRule is called on the target collection, followed by RequestRefresh.
• CSV parsing File.ReadAllLines + Split on semicolon, comma, or tab. Empty trailing columns are tolerated. Per-line validation: missing ComputerName → skip with warning; missing both SMBIOSGUID and MAC/Serial → skip with warning. No header row detection — every non-blank line is treated as a device entry.
• 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 CDS runs entirely from the administrator workstation. The only outbound connections are RPC to the SCCM site server and api.lemonsqueezy.com for license validation (at most weekly).