> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/developer-machines/installation/script/mdm-deployment/windows/microsoft-configuration-manager-sccm.md). # Microsoft Configuration Manager (SCCM) This guide is for IT admins deploying Dev Machine Guard to a fleet of Windows endpoints through **Microsoft Configuration Manager** (formerly SCCM, now part of the Microsoft Intune family as MEMCM / ConfigMgr). {% hint style="info" %} SCCM consumes the Dev Machine Guard MSI natively as a **Windows Installer (`*.msi`)** Application deployment type. Detection rule and uninstall command are auto-derived from the MSI `ProductCode`, so no scripting is required on your side. {% endhint %} ### What ships * `stepsecurity-dev-machine-guard--x64.msi` (Windows on Intel/AMD) * `stepsecurity-dev-machine-guard--arm64.msi` (Windows on ARM) Download the MSI for your architecture from [GitHub Releases](https://github.com/step-security/dev-machine-guard/releases). ### Two ways to pass tenant credentials | | **Option A: Inline properties** | **Option B: Pre-staged bootstrap file** | | ------------------- | --------------------------------------------------- | ------------------------------------------------------------------ | | **Set up** | One step (MSI deploy) | Two steps (drop config, then MSI deploy) | | **API key in logs** | Appears in `AppEnforce.log` if `/l*v` is on | Never on command line, safe under any logging | | **Multi-tenant** | One Application per tenant (different command line) | One Application; per-tenant config via GPO/Intune File preferences | | **Recommended** | OK for small or lab deployments | **Yes for production** | #### Option A: Inline properties Use this in the SCCM Application's **Installation program** field: ```cmd msiexec /i "stepsecurity-dev-machine-guard--x64.msi" /qn ^ CUSTOMERID="acme-corp" ^ APIENDPOINT="https://agent.api.stepsecurity.io" ^ APIKEY="step_xxxxxx" ^ SCANFREQUENCY=4 ^ /l*v "C:\Windows\Temp\dmg-install.log" ``` | Property | Required | Description | | --------------- | -------- | ------------------------------------------------------------------------ | | `CUSTOMERID` | Yes | Your StepSecurity tenant ID | | `APIENDPOINT` | Yes | StepSecurity backend URL (typically `https://agent.api.stepsecurity.io`) | | `APIKEY` | Yes | Tenant API key from your StepSecurity dashboard | | `SCANFREQUENCY` | No | Scheduled scan frequency in hours (default `4`) | #### Option B: Pre-staged bootstrap file (recommended) **Step 1.** Deploy a JSON config to every target endpoint via GPO File Preferences, Intune Settings Catalog → Files, or any other config distribution channel. Path: ``` C:\ProgramData\StepSecurity\bootstrap.json ``` Contents: ```json { "customer_id": "acme-corp", "api_endpoint": "https://agent.api.stepsecurity.io", "api_key": "sk_live_xxxxxxxxxxxxxxxx", "scan_frequency_hours": "4" } ``` **Step 2.** Deploy the MSI with the `BOOTSTRAPFILE` property pointing at that path: ```cmd msiexec /i "stepsecurity-dev-machine-guard--x64.msi" /qn ^ BOOTSTRAPFILE="C:\ProgramData\StepSecurity\bootstrap.json" ^ /l*v "C:\Windows\Temp\dmg-install.log" ``` The API key never appears on the `msiexec` command line, so it stays out of `AppEnforce.log` even with verbose logging enabled. The bootstrap file can be ACL-restricted to SYSTEM and Administrators if you want defense-in-depth. #### A note on the persisted `config.json` and multi-user machines Either deployment path writes the resolved config, **including `api_key` in plaintext**, to `C:\ProgramData\StepSecurity\config.json` on each endpoint. This is required because the scheduled task runs under the logged-in user's context and needs to read the config at scan time. The installer hardens the file's ACL on write to: * `NT AUTHORITY\SYSTEM` — Full Control * `BUILTIN\Administrators` — Full Control * `BUILTIN\Users` — Read Inheritance is disabled. So any logged-in user can read the API key (necessary for the scanner), but cannot modify it. On a single-user developer workstation this is the expected security posture. {% hint style="warning" %} On a **shared multi-user machine** (kiosk, lab workstation, RDS host) every interactive user can read the tenant API key from `config.json`. If that is not acceptable for your environment: * Use the `BOOTSTRAPFILE` path and tighten the bootstrap file's ACL yourself (the installer only manages `config.json`'s ACL). * Or scope deployment to single-user machines via SCCM collection requirements. DPAPI-backed storage is on the roadmap. Open a [feature request](https://github.com/step-security/dev-machine-guard/issues) to register interest. {% endhint %} ### SCCM Application setup, step by step **Step 1:** Go to **Software Library → Applications → Create Application**.
**Step 2:** Select **Manually specify the application information** and fill in: * **Name:** `StepSecurity Dev Machine Guard` * **Publisher:** `StepSecurity` * **Software version:** matches the MSI you are deploying (e.g., `1.11.3`)
**Step 3:** Add a Deployment Type and select **Windows Installer (`*.msi`)**.
**Step 4:** Under **Content**, point at the `.msi` file on a share that the Distribution Points can pull from.
**Step 5:** On the **Programs** tab: * **Installation program:** use the command from Option A or Option B above. * **Uninstall program:** SCCM auto-fills from the MSI `ProductCode`, usually `msiexec /x {PRODUCT-CODE} /qn`. Accept the default.
**Step 6:** For **Detection method**, accept SCCM's offer to use the MSI's product code. No custom script needed.
**Step 7:** On the **User Experience** tab: * **Installation behavior:** Install for system * **Logon requirement:** Whether or not a user is logged on * **Installation program visibility:** Hidden
**Step 8:** On the **Requirements** tab: * For the x64 MSI: `Operating system → Windows → All Windows 10/11 (64-bit) and Windows Server 2016+ (64-bit)` * For the arm64 MSI: same selection but the ARM64 variant
**Step 9:** Deploy to a test collection first (5 to 10 machines), then expand to the full fleet.
### Validating a successful deployment After SCCM reports the install as complete, on a target endpoint: ```cmd :: 1. The binary is on disk dir "C:\Program Files\StepSecurity\stepsecurity-dev-machine-guard.exe" :: 2. The scheduled task is registered schtasks /query /tn "StepSecurity Dev Machine Guard" :: 3. The config landed where the scanner can read it type "C:\ProgramData\StepSecurity\config.json" :: 4. (Optional) trigger an immediate scan to confirm end-to-end "C:\Program Files\StepSecurity\stepsecurity-dev-machine-guard.exe" send-telemetry ``` The configured tenant should see the endpoint in the StepSecurity dashboard within a few minutes.
### Upgrades When a new version ships, **create a new Application** in SCCM with the new MSI and mark it as **superseding** the previous Application: **Step 1:** On the new Application, open the **Supersedence** tab and click **Add**, then pick the old Application.
**Step 2:** Choose **Uninstall** for the old app. The new MSI's MajorUpgrade will do the uninstall atomically, but SCCM needs the supersedence link to track which endpoints to push the upgrade to. **Step 3:** Deploy the new Application to the same collection. On each endpoint: * SCCM pushes the new MSI on its next policy cycle (default 60 minutes). * Windows Installer recognizes the upgrade (same `UpgradeCode`, higher `Version`) and atomically uninstalls the old version (removing the scheduled task via the `uninstall` custom action), then installs the new one (re-registering the task with the new binary). * The per-tenant config at `C:\ProgramData\StepSecurity\config.json` is **preserved across upgrades**, so tenant configuration is retained automatically. ### Uninstall The SCCM uninstall fires the `msiexec /x {ProductCode}` command. Dev Machine Guard's custom action runs **before** file removal and calls `stepsecurity-dev-machine-guard.exe uninstall`, which removes the scheduled task via `schtasks /delete`. MSI then removes the executable and empties `C:\Program Files\StepSecurity\`. The config at `C:\ProgramData\StepSecurity\config.json` is **not** removed by MSI, since it lives outside the install scope. If you want a clean uninstall, add this as a post-uninstall cleanup step in SCCM or via GPO: ```cmd rmdir /s /q "C:\ProgramData\StepSecurity" ``` ### Troubleshooting | Symptom | Likely cause | Where to look | | ---------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------- | | MSI exit code 1603 | Custom action failed (bad credentials, `schtasks` denied) | `C:\Windows\Temp\dmg-install.log` (msiexec verbose log) | | Scheduled task missing | `install` custom action skipped or failed | Same log; search for `RunInstallScheduledTask` | | Endpoint not reporting to dashboard | Wrong API key or endpoint | `type C:\ProgramData\StepSecurity\config.json` | | Endpoint config still under `%USERPROFILE%\.stepsecurity\` | MSI ran without elevation (should not happen via SCCM) | Verify SCCM Application is set to "Install for system" | When opening a support case, attach: ``` C:\Windows\Temp\dmg-install.log (msiexec verbose log) C:\ProgramData\StepSecurity\agent.log (scanner output) C:\ProgramData\StepSecurity\agent.error.log ``` ### Verifying the MSI before deployment Before pushing an MSI to SCCM, run this check on a test workstation to confirm the file came from StepSecurity and has not been tampered with. This is a second integrity check, independent of the Windows publisher signature (Authenticode) that Windows already verifies at install time. #### Files to download From the [GitHub release page](https://github.com/step-security/dev-machine-guard/releases), grab both files below for each architecture (`x64` or `arm64`) you deploy: * `stepsecurity-dev-machine-guard--.msi` * `stepsecurity-dev-machine-guard--.msi.sha256.sig` #### Download and run the verifier ```powershell Invoke-WebRequest ` -Uri "https://raw.githubusercontent.com/step-security/dev-machine-guard/main/scripts/verify-msi.ps1" ` -OutFile ".\verify-msi.ps1" .\verify-msi.ps1 .\stepsecurity-dev-machine-guard--.msi ``` Success exits `0` and prints: ``` [OK] Signature VERIFIED - MSI is authentic and untampered. ``` #### If verification fails Do not deploy the MSI. Re-download both files from the official GitHub release and retry. If a fresh download still fails, contact `support@stepsecurity.io`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.stepsecurity.io/developer-machines/installation/script/mdm-deployment/windows/microsoft-configuration-manager-sccm.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.