9. Ring Remote View reference#

Who this is for. Plant IT, integrators adding a site, a security reviewer checking the package's claims against its code, and a future developer who needs an exact value without re-reading every script.

Not a walkthrough. For the guided install see installer/07 — Ring Remote View (v1, LAN) and installer/07a — off-site (v2, Cloudflare Tunnel). For what an operator sees, see operator/10 — Remote viewing; for where this sits in the plant network, see reference/02 §2.4.

Ring Remote View is a separate, optional package — a pinned, hardened MeshCentral server plus a portable Node runtime, installed into C:\Ring\RemoteView\. It mirrors the one live Ring HMI session; it never starts a second Ring, never opens a second PLC connection, and no Ring file is touched by anything in it. Every table below comes from the package's own scripts and config template, the two runbooks, and a bench verification pass run 2026-09-04 — where that pass found something a runbook got wrong, or left unproven, this chapter says so.

9.1 Pinned constants#

test\Verify-RemoteViewStatic.ps1 asserts every value above across every script and the config template — see §9.7.

v2 pinned constants (Cloudflare Tunnel, optional)#

9.2 Listeners and firewall#

What actually listens (bench-observed, 2026-09-04)#

Inbound firewall rules#

No rule is ever created for MPS 4433.

Dual-homed: LocalSubnet alone is not enough if the plant subnet is also "local" — bind the rule to the office NIC with -InterfaceAlias; the installer requires both -LanCidr and -InterfaceAlias together on a multi-homed box and asserts the rule's interface filter matches. Profile: the rule is Domain,Private only — if the NIC's Get-NetConnectionProfile category is Public, the rule does nothing and 8443 is unreachable with no error (the installer warns in its summary). The 2026-09-04 bench run hit exactly this and used -NoFirewall instead, since the lab's only NIC was Public.

v2 is outbound-only. cloudflared dials out on TCP 443 (and UDP 7844 for QUIC). The v2 installer creates no inbound rule and asserts that none exists referencing cloudflared.

9.3 Files and folders on the HMI PC#

C:\Ring\RemoteView\
    node\                         portable Node 24 LTS "Krypton" (not machine-wide)
    meshcentral\                  MeshCentral 1.2.4 (agents\ pruned to Windows x64)
        meshcentral-data\        JUNCTION -> C:\Ring\RemoteView\meshcentral-data\
        meshcentral-recordings\  JUNCTION -> C:\Ring\RemoteView\meshcentral-recordings\
    meshcentral-data\             real folder: config.json, certificates, database
    meshcentral-recordings\       real folder: session .mcrec recordings
    manifest.json                 the payload SBOM
    payload-inventory.json        path + size + SHA256 of every payload file
    cloudflared\                  v2 only — see below

The junctions are load-bearing — do not delete them. MeshCentral resolves its data folder relative to the package location, and winservice.js forwards only user/port/aliasport/mpsport/mpsaliasport/redirport/exactport/debug to the Windows service — not --datapath. Deletes in this package are junction-aware: a link is unlinked first, so a recursive delete can never follow it into real data.

Rollback deny-list. C:\Ring\Icons, C:\Ring\Pictures, C:\Ring\App and C:\Ring itself can never be deleted by a rollback — only artefacts this run created (install root, junctions, config.json, both services, the firewall rule, the shortcuts, and any accounts it created) are ever undone.

9.4 Accounts and rights#

The rule the design depends on: a MeshCentral site administrator bypasses every device-group rights mask entirely. So every operator is created with --rights none — zero server rights — and access is granted only on the Plant HMI device group, per account, by numeric mask. The admin account stays with plant management, never handed to an operator.

   8         REMOTECONTROL
 512         NOTERMINAL
1024         NOFILES
2048         NOAMT
4194304      NOREGISTRY
8388608      NOSOFTWARE
--------
12586504     control mask
    +256     REMOTEVIEWONLY
--------
12586760     view-only mask

Bit values are the MESHRIGHT_* constants in meshuser.js @ 1.2.4, lines 40–64. MeshCtrl flag names map to the same bits in meshctrl.js @ 1.2.4, AddUserToDeviceGroup, lines 1648–1665: control = --remotecontrol --noterminal --nofiles --noamt --noregistry --nosoftware; view-only = the same plus --desktopviewonly (the flag for the 256 bit — --viewonly is not a real flag).

