RMM

OpsMerge's RMM (Remote Monitoring & Management) is the part of the platform that watches your client endpoints, raises alerts, runs scripts, and gives you remote control. Once the agent is installed, everything in this section becomes available.

The pieces

• Policies — control what gets monitored, what runs, and how often. Inherit from defaults, override per-client, per-site, or per-endpoint.
• Monitoring & alerts — what OpsMerge watches out of the box, how to add custom checks, and how alerts route into tickets.
• Scripts & automation — PowerShell, bash, and Python scripts that you push to one or many endpoints. Ad-hoc or scheduled.
• Domain monitoring — checks for the client's external domains: SSL expiry, DNS, WHOIS, HTTP health, DMARC.
• Remote control with Connect — browser-based remote desktop, brokered through OpsMerge Connect (a RustDesk fork).
• Self-service scripts — let end users run a curated subset of scripts on their own machine via the Tray app, with approvals.

Mental model

OpsMerge RMM uses a simple inheritance pattern:

1. Tenant defaults — set at Settings → RMM → Defaults. Applied to every endpoint unless overridden.
2. Client policies — override defaults for one client.
3. Site policies — override the client policy for one site within a client.
4. Endpoint overrides — override everything for one specific endpoint.

Where you set something matters less than that you set it somewhere. The hierarchy means you can configure 95% of your fleet once at tenant level, and tweak the 5% of awkward special cases higher up the tree.

Data flow

Once the agent is running, the loop is:

1. Agent gathers telemetry (every few seconds for live state, every few minutes for inventory).
2. Agent publishes to NATS over the live connection.
3. Server-side workers consume NATS messages, write to Postgres, fan out alerts.
4. Alerts arrive in your dashboard immediately and create tickets according to your alert rules.
5. You can act on tickets directly, or push scripts back to the endpoint to resolve.

The whole loop is sub-second for live state and a few seconds for inventory updates.

What to set up first

After the agent is installed on a few endpoints, in this order:

1. Policies — set sensible tenant-wide defaults. The shipped defaults are a reasonable starting point but assume nothing about your MSP's standards.
2. Monitoring & alerts — review the default checks, mute anything noisy for your clientele, add custom checks for the things you actually care about.
3. Scripts — start a script library. Even three or four common scripts ("disable a user", "force Windows Update", "tail event log") will save hours over a year.

Domain monitoring, Connect, and self-service can wait until you have the basics.

Common gotchas

• A policy change doesn't apply immediately. The agent picks up policy updates on its next heartbeat (typically within 30 seconds). For specific endpoint, click Refresh policy on its page to force.
• An alert keeps firing for a "fixed" issue. Check whether the underlying check is still failing — alerts auto-clear when the condition goes back to OK, so a persistent alert means the underlying state is still bad.
• Scripts on Linux/macOS need the agent to run as root. It does by default, but some collectors/scripts that require sudo invocation specifically might be locked down by SELinux or AppArmor. See Scripts for the workarounds.

Next

Start with Policies.