An RMM agent is a small program with a lot of power: it can run scripts as SYSTEM, install software, and reboot machines. Pushing it to every device on day one is how you learn, all at once, that it conflicts with the client's old antivirus or eats the CPU on the thin laptops.
Rings are the fix. Deploy to a small group, watch, widen, repeat. This post covers how to size the rings, what to verify between them, and the specific things that go wrong.
Prepare the package and the exclusions
Before any deployment, get the installer into a form that runs silently and tags the device to the right client site. Most RMM vendors provide an MSI or PKG with a site token baked in or passed as a parameter. Test it on a clean VM and on a machine that mirrors the client's standard image.
Then handle the two things that most often break an agent rollout: the existing security product and the outbound firewall. Add the agent's process and install folder to the antivirus exclusions, and confirm the agent's outbound ports and hostnames are allowed from every site, including the guest VLAN if laptops roam onto it.
- Silent install string documented and tested (for example msiexec /i agent.msi /qn SITEKEY=...)
- Antivirus and EDR exclusions in place for the agent path and service
- Outbound allow rules for the agent's endpoints on every firewall
- Uninstall string tested, so you can back out
- Naming and grouping convention decided: site, department, device type
msiexec /i "C:\\Temp\\agent.msi" /qn /norestart SITEKEY="xxxxx" /l*v C:\\Temp\\agent-install.logRing 0 and Ring 1: your machines, then the friendly ones
Ring 0 is one or two devices you control at the client, ideally one desktop and one laptop. Install, confirm the agent checks in, run a harmless script, take a remote session, reboot from the console. If any of those fail, stop and fix it here.
Ring 1 is the people who will tell you when something feels off: the office manager, the one power user in finance, someone who travels. Five to ten devices. Leave them alone for two working days and watch CPU, memory and the agent's own logs. Ask them directly whether anything got slower.
- Install on Ring 0, verify check-in, script execution, remote control, reboot
- Install on Ring 1 through your deployment tool, not by hand, so you test the delivery path too
- Wait 48 hours. Check agent CPU time and any crash logs
- Confirm every Ring 1 device appears in the correct group with the correct name
Get-Service | Where-Object {$_.DisplayName -like '*Agent*'} | Select-Object Name, Status, StartTypeRing 2 and Ring 3: departments, then everyone
Ring 2 is a whole department or a whole small site, chosen so that a problem affects a group you can walk over to or call directly. Deploy on a Monday morning, never a Friday. Watch the helpdesk queue for the next two days for anything that mentions slowness, pop-ups or login delays.
Ring 3 is the rest. Even here, throttle. Most deployment tools let you stage by percentage or by group; use it. And keep a list of the devices that do not receive the agent: machines off the domain, kiosks, that laptop that lives in someone's car. Those get a manual install or a decision to leave them unmanaged, written down.
Verify coverage and close the loop
A rollout is done when the RMM device count matches the inventory from discovery, minus the documented exceptions. Pull both lists and diff them. Any device in the network scan but not in the RMM is either unmanaged on purpose or a mistake.
Then turn on the boring things in stages too: patch policy, monitoring thresholds, scheduled maintenance. Enabling every policy on the day the agent lands is the second most common way to flood the helpdesk. If you want someone to sanity-check a rollout plan before it goes to a few hundred devices, RackLedge does this regularly.
- RMM device count equals discovered inventory minus documented exceptions
- No duplicate device records from renamed or reimaged machines
- Every device in a group that has an owner and a patch ring
- Agent version consistent across the fleet
- Uninstall tested once more on a live device, so rollback stays real
Frequently asked questions
How long should the whole rollout take?
For a few hundred devices, two to three weeks. The waiting between rings is where you learn things, so do not compress it.
What about devices that are rarely online?
Deploy to them by hand when they appear, or use a login script that installs on first connection. Track them as a named exception list so they are not simply forgotten.
Should the old RMM agent be removed first?
Yes, on each ring, before installing the new one. Two agents fighting over patching and reboots is worse than either alone.
Takeaway
Staged rings cost a couple of weeks and save a month of cleanup. Test the package, exclude it from the security stack, deploy small, wait, widen. Finish by diffing the RMM against the real inventory so nothing is left unmanaged by accident.