RMM at a glance
The other pages under RMM besides Policies - devices, the agent's own self-update channel, the shared third-party patch catalog, the script library, alerts, and device approval - each shown once, on an instance that has one policy and zero enrolled devices.
Set up RMM banner
A one-time card offering the guided setup wizard: install the agent, then settle the same handful of fleet-wide decisions this KB's policy walkthrough covers one page at a time. Dismissing it with Not now hides it; it does not change anything already set.
Install agent
Opens the same Add a device dialog the policy walkthrough uses to reach a client's install key: EXE, MSI, and Linux installer downloads, plus a masked per-client install key.
Roster / Unapproved tabs
Roster is every approved device. Unapproved is where a device waits if Device Approval (Settings > RMM) is set to Manual, or to Automatic above a confidence score and a device misses it. This instance reads Unapproved (0): nothing is waiting.
Search and filters
Search by hostname or serial, narrow to one client, filter by status, or open Filters for the rest. All four apply to the Roster tab only.
Device roster
Device, Health, Client, Agent, and Last check-in, sortable on every column. It reads "No devices match these filters" here because this tenant has zero enrolled devices, not because anything is misconfigured.
Policies list
New Policy
Opens the same policy-creation form this KB's set-up-a-policy walkthrough builds end to end: name, scope, patching, monitoring, and agent settings.
Workstations, standard
The one policy this instance has, exactly as the walkthrough leaves it: scope Tagged Bluebird Dental, no devices carrying that tag yet, priority 0, status Enabled.
Agent updates: the channel that updates itself
Rollout rings
Canary, Early, and Stable, each reading Automatic with no target version yet on this instance. Pause freezes a ring so it offers nothing until resumed. Roll back clears the ring's target version and pauses it in the same step, so it stops offering that version; an agent already on the newer build keeps it, since it refuses to install anything older than what it already has.
Which fleet goes first
This fleet is set to Wait 24 hours after other fleets report clean, the shipped default: the stable ring moves to a new version 24 hours after this portal registers it, counted from the moment the fleet that goes first starts running it, and only if no device anywhere has reported that version and fallen back. Update this fleet immediately is the other option, meant for the one portal whose own machines get watched first. Every build is signed before it ships and verified on the device, so nothing here depends on someone approving a file.
Registered releases
This portal ships agent 1.7.10, listed once per platform (linux-amd64, windows-amd64). A version is registered once: rebuilding the same code produces a new signed file with a new timestamp, but the portal compares the code, not the file, and leaves the existing entry alone rather than adding a duplicate. Only different code under a new version number becomes a new row.
Patch Catalog: the shared third-party app list
Add application
Opens the form for adding an app that is not already in the catalog, shown in full further down this page.
Test / Push / Override
Test and Push are per-row actions; Override forks a platform-default row into an editable copy scoped to this MSP, the same move this KB's policy walkthrough uses to keep Chrome and Zoom always current.
Script library
Clear temp files
This library is yours: a script saved here runs on any device you manage, there is no client to pick and no per-client copy. This one is a PowerShell script, risk Standard, version v1. Every run goes through the same signed execution plane as any other remote action.
Alerts
Alerts
Open monitoring alerts across every managed device, filterable by client, status, severity, and time frame, with Severity, Client, Alert, Entity, and Raised columns. It reads "No alerts match these filters" here because no device on this instance has tripped a monitoring threshold, not because alerting is off.
RMM Settings: Device Approval
Device Approval
The one setting under RMM's own Settings page, and the same page this KB's policy walkthrough leaves on Automatic: every device that enrolls is approved with nothing to wait on.
Adding an application that isn't in the catalog
Add application form
Two fields are required: the display name techs see, and the exact winget package id (letters, digits, dot, underscore, plus, and hyphen only, e.g. Google.Chrome). Nothing here stores a command line; the install script is assembled server-side from the id, which is why the id has to be exact. Fill with Elise proposes an id from the name typed into Display name; it only fills the field, and nothing saves until Add application is pressed.
Pushing one app to many devices at once
Install on many devices
Push queues the install on every device the chosen target reaches: a client, a tag, or the devices governed by a policy. Each device gets its own signed command and its own audit row. A pending device, or one with execution turned off, is skipped rather than silently failing later.
A script's parameters
Parameters
Add parameter, or Insert variable to reuse a built-in or your own saved value. This script's one parameter, retentionDays, reads underneath as EZDA_PARAM_retentionDays: the exact environment-variable name the script itself reads, shown live as soon as the parameter is named. Nothing is pasted into the script text; the value is resolved per device (and, for a client-scoped variable, per client) at run time.
Variables: built-in list and your own
Built-in variables
This card lists every value the portal already knows: device fields like hostname, serial, and last check-in, two agent fields, four client fields, your own company name, and two portal fields, each shown with what it looks like on a real machine. Search narrows the list by name or by meaning, Group narrows it to just device, client, agent, company, or portal values, and Usable in narrows it to what a script or an automation can actually read. Copy a name straight from here, or add it to a script as a parameter.
Variables
This is where you add your own: a Key scripts and automations reference by name, a Label for people, a Type (Text, Number, Yes/No, or Secret), and a Scope, Global for one value everyone shares or Client-specific for its own value per client. NORTHWIND_SUPPORT_LINE is this instance's one custom variable, a Text value at Global scope reading +1-555-0100, allowed for Scripts and Automations. A script parameter or an automation step references it by name, and the portal resolves the value at run time rather than storing it in the script text.
Tokens the portal fills in when it delivers the menu
A second, separate card below the tray's own device-filled tokens. These ${COMPANY_NAME}, ${SUPPORT_EMAIL}, and ${SUPPORT_PHONE} tokens are filled in by the portal itself when it delivers the tray menu to a device, from your company's brand and support details, not by the device and not the variables above it on this page.
Why it works this way
Agent updates install themselves on purpose: this page is only the brake (Pause, Roll back) and the one lane choice (go first or wait 24 hours), never an upload-and-approve flow.
The patch catalog never stores a command line for a third-party app, only its winget package id; the install script is assembled server-side from that id, which is why the id has to match exactly.
The script library has no client picker and no per-client copy: a script saved here runs on any device you manage, the same way this KB's policy walkthrough scopes by tag rather than by client.
A script parameter pointed at a variable is never pasted into the script text; the portal resolves the value for that device (and its client, for a client-scoped variable) at run time and hands it to the script as an environment variable named EZDA_PARAM_ plus the parameter name.
Questions this page answers
What does the Agent updates page do?
It shows you an update channel that runs itself, and gives you the handful of controls that steer it. Each time this portal starts, and once a day after that, it registers the signed agent builds that shipped inside it and points the stable rollout ring at that version. No one approves a build, uploads a file, or presses a button to make an update happen. Your devices pick the new build up on their next check-in, verify its signature themselves, install it, and fall back on their own if it fails to start. This page is where you watch that, where you choose whether this fleet takes a new build immediately or waits 24 hours behind the fleet that goes first, and, if a build goes bad, where you halt it.
What do Pause, Roll back, and the update lane do?
Pause freezes a ring: devices on it are offered nothing at all until you resume it. Roll back clears the ring's target version AND pauses it in the same step, so the ring stops offering that version and automatic updating cannot simply re-point it at the next check. Neither one moves a device backwards: a machine already running the new build keeps it, because an agent refuses to install an older version than the one it has. Resume is the re-arm: once you press it, the ring goes back to being pointed at the shipped version automatically. Devices sit on one of three rings, canary first, then early, then stable, which is where nearly everything lives. The update lane is the third control, and it is not a stop: it decides whether this whole portal is the fleet that goes first or one of the fleets that waits. "Update this fleet immediately" points the stable ring at a new version the moment this portal registers it. "Wait 24 hours after other fleets report clean" holds a new version for 24 hours, counted from the moment this portal registered it, and advances only if no device has fallen back off that version. The same image reaches every portal at once, so that clock starts when the fleet in front begins running the version. Every portal ships on the wait; the one whose own machines you watch is the one to set to go first.
If nobody approves an update, what stops a bad one?
Three things, and none of them need you. First, signatures: each build is signed by our release key in a hardware-backed vault before it ever ships, and the agent on the device checks that signature against the key baked into it, so an unsigned or tampered build is refused on the endpoint. Second, order: one fleet is set to go first, and every other fleet holds a new version for 24 hours from the moment it registered that version, so the fleet in front runs the build for a full day and a bad one shows itself in that window before it reaches anybody else. Which fleet goes first is a choice somebody makes, on this page, under the rollout rings: set "Update this fleet immediately" on the portal whose own machines you watch, and leave every other portal on the wait. Third, the devices themselves: an agent that does not come back healthy after an update returns to its previous build and reports it, which halts the rollout for everyone else here and raises an alert naming the version. Your job is only to decide whether to pause or roll back once you see that.
Why does a rebuild not add a new entry to the list?
Because it is not a new release. The list shows versions, not builds. A version is added once. Build the same code again and the file must be signed again. A signature holds the time it was made, so the file is never the same twice. The code is. The portal compares the code, not the file. When the code matches, it keeps the entry it has and notes this in the system log. That is not a warning. One thing is refused: the same version with different code in it. Devices may already run that version, and the file they get must match what was registered. To ship changed code, raise the version number.
What is the script library?
This library is yours, and a script you save here runs on any device you manage - there is no client to pick and no step that saves a script to a client. Save it once, then run it on a device from that device's own page or put it on a schedule, instead of pasting code onto each machine. Every run goes through the signed execution plane.
Can a script use variables?
Yes. Add a parameter to the script and point it at a variable. When the script runs, the portal looks up the value for that device and its client and sends it with the run. Your script reads it as an environment variable named EZDA_PARAM_ plus the parameter name. Nothing is ever pasted into the script text.
How do I push an app to many devices at once?
Use the Push action on the application's row in the catalog and choose what to target: a client, a tag, or the devices governed by a policy. Each device gets its own signed command and its own audit row, so you can see per-device what was queued and what it did. Only approved, enrolled devices are queued - a pending device or one with execution turned off is skipped rather than silently failing later.
How do I add an app that isn't in the catalog?
Click Add app and give it two things: the application name you want techs to see, and the exact winget package id (for example Mozilla.Firefox). We never store a command line - the install script is assembled server-side from the id, which is why the id has to be exact and why only a known-good character set is accepted. If you know the name but not the id, "Fill with Elise" proposes an id from the name; it is a suggestion in the field, and nothing is saved until you confirm it.
Where do I see the built in variables?
Open the Variables page. The Built in variables card lists every value the portal knows already. It covers the device, the client, the agent and this portal. Search it by name or by meaning. Then copy a name, or add it to a script as a parameter.
What are variables for?
Variables are named values resolved at run time - in automations, and in script runs launched from a device's own page - an install path, a server name, a threshold, so the same value works across clients without editing anything by hand. Define a value once and reference it by name wherever it's needed.
Was this helpful?