Onboarding6 Nov 2026
You run an MSP. With three clients, patching is a Tuesday-evening habit: you know which server hosts the accounting package, which laptop belongs to the managing director, and who to call when an update breaks the printer. At client number ten, that habit stops scaling. Every client has its own exceptions, every technician approves updates a little differently, and when a client asks "are we up to date?", the answer takes an afternoon.
This article is for MSP owners and technical leads who want one patch policy they can run across every client: what to approve automatically, how to roll out in rings, how to handle third-party apps and servers, and how to show a client where they stand. It ends with how we do it in Xcellerate RMM.
TL;DR
- Write the policy once, per device class: workstations, servers and critical servers each get their own approval delay, install window and reboot rule.
- Roll out in rings: your own test devices first, then your internal machines, then pilot clients, then everyone.
- Patch third-party apps with the same workflow as the operating system, and never auto-reboot a server outside a maintenance window.
- Give every client a monthly report: patch status per device, what was installed, what failed and what you deferred on purpose.
Why patching breaks at client number ten
Patching rarely fails because a technician doesn't know how. It fails because the rules live in people's heads. One technician approves everything on Wednesday, another waits a week, a third skips the server of the client who complained about a reboot last year. Nothing is written down, so nothing is consistent, and nobody can show what actually happened.
A patch policy fixes that. It's a short document, and ideally a setting in your RMM, that answers four questions for every device: which updates are approved automatically, after how many days, in which time window, and whether the device may restart on its own. Once those answers are written down, patching becomes a process you can check instead of a habit you hope for.
The policy in one table
Start with device classes, not with clients. Most MSPs need three. The numbers below are an example to adapt, not a rule:
| Device class | Critical updates | Other updates | Install window | Reboot |
|---|---|---|---|---|
| Workstations | Auto-approve after 3 days | Auto-approve after 7 days | Lunch break or end of the working day | Automatic, with a 15-minute warning to the user |
| Servers | Auto-approve after 3–5 days | Manual approval | Maintenance window, e.g. Sunday 02:00–05:00 | Only inside the window |
| Critical servers (business applications, domain controllers, hosts) | Manual approval after testing | Manual approval | Window agreed per client | Manual, with someone available |
Why a delay at all? A few days give the wider community time to report a broken update before it reaches your clients. Why different windows? Workstations are best patched when people take a break, servers when nobody is working.
Then add exceptions per client, not per device: a client whose staff works night shifts gets a different workstation window; a client with a fragile business application gets its server in the critical class. Write every exception down, with the reason.
Rings: let your own devices go first
An update ring is a group of devices that receives updates at the same stage. A simple MSP setup has four:
- Test ring: a few devices of your own that get every update first.
- Internal ring: the rest of your own office.
- Pilot ring: one or two clients who are tolerant, well documented and know they are the pilot.
- Broad ring: everyone else.
Each ring waits for the previous one. If an update breaks something in the test or internal ring, you block it before it reaches a client. Rings also give you a clear answer when a client asks why they didn't get an update on day one: it's deliberate.
Third-party apps are the real gap
Operating-system updates are the easy part: Windows, macOS and Linux each have their own update mechanism, and most RMMs handle them. The gap is everything else: browsers, PDF readers, Java, Zoom and the other applications users install and nobody updates.
Treat them like the operating system: the same approval rules, the same rings, the same windows. Keep a list of the third-party applications you support per client, and decide what happens to the rest (remove them, or leave them to the client with a written note).
Servers: never reboot without a window
The fastest way to lose a client's trust is an unplanned reboot of the server that runs their business application in the middle of the day. Three rules:
- No automatic reboots on servers outside an agreed maintenance window.
- Agree the window with the client in writing, in the client's time zone.
- For critical servers, have someone available during the window to check the services afterwards.
Proving it: the report your client sees
A policy only builds trust when the client can see it work. Once a month, send each client a short patch report:
- Patch status per device: the share of applicable updates that is installed.
- What was installed in the last month, and what failed.
- What you deferred or blocked on purpose, and why.
- Devices that need attention: offline for weeks, waiting for a reboot, or out of support.
Go through it in your monthly or quarterly review. It turns patching from an invisible cost into a service the client can see.
How we do it in Xcellerate RMM
Xcellerate RMM is our RMM: source-available under the FSL, on your own servers or in our EU cloud. Patch management is part of the source-available core. This is how the policy above maps onto it:
- Operating systems and third-party apps: Windows Update, apt/yum on Linux and softwareupdate on macOS, plus a catalogue of popular third-party applications that follow the same approval and scheduling workflow.
- Patch policies per group: auto-approval, deferral periods, maintenance windows and reboot behaviour, set once and attached to a group. Named patch strategies with their own schedules and rules can be attached to any agent or group.
- Approve, defer or block in batch: review pending patches across the fleet and change their status in one operation.
- Update rings: choose which update ring each tenant follows, so early builds stay away from production clients.
- Per-device detail and history: what is installed, pending or failed on every device, and a log of every installation with its result and time.
- Compliance score and reports: the percentage of applicable patches installed per device or group, an exportable compliance report to share with the client, and an alert when the score drops below a threshold you set.
The patch management feature page gives the overview, and the patch management documentation walks you through creating a policy step by step. Want to run it on your own servers? The installation guide covers the self-hosted setup.
Do you also run a PSA next to your RMM? Xcellerate RMM and Xcellerate OPS are two separate products, and a ready-made connection between them isn't available yet. All-in-one RMM + PSA or best-of-breed helps you decide what your stack needs.
Try the policy on your own fleet: free forever on your own servers, or a 14-day Cloud trial. Get started for free
