Remote control with Connect

OpsMerge Connect is our remote-desktop tool — a fork of RustDesk, rebranded and tightly integrated into OpsMerge. You launch a session from an endpoint's page in OpsMerge; the client connects in your browser.

Connect runs alongside the OpsMerge agent on each endpoint. The agent installs and manages Connect; you don't install it separately.

When to use Connect

• Helpdesk over a remote user's shoulder. The default scenario.
• Server-side troubleshooting. Unattended access (no user prompt) to fix something on a server.
• Operator training. Watch a less-experienced tech work through a problem with you observing.
• Brief remote presence. Faster than booking a meeting and demanding screen-share.

When it's not the right tool: anything you can do via a script. Scripts are auditable, repeatable, and don't require a human. If you find yourself opening Connect to perform the same procedure repeatedly, automate it.

Enabling Connect on an endpoint

Connect is enabled via policy. Three flags govern its behaviour, all per-endpoint:

Flag	Values	What it controls
enabled	Inherit / On / Off	Master switch. If off, no Connect on this endpoint.
auto_install	Inherit / On / Off	Whether to install Connect automatically. If off, an admin must manually trigger install.
configs	Inherit / On / Off	Whether OpsMerge's per-endpoint config (server address, password, etc.) overrides the local RustDesk config.

All three are tri-state — Inherit, On, Off — at every level of the policy hierarchy. The default is off across the board, so Connect doesn't get auto-installed without a deliberate decision.

Default off is deliberate

Remote control is a high-trust capability. We default it to "off" because turning it on without thought leaks attack surface. Enable per-client, not tenant-wide-then-disable-the-weird-ones.

Once enabled and installed, the Connect button on the endpoint's page is live.

Starting a session

1. Open the endpoint's page in OpsMerge.
2. Click Connect.
3. Choose:
   • Attended — the user at the endpoint sees a "Operator X wants to connect" prompt and must accept. Use for live helpdesk.
   • Unattended — connect without prompting. Use for unattended servers or when the user is offline.
4. A browser-based RustDesk viewer opens.

The session is brokered by our connection servers — the operator's browser and the endpoint don't establish a direct connection in most cases.

Audit and consent

Every Connect session is logged:

• Who opened it.
• Which endpoint they connected to.
• When it started and ended.
• Whether the end user accepted (for attended sessions).
• The session duration.

This appears in:

• The endpoint's history tab.
• The audit log.
• A separate Remote sessions report under Reports.

For attended sessions, the end-user prompt is non-bypassable by the operator. If the user rejects or doesn't respond, the session doesn't start.

For unattended sessions, the lack of a prompt is a privileged operation — only roles with the Unattended remote control permission can initiate them. We log them prominently.

What an end user sees

When you initiate an attended session:

• A small dialog appears on the endpoint asking whether they want to allow you to control.
• The dialog shows your name, your tenant (their MSP), and a timeout.
• If they accept, they see a small notification banner during the session showing your name.
• When the session ends, a brief banner confirms it.

When you initiate an unattended session:

• A small persistent notification appears (depending on policy).
• The endpoint's session-active light/icon turns on.
• Session details are logged on the endpoint locally (/var/log/rustdesk or C:\ProgramData\rustdesk).

You can configure how aggressive the user-side notification is per-policy. We recommend a minimum of "show that a session is active" for unattended sessions — invisible remote control breeds distrust.

Configuration governance

For most operators, the default config is fine. For specifically-managed environments (e.g. a client who requires their own RustDesk relay), the configs flag controls whether OpsMerge's central config overrides local. If you set configs to Off, the endpoint keeps any local RustDesk config — useful if the client manages RustDesk separately for their own reasons.

For most clients, leave configs at On (or Inherit-from-default-which-is-On). The benefit is centralised control: rotate a relay's password, change a server address, deprecate an old connection method — all from OpsMerge.

Tunnels and port forwarding (planned)

A future Connect feature is brokered port forwarding — for example, connect to a printer's web UI behind a client's network without bringing up the full RustDesk desktop. This is on the roadmap (with explicit MSP guardrails: audit, permission gate, end-user notification, timeout, rate cap). Watch the Founder Discord for previews.

Disconnecting and tearing down

Closing the browser tab ends your side of the session. The endpoint's RustDesk service stays running (so the next session can connect quickly).

To genuinely uninstall Connect from an endpoint:

• Flip the enabled flag to Off in the endpoint's policy.
• OpsMerge dispatches a rustdeskuninstall command on the endpoint's next heartbeat. The service stops, the install directory is removed, credentials are cleared.

This is also the procedure when a client cancels — their endpoints all flip to enabled=Off automatically, and Connect uninstalls cleanly.

Common issues

Connect button is disabled. Either Connect is not enabled in this endpoint's effective policy, or Connect is enabled but hasn't installed yet. Check the policy's RustDesk tab; if it says "installing", wait a few minutes and refresh.

Session won't start, viewer says "endpoint offline". The agent on the endpoint is offline. Connect rides on the same NATS connection — no agent connection, no Connect session.

Session starts but immediately disconnects. Most commonly a network-path issue. Connect prefers a UDP hole-punch; if UDP is blocked or unreliable on the endpoint's network, it falls back to relay. The relay should work but is slower. If even relay fails, look at the RustDesk service logs on the endpoint.

End-user prompt never appears. The endpoint may have no logged-in user (so there's no session to show the prompt in). Use unattended mode, or wait for someone to log in.

Asked to install Connect on macOS but it fails. macOS sandboxing + the RustDesk service installation has historically been fiddly. Check the agent's install log for the specific error. Recent Connect versions handle this much better but if you hit an old bug, contact support.

Security model

• Connect uses RustDesk's transport security (TLS, per-session encryption keys).
• Per-endpoint password is unique and randomly generated by OpsMerge — not user-chosen.
• Session brokering goes through our infrastructure; the broker can't decrypt traffic (it's transit between two encrypted endpoints).
• We do not retain session video or content. The audit log records "session happened", not "what was on screen".

For more on the threat model and what specifically is and isn't seen by OpsMerge during a session, see the security page on opsmerge.cloud.

Next

• Scripts & automation — often a better tool than remote control for repeatable work
• Policies — the configuration surface that enables Connect