Scripts & automation

OpsMerge lets you run scripts on any managed endpoint — one-off, scheduled, or in response to alerts. PowerShell on Windows, bash on Linux/macOS, and Python everywhere Python is installed.

The script library

Settings → RMM → Scripts.

The library is your collection of saved, reusable scripts. Every script has:

• Name and description (mostly for your team's sanity).
• Language (PowerShell, bash, Python).
• Body — the actual script.
• Default timeout — how long the script can run before the agent kills it.
• Run-as — who the script runs as (LOCAL SYSTEM by default on Windows, root on Linux/macOS).
• Parameters — named placeholders the script accepts (e.g. $Username, $Days).
• Approval gating — does running this script require operator approval?

Scripts can be:

• Personal — only the user who created them can see/run them.
• Tenant — shared across your MSP.
• System templates — read-only, shipped by OpsMerge. You can clone-and-edit.

Running a script ad-hoc

From any endpoint's page:

1. Actions → Run script.
2. Pick from the library (or paste a one-off script body).
3. Fill in any parameters.
4. Confirm.

Output streams back in real-time. When the script finishes, the full output and exit code are stored against the agent's script-history.

You can also bulk-run a script across many endpoints from the Agents list — multi-select endpoints → Bulk actions → Run script.

Bulk-runs are easy to fire and hard to take back

A script that does something destructive (delete a directory, force-reboot) bulk-run across 200 endpoints is 200 destructive operations all at once. Use the "Run on first N, wait for me to confirm, then run on the rest" pattern via the bulk dialog's batch mode.

Scheduled scripts

A script can be scheduled to run on a cron-like schedule.

Script → Schedule → + New schedule.

You set:

• When — cron expression or pick from presets (hourly / daily / weekly / monthly).
• Where — all endpoints, specific client/tag, or list of endpoints.
• In what window — e.g. only between 22:00 and 06:00 local-to-endpoint, only on weekdays.
• Parameters — if the script takes any.
• Retry behaviour — if the run fails (agent offline, script errors), how many retries?

Scheduled runs come from policy, not from this UI directly — under the hood, scheduling a script attaches it to a policy. See Policies.

Approval-gated scripts

For scripts that need a human in the loop:

1. In the script's settings, tick Require approval.
2. When anyone tries to run the script, the run goes into an approval queue.
3. A user with the Script approval permission must approve before it executes.
4. Approval timeouts: if not approved within X hours, the run is auto-rejected.

Used for: scripts that modify Active Directory, scripts that touch production databases, scripts your less-experienced techs are allowed to request but not fire.

Self-service from the Tray app

Approved end users can run a curated subset of scripts on their own machine via the OpsMerge Tray app. See Self-service scripts.

Language specifics

PowerShell (Windows)

• Runs in PowerShell 5.1 by default. If pwsh 7+ is installed on the endpoint, you can select it explicitly via the script's settings.
• Runs as LOCAL SYSTEM by default. You can switch to "active user" but that requires the user to be logged in.
• $ErrorActionPreference = 'Stop' is set automatically (you can override in the script if you want).
• Output is captured to UTF-8; PowerShell's default encoding is the source of half of all "why did my CSV come out garbled" tickets.

Microsoft Store PowerShell

The Store-installed pwsh.exe lives under WindowsApps with per-user ACLs. LOCAL SYSTEM gets Access Denied. If you specifically want PowerShell 7, install via the MSI (or scoop, choco) rather than the Store.

bash (Linux/macOS)

• Runs as root by default.
• set -euo pipefail is not set by default — add it yourself if you want strict failure semantics.
• Linux: the agent uses bash, not sh. POSIX-only scripts work fine; bash-isms are also fine.
• macOS: zsh is the system default but the agent invokes /bin/bash (still installed in modern macOS but old version 3.x — beware bash 4+ features).

Python

• Calls the system python3 interpreter (not bundled with the agent).
• If python3 isn't on PATH, the run fails fast with a clear message.
• Useful for scripts that need libraries (requests, pyyaml, whatever) — but the agent doesn't manage Python packaging. Install your deps via the script itself (pip install --user) or assume a known environment.

Output capture and limits

• stdout and stderr are captured separately and stored.
• Maximum output size: 1 MB by default. Output beyond that is truncated with a clear marker.
• Maximum runtime: defaults to 5 minutes; can be set per-script up to 1 hour. Beyond 1 hour, use a scheduled script with a state file rather than one long-running run.
• Exit code is captured and used by check-style scripts (see Monitoring).

Common patterns

"Wipe a specific user's profile on every endpoint"

param([string]$Username)
$ProfilePath = "C:\Users\$Username"
if (Test-Path $ProfilePath) {
    Remove-Item $ProfilePath -Recurse -Force
    Write-Output "Removed $ProfilePath"
} else {
    Write-Output "No profile for $Username on this endpoint"
}

Bulk-run with the Username parameter set to the departing employee's name.

"Daily diagnostic: capture top 10 disk hogs"

df -h / | head -2
echo "---"
sudo du -h /var | sort -rh | head -10

Schedule daily, output retained in script history.

"Auto-remediate: restart the service if it's down"

Tie it to an alert rule: when the "service status: stopped" alert fires, the alert rule action runs a Restart-Service script. The check goes green a few seconds later and the alert auto-clears.

Security

• All scripts are stored encrypted at rest.
• Every run is logged to the audit log — who, when, what, where.
• Scripts can be locked to specific user-roles (only Admins can edit, Technicians can run, Read-only can view).
• Script bodies are never sent to the agent in plaintext — they're encrypted in transit (TLS + per-agent NATS auth) and only decrypted on the endpoint at execution time.

Common issues

Script "succeeded" but didn't do what I expected. Check the captured stdout/stderr. PowerShell's $ErrorActionPreference = 'Stop' is set, but a lot of cmdlets emit "errors" that aren't truly errors — be defensive about how you check.

Script can't write to a network share. The agent runs as LOCAL SYSTEM on Windows. SYSTEM has no network identity by default — it can't authenticate to a share as itself. Use the user-context run mode, or use a service account.

Linux script that worked yesterday fails today. Often a PATH issue — the agent's environment is minimal and doesn't source ~/.bashrc. Either fully-qualify your commands (/usr/bin/jq) or export PATH=... at the top of your script.

Output appears truncated. Hit the 1 MB output cap. Save large output to a file on the endpoint and have the script print the path; download via the agent's file browser if needed.

Scheduled script runs at the wrong time. Cron timezone defaults to the endpoint's local timezone, not the agent's tenant TZ. Specify timezone in the schedule UI if you need a specific UTC time.

Next

• Self-service scripts — let end users run a curated subset
• Monitoring & alerts — scripts as alerts and as remediation