Manage your RMM policies beyond the basics
A tour of the Policies area that set-up-a-policy does not cover: defaults, per-client assignment, tag exceptions, and the General, Patching, Maintenance, and Permissions tabs.
What you will have
- See what a brand-new computer gets before anyone has set anything up, and change what a default does.
- Give one client a different policy for one kind of machine, and read what a blank cell in that grid actually means.
- Read a policy's device type and owner, and see why the type cannot change once the policy is made.
- Rename a policy and find where Delete lives.
- Create a policy scoped to a tag, and see the door that adds devices to it.
- Turn off updates over a metered connection, for both Windows updates and third-party apps.
- Confirm that patch times and app-update times run on each device's own local clock, not yours.
- Confirm that an app update never restarts a computer on its own.
- Set a maintenance window that suppresses alerts during planned work.
- Read the full list of commands a policy arms for automations and the AI operator.
- See two tag policies side by side and know which one wins when a machine carries both tags.
Why it works this way
A "blank" cell on the Clients tab is not empty: it is a dropdown already showing Default (policy name). Blank means nobody has picked something different for that client, not that nothing is set.
A policy's device type is offered only once, at creation, because changing it later would quietly move every device the policy governs onto rules written for a different kind of machine. Making a second policy is the only door.
Delete lives inside the Actions menu next to Save, not as its own button, because removing a policy is far rarer than editing one.
Steps
Open RMM > Policies.
This lands on the Defaults tab: one row per device type, each pointing at the policy every client falls back to until somebody says otherwise. On this instance every count read 0 devices and 0 of 0 clients, because nothing had been assigned yet - the defaults exist and are ready the moment a device shows up.
Open RMM > Policies. Click a default policy's name, such as Default Workstation Policy, to change what it does.
The name is a link, not a label: opening it lands on that policy's own editor, with every tab (General, Monitoring, Patching, and the rest) open for editing. There is no separate 'edit the default' screen - a default is a policy like any other, just one the Defaults tab points at automatically.
Click a default policy's name, such as Default Workstation Policy, to change what it does. Click the Clients tab.
One row per client, one dropdown per device type. Every dropdown here already reads a name: Bluebird Dental's Workstation cell said 'Default (Default Workstation Policy)', because nobody had given that client anything different yet.
Click the Clients tab. Read one client's dropdown, such as Bluebird Dental's Server cell.
It read 'Default (Default Server Policy)' with 'no devices' underneath. That is what a blank assignment looks like: the box always names a policy, and when nobody has overridden it, the policy it names is the default for that type. Picking a different policy from this same dropdown gives that one client and type something else, effective immediately.
Read one client's dropdown, such as Bluebird Dental's Server cell. Click the All policies tab, and read the Owner column.
Every row on this instance said MSP: your team made every policy that exists here, and your team edits it. The column is already on screen for the day a co-managed client can author their own policy - that row would say the client's name instead.
Click the All policies tab, and read the Owner column. Click New Policy, name it, and pick its type.
Naming it 'KB walk - policy sandbox' and leaving Type on Workstation showed the exact line 'Set once, when the policy is made' next to the Type field - the only point in a policy's life where its device type is choosable. Typing a new tag name, 'KB walk device tag', into the tag picker offered a Create option that made the tag on the spot, with 'No devices carry this tag yet' underneath. That Create row is the only part of this form that needs a permission of its own, Tag Defaults create; without it the picker offers only tags that already exist, and the tag has to be made in Settings first. The Priority field's own hint - 'Only used when two tag policies land on the same device. The higher number wins.' - is the same rule the Tags tab uses to settle a tie.
Click New Policy, name it, and pick its type. Open the new policy's General tab and its Actions menu.
General holds every shell fact about the policy - Name, the tag it targets plus an Add devices door, Priority, and Status - with one Save for all of them. Actions, next to Save, opened to show Delete policy as the only item: deleting falls back every device the policy governs to whatever is next in priority, or to the default for that type - another tag policy first, then the client's own assignment for that device type, then the MSP default for that type (src/lib/domains/device-policy/resolve.ts at 4b5e59a2f, the selectPolicyForDevice resolution order: TAG EXCEPTION, ORG ASSIGNMENT, MSP DEFAULT).
Open the new policy's General tab and its Actions menu. Rename the policy and click Save.
Typing 'KB walk - policy sandbox (renamed)' into Name and saving updated the page's own heading immediately and raised a 'Policy saved.' toast - the same Name field is the retarget door too: picking a different tag here moves the policy to different machines without touching anything else.
Note: Delete is permanent: devices on a deleted policy fall back to a lower-priority or default policy, they are never left with nothing.Rename the policy and click Save. Click Add devices next to the policy's tag.
This is the second way a tag policy reaches machines: instead of tagging devices one at a time on their own pages, Add devices opens a search over every device and applies the tag to whichever ones are picked, right there. This tenant carries no devices yet, so the dialog read 'No devices match' - the honest state of a policy pointed at a tag nothing wears.
Click Add devices next to the policy's tag. Open the Patching tab and find Skip on a metered connection.
This sits under the OS-patching schedule, right next to Install day and Install time, both of which run on 'each device's own local time', not yours. Left on its shipped default of On, a laptop tethered to a phone at its install time waits for a real connection instead of pulling a Windows update over someone's data plan.
Open the Patching tab and find Skip on a metered connection. Scroll to the Software patching (third-party apps) card and find Scan time.
Third-party patching is its own card, separate from OS updates, with its own schedule: 'Scan time' reads Default (17:00) in 'each DEVICE's own local time, not yours', the same rule the OS side uses. The 'Next three install times' box just above spells this out further: it shows the schedule in your own time zone for reference, but notes each device uses its own clock.
Scroll to the Software patching (third-party apps) card and find Scan time. Read the 'When the app is open' setting at the bottom of the same card.
Four choices - leave it open and try again, ask the person, close it and update anyway, or (the shipped default) leave it open and retry next time - and none of them is a restart. This card has no restart section of its own: the FAQ answer this confirms is that an app update can never restart a computer by itself. Any restart an app update does need joins the same queue a Windows update would, governed by the Patching tab's own restart settings.
Read the 'When the app is open' setting at the bottom of the same card. Open the Maintenance tab, click New Window, fill it in, and click Save window.
Naming it 'KB walk - overnight window', picking Sunday, start hour 2, a 3-hour duration, and leaving Suppress alerts on Yes, then saving, put the window straight into the list: 'KB walk - overnight window, Sunday at 02:00 for 3h, Yes, Enabled'. A maintenance window is only a schedule and an alert switch - it does not run anything by itself; it exists so planned disruptive work (like a patch reboot) does not page anyone while it happens.
Open the Maintenance tab, click New Window, fill it in, and click Save window. Open the Permissions tab and read Armed command types.
A checklist of every command an automation or the AI operator is allowed to send to a device under this policy - from plain reads like device.state.read up to device.reboot, device.script.run and device.fs.upload - every one unchecked by default on a new policy. The hint is exact: 'Everything else is refused.' A command not armed here cannot be run against these devices no matter what asks for it.
Open the Permissions tab and read Armed command types. Click the Tags tab to see every tag-scoped policy together.
Both tag policies on this instance now showed up side by side: 'Workstations, standard' tagged Bluebird Dental, and the new 'KB walk - policy sandbox (renamed)' tagged KB walk device tag - same device type, same priority (0), neither one's tag carrying any devices yet. The page's own hint states the tie-break rule plainly: 'When two tag policies land on one device, the higher priority wins.' A device that somehow carried both tags would follow whichever policy's Priority number, set on its General tab, was higher; if the numbers matched, the resolver still picks one and keeps using the same one, so a machine's assignment never flips on its own.
Click the Tags tab to see every tag-scoped policy together.
Other ways to do this
The Set up RMM wizard
The Devices page offers a one-time 'Set up RMM' card that walks the same handful of fleet-wide decisions - approval, patch day, tray branding - in one guided pass instead of tab by tab.
A client's own Devices tab
The same four device-type rows shown on the Clients tab also sit at the top of that one client's Devices tab, so a tech already looking at a client can set their policy assignment without a trip back to RMM > Policies.
If it did not work
- If a client's cell on the Clients tab will not change, check that a policy of the matching device type actually exists and is enabled - a disabled or missing policy cannot be picked.
- If a tag policy does not seem to be reaching a machine, check the tag count on the Tags or General tab first: a tag with 'no devices' carrying it, like both tags in this walkthrough, means the policy is real but is not reaching anything yet.
- If a command an automation tries to run is refused, check the Permissions tab first: an unarmed command type is refused for every device under that policy, no matter what asks for it.
Questions this page answers
What does a new computer get?
One of the four policies on this tab, based on what kind of machine it is. A laptop or desktop gets Default Workstation Policy. A server gets Default Server Policy. A Mac gets Default Mac Policy. A Linux box gets Default Linux Policy. You do not have to set anything up for that to happen.
How do I change what a default does?
Click its name. That opens the policy, and every tab in it is yours to edit. The change reaches every machine on that policy. If you want the change for one customer only, do not edit the default. Make a new policy and give it to them on the Clients tab.
How do I give one customer a different policy?
Find their row, find the column for the kind of machine, and pick the policy. It takes effect right away. You can do the same thing from that customer's own Devices tab, where the same four rows sit under the page title. They are the same rows either way.
What does a blank box mean?
It means that customer gets our default for that kind of machine, and the box says which policy that is. Blank is the normal state. Set it back to the default line any time to undo a change.
What is the Owner column?
Who the policy belongs to. Today every policy says MSP, which means your team made it and your team edits it. Later a co-managed customer will be able to write their own, and those will say their name here.
Why can I not change a policy's type?
A policy is for one kind of machine, and you pick that when you make it. If the type could change later, every computer on the policy would quietly move to rules written for something else. To get the same settings for another kind of machine, make a second policy.
Which policy does a computer end up with?
We check three things in order. A tag policy on that machine wins first. If there is none, the policy set for its customer and its kind of machine. If there is none of that either, our default for that kind of machine. Only one policy applies, never a mix.
How do I rename, retarget, or delete a policy?
The General tab holds the policy's name, its Applies to group (Type, Owner, Tag, Also assigned), priority, and enabled status. Edit any field and Save. Delete lives in the Actions menu. Deleting a policy does not leave devices unmanaged. Each device falls back to the next winner in order: a tag, then the client's own assignment for that type, then the MSP default for that type.
What happens if a laptop is tethered to a phone at its install time?
With "Skip on a metered connection" on (the default) it does not download anything - a cumulative update over somebody’s data plan is a real cost. It patches at its next scheduled time, or at its next check-in if "Patch a device that missed its time" is on.
The scan and update times: whose 5pm is that?
The clock on each device. A machine scans and updates at that hour where it sits. So a fleet spread over four time zones all patch at 5pm local. If a device has not told us its time zone, we use the one set for its client. If that is missing too, we use the default for your portal, and we log it. A machine patched on a guessed clock is worth knowing about. Dates in the rest of the portal use your own time zone. The patch times do not.
Can an app update restart a computer?
Only by the same rules Windows updates use. That is why this card has no restart settings of its own. Most app updates need no restart at all. When one does ask for one, it joins the same queue a Windows update would. The person is asked, or told, or the machine just restarts. It follows the two restart choices on the OS patching card. The limit on how often they can wait, the deadline, and the rule that servers only restart if you opt them in: all of it applies. There is no second way to restart a machine, and no separate countdown for apps.
What are maintenance windows for?
A maintenance window is a scheduled period when disruptive work (like patch reboots) may run for the devices under this policy. Suppress alerts during the window so planned reboots do not page anyone.
What are armed command types?
These are the specific agent commands that automations and the AI operator are allowed to run on devices under this policy. Anything not armed here is refused, no matter what asks for it - the policy is the guardrail.
What is an RMM policy?
A policy is a set of rules. It sets monitoring thresholds, patching, agent settings, and which commands are armed. It governs your managed devices. Each device follows exactly one policy. First choice: a policy that targets a tag the device carries. Next: the policy assigned to its client for that device type. Last: the MSP default for that type.
Which policy applies when more than one could match this device?
A device is governed by exactly one policy at a time, chosen in order: a policy targeting a tag the device carries wins first (if two tag policies match, priority breaks the tie, then id). Otherwise, the policy assigned to the device's client for that device type applies. If neither exists, the MSP default policy for that type applies. Whichever policy wins supplies every field for the device; fields it does not set fall through to the shipped default.
Make a policy for some of a client's devices
Two steps, both on the policy. First, on "Applies to", pick or make a tag in the Tag box - making a new tag needs the tag defaults permission. Second, once the policy is saved, click "Add devices" next to the tag and pick the machines. That puts the tag on them for you, so you never open each device by hand. The count under the tag is how many devices carry it today. A policy on a tag with no devices is not doing anything yet.
Was this helpful?