Remote monitoring and management
All notes
Everything here, grouped by subject.
Practical guidance, vendor comparisons and no substitute for contractual or security advice.
What this covers
From the queue nobody reads to the console that reaches every client
Eight sections, in the order the work actually runs: what the platform does, getting the noise down, onboarding an estate, patching, automation, securing the tool itself, and the commercial side that decides whether any of it is sustainable.
What it does
The machines belong to somebody else, and the gap between what you control and what you are accountable for shapes everything.
6 notes →Getting the noise down
A platform at default settings produces more alerts than anybody will read, and an unread queue looks like monitoring.
7 notes →Onboarding an estate
The machine count a client gives you is wrong. Finding the real one before the contract is better than after.
7 notes →Patching
A patch installed and pending reboot protects nothing. That gap is where compliance quietly fails.
6 notes →Automation
A script runs against every client at once. There is no partial failure and no time to notice.
6 notes →Securing the tool
An internal compromise affects one organisation. A provider compromise affects everybody they serve.
7 notes →The commercial side
Two or three clients usually consume most of the capacity, and the pricing model decides whether that is visible.
7 notes →Reference
The end state as a description, the twelve failures, and the order to do things in.
4 notes →If the queue is unreadable
Three things that cost a week and change the service
Count, then tune the top three
Alerts raised, opened, actioned, and arriving out of hours. A small number of check types produce most of the volume, and fixing those usually removes most of it.
Reconcile agents against the directory
Nobody looks for absence. A machine without an agent is invisible from the console and looks identical to a healthy one, which is how estates acquire unmonitored machines.
Scope script execution by client
Running a script across estates is code execution with high privilege on machines you do not own. Most incidents in this category are a correct script with a wrong scope.
All 50 notes
All fifty notes, by subject
- What RMM Actually Does
- Managing Estates You Do Not Own
- RMM, PSA and the Tools Around It
- What It Is Not: Four Adjacent Things
- The Questions to Settle Before Deploying
- Build, Buy, or Use What the Vendor Gives You
- Why the Default Configuration Is Unusable
- Counting Your Alerts Honestly
- Thresholds That Mean Something
- Alert Fatigue and What It Costs
- Tuning Per Client, Not Per Product
- What to Stop Monitoring
- Measuring Whether Tuning Worked
- Onboarding a New Client Estate
- Discovery: Finding What Is Actually There
- Agent Deployment and the Machines You Miss
- Monitoring Templates and Keeping Them Few
- Documentation That Survives Staff Turnover
- The First Thirty Days With a New Client
- Offboarding: Removing Yourself Cleanly
- Patch Management Without Breaking Things
- Ring Deployment and Why It Is Worth It
- Third-Party Application Patching
- Reboots, and the Conversation Nobody Wants
- Reporting Patch Compliance Honestly
- When a Patch Causes the Outage
- Scripts: What to Automate First
- The Script Library and Its Decay
- Testing Automation Before It Runs Everywhere
- Self-Healing and Its Limits
- When Automation Hides a Problem
- Who Can Write and Run Scripts
- The Tool That Fixes Can Also Break
- Securing the RMM Itself
- Credential Handling Inside the Platform
- Supply Chain: Your Vendor Is Your Exposure
- Separating Monitoring From Administration
- Detecting Misuse of Your Own Tool
- What To Do If the Platform Is Compromised
The short version
Measure what the client notices
Not alert volume, but how often a client tells you about an outage before your monitoring does. Tune until every alert is read, verify rather than assume, and run the console as the privileged system it is.