Erratum, corrected on purpose. An earlier brief quoted 12587016 / 12587272 — the same flags, mis-added by exactly 512. This package ships the correct masks above, and the static gate fails the build if either superseded literal reappears anywhere.

What MeshCtrl actually shows (ListUsersOfDeviceGroup, bench-observed): ringadmin → FullAdministrator; jbaker (control) → RemoteControl, NoTerminal, NoFiles, NoAMT; shiftlead (view-only) → RemoteControl, RemoteViewOnly, NoTerminal, NoFiles, NoAMT. Note the gap: MeshCtrl's text view never names the NoRegistry/NoSoftware bits — only the numeric mask read-back (12586504/12586760) confirms them.

Enforced server-side, not just a hidden tab. The 2026-09-04 pen-test pass (§9.7) confirmed the relay itself refuses to route a restricted account to the agent for terminal, file and command requests.

2FA is domain-wide, not per-account. force2factor: true applies to every account — MeshCentral 1.2.4 has no per-account 2FA setting. It is enforced post-login: a successful password login is signalled to force 2FA enrolment afterward, not refused outright (webserver.js, feature flag 0x00040000). skip2factor is deliberately absent.

9.5 Configuration keys as rendered by the installer#

Rendered by Install-RemoteView.ps1 from config-template.json into meshcentral-data\config.json. <TOKEN> = a placeholder.

settings.*#

domains[""].*#

v2 — the five keys it patches, and why#

Each is justified line-by-line against the MeshCentral 1.2.4 source in REMOTE_ACCESS_V2_RUNBOOK.md §4A; this is the one-line summary.

v2 — must NOT set (the installer refuses to proceed if any is present)#

9.6 Scripts and parameters#

Build-RemoteViewPackage.ps1 — packager-side payload builder#

Install-RemoteView.ps1 — target-side installer#

Provision-RemoteView.ps1 — device group + operator accounts#

Uninstall-RemoteView.ps1#

New-RemoteViewFirewallRule.ps1#

Install-RemoteViewTunnel.ps1 — v2 companion#

Test-RemoteViewTunnelSmoke.ps1 — v2 staged smoke#

Verify-RemoteViewStatic.ps1 — static gate#

param() — no parameters.

powershell -NoProfile -ExecutionPolicy Bypass -File .\test\Verify-RemoteViewStatic.ps1

Runs entirely offline: installs nothing, starts no service, touches no firewall. See §9.7 for the current pass result.

9.7 Verification evidence#

Everything here was observed, in order, on a bench pass 2026-09-04 on the developer laptop (Windows 11 Home, single NIC classified Public), source tree main @ fd4e5173. Items not exercised are marked NOT VERIFIED — that phrasing is deliberate; do not read it as a pass.

Fresh install with the fixed package (authoritative). Install-RemoteView.ps1 (-NoFirewall, with the local Mesh Agent), branch docs/remote-access-guide: exit 0, 175 s (an earlier run before the cert/origin fix took 203 s under the same conditions — expect longer on an HMI PC with on-access AV scanning the ~394 MB payload). Printed: certificate name laptop-t8d4hur8.local; allowedOrigin = laptop-t8d4hur8, laptop-t8d4hur8.local, localhost, 127.0.0.1, 192.168.1.206; server cert subject=CN=laptop-t8d4hur8.local; agent service Running; shortcuts for https://laptop-t8d4hur8:8443/.

Browser walkthrough as operator jbaker (control mask) — observed and screenshotted#

Not exercised: clicking Allow, view-only input-discard, registry/software tabs, off-subnet. The auto-accept checkbox is stock MeshCentral — tell operators to leave it unticked unless the shift agrees.

Uninstall — verified. Uninstall-RemoteView.ps1 -Force: exit 0, 50 s. Removed the Mesh Agent (-fulluninstall) and MeshCentral service, printed "No Ring Remote View firewall rules found" (this run used -NoFirewall), "UNINSTALL COMPLETE." Confirmed afterward: no services, install root gone, C:\Program Files\Mesh Agent gone, the "Mesh Agent WebRTC Traffic" rule gone, no 8443 listener, shortcuts gone.

