Deploying SnitchOS with your RMM

How it works

1. Sign in to app.snitchos.com as an admin for the customer's tenant.
2. Go to Tenants → <customer> → Install agents.
3. In the RMM mass-deploy installer panel, download Install-SnitchOS-<slug>.ps1 (or the .cmd variant for batch-only RMMs).
4. Upload the script to your RMM's script library.
5. Push to every target endpoint and run elevated (SYSTEM or an Administrators member).

The script embeds the customer's tenant ID, a multi-use fleet enrollment key, and the CDN URL of the universal MSI. Each endpoint downloads the MSI, verifies its Authenticode signature, and installs silently with the right properties — no per-machine arguments.

Reuse and deliberate rotation

A normal download reuses the tenant's current active fleet key, so an existing RMM deployment task keeps working. Use Rotate & download only when you intend to revoke the previous wrapper, such as after suspected exposure or an administrator departure.

You can rename the downloaded file to match your RMM's naming convention — the customer identity is in the file content, not the filename.

Invocation commands

NinjaOne / Datto RMM / ConnectWise Automate / Kaseya

powershell.exe -ExecutionPolicy Bypass -File "Install-SnitchOS-<slug>.ps1"

N-able N-central / N-sight

Upload the .ps1 to the script repository and run it as a scripted task or automation policy against the target devices, with the execution context set to Local System. The command is the same as above. Nothing N-able-specific is required — the script takes no arguments and is idempotent, so a scheduled re-run against new devices is safe.

Batch-only RMMs

Install-SnitchOS-<slug>.cmd

The .cmd version uses curl.exe (built into Windows 10 1803+ / Server 2019+) and msiexec — no PowerShell required.

Microsoft Intune

Add the .ps1 as a Win32 app PowerShell script. Detection rule: presence of C:\Program Files\SnitchOS\SnitchOS.Agent.exe.

Group Policy

Run the .ps1 as a startup script. Re-runs on later boots are no-ops once the service is installed.

Verify the rollout

The tenant overview lists each new device within about 60 seconds of install; activity populates as users work. Every install also writes a device.enroll entry to the tenant's audit log with the source IP.

After install, your RMM can run the local health helper without showing UI:

& "C:\Program Files\SnitchOS\SnitchOS.HealthCheck.ps1" -Json

SmartScreen and antivirus

• The installer script verifies the MSI's Authenticode signature against both accepted publisher certificates before invoking msiexec and refuses anything unsigned or mis-signed.
• RMM-pushed installs normally avoid the interactive SmartScreen flow, but endpoint-security behavior depends on the client's policy.
• Defender or another security product may flag the input-count hook. Verify the Authenticode publisher first, then work with the client's security team on the narrowest appropriate allow rule. A file hash changes with each release.

One-off manual install

Use the downloadable installer — double-click, no arguments. The wrapper .ps1 also works fine on one machine.

If you would rather drive msiexec yourself, note that there is no enrollment-key MSI property to pass. The key is never handed to msiexec at all: the wrapper script writes it to an ACL-restricted bootstrap registry subkey first, then calls the MSI with a non-secret ready flag. That is why the wrapper exists, and why running it on one machine is the simplest manual path.

Earlier versions of this page printed a short PowerShell snippet for reproducing that step by hand. It has been removed rather than corrected, because hand-provisioning the bootstrap key cannot be made safe in a snippet. Three things have to be true at once, and only the shipped scripts manage all three:

• The key must be created, never adopted. CreateSubKey (and New-Item -Force) apply the security descriptor you pass only when they actually create the key - handed one that already exists they silently open it and drop the descriptor. Checking for absence first does not close that: the check and the create are two operations, and a key recreated in between is adopted, along with any handle already open on it, while the check reports all-clear. Only RegCreateKeyEx reports which of the two happened, and the wrapper aborts unless it says REG_CREATED_NEW_KEY.
• The descriptor must ride in the create itself. HKLM\SOFTWARE is readable by Users, so a key created first and locked down afterwards is briefly world-readable - and tightening a DACL does not revoke handles that are already open, which no amount of reading the DACL back will reveal.
• The key must end up owned by SYSTEM or BUILTIN\Administrators. The agent refuses to enrol from a bootstrap key owned by anyone else - the owner is the part a planter cannot forge, and a planted key redirects that machine's captures to somebody else's tenant. A descriptor that sets only a DACL leaves the owner at the creating account's default, which on a hardened box is the individual administrator, so the endpoint installs cleanly and then never reports.

So there is no hand-run recipe to give you. Run the tenant's wrapper .ps1 (or the .cmd payload, or the signed one-off .exe) from the Install agents page - mint a single-use, short-expiry key for one-off installs rather than reusing the fleet key, which pollutes the audit trail. The wrapper also verifies the MSI's Authenticode publisher against both accepted signing certificates and scrubs the key on every failure path.

Repair and re-enroll

To silently repair an endpoint with a bad or missing device token, push the same script with -Reenroll:

powershell.exe -ExecutionPolicy Bypass -File .\Install-SnitchOS-<slug>.ps1 -Reenroll

An enrollment key is authority to add a machine to a tenant, not authority to take an existing endpoint over. Replacing the device token of a machine that is already running one therefore needs more than the fleet key — otherwise anyone holding a copy of that key could knock your clients' endpoints offline at will. In practice the common repairs already carry what the server needs:

• Reimaged or wiped machine — nothing to do. Windows generates a new machine GUID, so it enrols as a brand-new device. Revoke the old row when you see the new one.
• Plain reinstall or upgrade — nothing to do. The endpoint keeps its device token and never re-enrols; the wrapper only stages credentials when there is no usable token.
• -Reenroll on an endpoint that still holds its token — nothing to do. The agent presents its existing token as proof that it is the device.
• -Reenroll where the token is genuinely gone — a restored image, disk corruption, a hand-deleted registry key. Here an administrator arms the device first, in Users & Devices → Devices → Allow re-enrolment. That permits exactly one token replacement inside a 12-hour window, and the re-enrolment that uses it spends it.

Order does not matter: the agent retries indefinitely, so arming the device after a repair has already run lets it recover on its own without re-running the installer. Both halves are audited — who armed the device, and which authority the resulting re-enrolment used.

One deliberate exception: a capped key that has run out of uses cannot repair even the machine it originally enrolled, and arming will not change that. Mint a fresh key on the Install agents page and repair with that.

Uninstall and offboarding

Per endpoint, or as an RMM uninstall job:

msiexec /x "{<product-code>}" /qn

Uninstall removes both services and stops collection; existing data stays in the backend per your retention policy. Normal uninstall intentionally leaves local support state behind — to purge it too:

msiexec /x "{<product-code>}" /qn PURGE_CONFIG=1

To decommission a whole customer: mark the tenant inactive (new enrollments are rejected immediately), revoke the fleet key, then uninstall via RMM at your convenience.