What the RMM pages show

Ask Elise

Find: "List the devices for Acme Dental" returns each device's name, type, OS, last seen and online status. Add up: "Show RMM health for every client over the last 30 days" returns offline devices, patch compliance, pending reboots, open alerts and automated repair results for each client. Report: "Diagnose the front desk laptop and tell me what looks wrong" reads its recent errors and health issues and suggests next steps, and it never runs anything on the computer. Change: "Push Google.Chrome to all of Acme Dental's devices" or "Give Acme Dental the Front desk laptops policy for workstations" shows a card and waits for your approval, and a push over 250 devices is refused whole. Deleting a device is gated, so Elise files it in Review > Gated Actions for someone else who holds that permission to release.

You would rather ask than click through the pages.

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, so its devices get nothing new until you press Resume. Roll back clears the ring's target and pauses it, so updates cannot set it again alone. Neither one moves a device back, because an agent will not install an older build. Devices sit on three rings: Canary, Early, then Stable, where most live. The update lane picks when Stable gets a new build: Update this fleet immediately, or Wait 24 hours after other fleets report clean. A Held build stays off Stable until a silent device checks in again or someone presses Mark clean.

If nobody approves an update, what stops a bad one?

Three things stop a bad update, and none of them need you. First, each build is signed before it ships, and the agent checks the signature, so a changed build is refused. Second, one fleet goes first and the rest wait 24 hours, so a bad build shows up there, and you pick that fleet with the update lane. Third, an agent that does not come back healthy returns to its old build and says so, which stops the rollout and raises an alert. A device that takes a build and goes quiet is caught too: after 60 minutes by default the version shows Held on the Version health card, and stable skips it until the devices check in again or someone presses Mark clean. You can find out why, then Pause or Roll back.

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. Its four sections are listed down the left side, and one shows at a time. Built-in variables opens first and lists every value the portal knows already. Search it by name or by meaning, then copy a name or add it to a script as a parameter. The variables you make yourself are in the Variables section. A link to a section opens that section.

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.