Penetration-test items — REMOTE_ACCESS_RUNBOOK.md §8, observed via MeshCtrl#

Rights masks are enforced server-side — the relay itself refuses to route a restricted account, not merely a hidden tab. The full §8 table on a clean VM with a second machine is still owed for items 1, 5, 6 and 8.

v2 — what was verified:

Defect found and fixed in the smoke script. As shipped, it probed the new hostname before DNS had propagated and every probe failed with an opaque exception. Fixed on branch docs/remote-access-guide: waits up to 90 s for DNS, retries the login-page GET for up to 60 s through transient Cloudflare 530/1033 errors, unwraps the real inner exception, and raised the default -BudgetSeconds from 120 to 240. The PASS above is the re-run.

Other verified facts. The Inno Setup GUI wrapper (RingRemoteView.iss) has never been compiled — no ISCC installed, no RingRemoteView-Setup.exe anywhere in the tree; the PowerShell installer is the only proven install path. Multi-homed detection ignores loopback and 169.254.* APIPA addresses. IPv6 caveat: browsing the bare hostname from the laptop itself answered HTTP 401 before any login page, because the name resolved to IPv6 addresses first and userAllowedIP lists only the IPv4 CIDR and 127.0.0.1 — make sure the HMI name resolves to IPv4 for LAN clients, or browse the IPv4 address directly (allowedOrigin permits that). A PowerShell trap, not MeshCentral's: Invoke-WebRequest/ClientWebSocket with a ServerCertificateValidationCallback scriptblock fails non-interactively ("There is no Runspace available to run scripts in this thread") — use curl.exe -k https://127.0.0.1:8443/ or a real browser for a hand check instead.

9.8 Security posture and residual risks#

Defence in depth, any one gate stopping an attacker on its own: (1) the network perimeter — LAN-only (v1), or Cloudflare Access authenticating at the edge (v2); (2) MeshCentral's own accounts — login, force2factor, the panel consent prompt, session recording; (3) the rights mask, enforced server-side (confirmed in §9.7).

Fixed defects (bench 2026-09-04 — read before trusting an unmodified main build):

All three are fixed on branch docs/remote-access-guide (the static gate gained one new assertion for the fix). Verify which branch a given build came from before assuming 2FA enrolment or a plain-hostname browser session will work.

Residual risks — v1. MeshCtrl takes credentials on its command line during provisioning, briefly visible in the process list (console-only, install-time only); the Inno wrapper passes -AdminPassword as an argument — same residual; a site administrator can do everything, and the control is procedural — that credential stays with plant management.

Residual risks — v2 (only where the tunnel is installed). The tunnel token is a standing credential in the service ImagePath (registry) — rotate it in the Zero Trust dashboard if the box is suspect. trustedProxy: "127.0.0.1,::1" means any local process can forge a source IP — accepted only because cloudflared is the sole local client of 8443 on a single-purpose HMI, and force2factor still stands behind it. Cloudflare sits in the trust path (edge-decrypt, re-encrypt to origin) — the Tailscale alternative avoids this if policy forbids a third party. Double authentication is intentional: MeshCentral has no key consuming an Access identity header, so Access is a perimeter, not single sign-on. cookieIpCheck: "lax" forces re-login on a roaming IP move outside its /24 — correct behaviour, not a fault to chase. The v2 install restarts MeshCentral, dropping any live LAN session; Ring and the PLC are untouched.

Still outstanding — a verification gap, not a residual risk. Pen-test items 1 (partial), 5, 6, 8 on a clean two-machine VM; the entire v2 off-site chain (Access policy, off-site smoke, v2 penetration test); whether the Inno Setup wrapper compiles at all.

9.9 Patch policy and licences#

AV/EDR. MeshCentral is widely flagged as a post-compromise RMM tool — support an allow-list request with dist\manifest.json (the SBOM). Concrete example: this laptop's Defender history shows MeshService.exe quarantined 2026-08-20 as RMM tooling; the 2026-09-04 install needed a Defender exclusion for the scratch directory and C:\Program Files\Mesh Agent (removed after). cloudflared.exe is legitimately signed but some EDR flags it by category too — raise both with IT before install day.