Set up an RMM policy
Walk RMM > Policies as it stands today: the four default policies every instance ships with, one new policy of your own built end to end (monitoring threshold, patch approvals, the install schedule, both restart choices, the repair ladder, third-party apps, agent settings and one armed command), giving that policy to one client for one device type, reading the assignment back on the client's own record, and the two places a real machine picks it up.
What you will have
- See the four policies a fresh instance already ships with, one per device type, and that a device follows exactly one policy at a time.
- Create a named policy, and know which of its fields are set once and which can change later.
- Set a monitoring threshold and see the shipped default sitting behind every field you leave blank.
- Set the patch approvals table by severity and update class, and know what the wait in days is for.
- Read the install schedule and both restart choices in the product's own words, including what a server does differently.
- See the exact ladder of repairs run on a failed update, and what decides whether a ticket opens at the end of it.
- Arm one agent command and know that everything not armed is refused.
- Give the policy to one client for one device type, and read that same assignment back from the client's own record.
- Find where a real machine would enroll, and the one fleet-wide decision that governs whether it is approved.
Why it works this way
A device is governed by one policy, never a blend of several. A policy targeting a tag the device carries wins first, then the policy its client was given for that device type, then the default for that type. Whichever policy wins supplies every field, and a field it does not set falls through to the shipped default.
A failed update is not escalated straight to a ticket. It is diagnosed first, and one specific repair from a fixed list is run before the update is tried again, up to three times a day for that one update on that one device.
A ticket only opens once every retry for that update has been used up and it still will not install, and only if the policy's ticket dropdown is on. Turning it off does not hide the problem: the device and its alert still show it, only the ticket stops.
Device approval is one decision for the whole fleet, not a per-policy setting: every device approved on enrollment, only devices at or above a confidence score, or a tech approving each one by hand.
Nothing pages anyone by default. The monitoring thresholds a policy sets are deliberately conservative, and which severities actually notify someone or open a ticket is its own decision, made once for every device alert.
Steps
Open RMM > Policies.
The menu item lands on the Defaults tab, and the first thing on it is the answer to "what does a brand new computer get?". Four policies ship with the instance, one per device type: Default Workstation Policy, Default Server Policy, Default Mac Policy and Default Linux Policy. A laptop or desktop follows the first, a server the second, a Mac the third, a Linux box the fourth, with nothing set up by anyone. Each row also carries two honest counts, Devices on it and Clients on it, both reading 0 on this instance because nothing has enrolled yet. A device follows exactly one policy at a time, never a blend: a policy that targets a tag the device carries wins first, then the policy its client was given for that device type, and failing both the default for that type. The line under the table says the same thing in one sentence: every client falls back to these, and to change what one of them does you open it and edit it.
Open RMM > Policies. Click New Policy on the All policies tab and fill in the form.
Name it, and read what Applies to actually holds. Type is a dropdown of Workstation, Server, Mac and Linux with the line "Set once, when the policy is made" beside it, because a policy written for workstations cannot be quietly retargeted at servers later. Owner reads MSP and is not editable here. Tag is a picker that starts empty, and the line under it is the honest default: "No tag picked yet. Until you pick one, this policy covers every managed device," followed by "Leave this empty unless a few machines need something different from the rest of their client." Also assigned is a link rather than a field: "Give this to a client on the Clients tab," which is the door this walkthrough takes further down. Priority is 0 and says what it is for: "Only used when two tag policies land on the same device. The higher number wins." This walk names the policy KB walk - safe to delete policy, leaves Type on Workstation, leaves Tag empty, and leaves Priority at 0.
Click New Policy on the All policies tab and fill in the form. Press Create policy.
The policy is saved and opens on its own page, on the Monitoring tab. The heading reads the name just typed, and three chips beside it say what this policy is and reaches right now: Enabled, Priority 0, All managed devices. Down the left is the policy's own tab rail, eight of them: General, Monitoring, Patching, Maintenance, Agent, Permissions, LAPS and Security Baseline. Nothing on any of them has to be filled in for the policy to work; every field falls through to the shipped default until it is set, and the placeholder in each field is that default written out.
Press Create policy. Set a monitoring threshold.
Four fields govern the alert conditions this policy raises: CPU sustained %, Memory sustained %, Sustain window (seconds) and Min free disk %. CPU is set to 90 here and saved; the other three are left blank, so they keep showing their shipped defaults as placeholders: Default (95), Default (900) and Default (5). Each field carries its own one-line explanation, and the sustain window's is the important one: "A spike shorter than this never alerts." The line under the group states the fallback rule exactly: "A blank field falls through to the shipped default, shown as the placeholder." Which severities actually notify someone, or open a ticket, is not set here at all; that is one instance-wide decision under Settings > Alerts & Notifications.
Set a monitoring threshold. Open Patching and decide what installs on its own.
The table at the top is every kind of update down the side and how bad the problem is across the top: Critical, Important, Moderate, Low / optional. Each cell is a dropdown, and a cell left alone reads Inherit with the shipped answer in brackets, so nothing is hidden: security and critical updates inherit "Approve: install as soon as it appears" at Critical and Important, regular updates and feature packs inherit "A person installs it", and the Low / optional column inherits "Never install" almost everywhere. A cell can also be set to Install right away, Install after 3, 7, 14 or 30 days, A person installs it, or Never install. This walk sets exactly one cell, Regular updates at Important, to Install after 7 days and saves. That wait is the whole point of the days options: a bad update gets pulled in the days before it reaches your fleet, and you can install security fixes immediately while holding everything else for a week. Below the table, Install these KBs immediately takes KB numbers that skip the wait entirely for a fix that cannot wait.
Open Patching and decide what installs on its own. Read the install schedule.
Install day and Install time show Default (5) and Default (16:00), and both hints say whose clock that is: "The day of the week updates install, in each device's own local time" and "24-hour, as HH:mm. Local to each device, not to you." A fleet spread over four time zones all patches at the same local hour. Patch a device that missed its time ships On, so a device that was off at its slot patches at its next check-in instead of waiting a week. Skip on a metered connection also ships On: a laptop tethered to a phone waits for a real connection instead of pulling a cumulative update over somebody's data plan. Stay quiet while patching ships On too, and its hint says why: installing updates spikes CPU and disk and briefly stops services, so alerts are not raised during a device's own patch run. Paging everyone every Friday about the patch job is how people learn to ignore the pager.
Read the install schedule. Read the two restart choices, because they are two different situations.
When someone is signed in is a list of five radio options with the shipped one selected: Default (Ask until they accept: "Updates are ready. Restart now / Wait"), then the same choice stated outright, Tell them then restart, Restart without asking, and Do nothing: wait until nobody is signed in. Its hint is the honest one: updates install silently, and the restart is the only thing the person at the device ever sees. When nobody is signed in is its own list, shipped on Default (Restart now), with Keep trying until it restarts and Do nothing: leave the restart pending beside it. The device itself reports which situation it is in. Three numbers sit under them: Restart anyway after this many days, Default (3), counted from when the update installed plus two days of grace once the device is back online, with 0 meaning never; Ask again after this many hours, Default (4), which is how long Wait buys, because hourly nags get ignored; and How many times "Wait" is honored, Default (3), after which the restart goes ahead with a notice first. Auto reboot servers too ships Off on purpose, and says so: servers install updates and then wait for a person, because restart order usually matters, and both restart choices above are ignored on a server until this is turned on.
Read the two restart choices, because they are two different situations. Look at what happens when an update will not install.
Auto remediate patch failure and Create a ticket when an OS patch fails after every retry both ship on, reading Default (On). With remediation on, a failed update is diagnosed and the one repair that fits the cause is run, then the update is tried again, at most three times a day for that one update on that one device; it needs a restart to be possible, because some of the repairs end in one. Opening "What we try before opening a ticket" prints the ladder in the product's own words, numbered one to ten: restart Windows Update services, clear the Windows Update cache, a full Windows Update component reset, DISM RestoreHealth, SFC scannow, reclaim system-drive space, check winget sources, re-add the winget source, restart to finish updates, and required restart once a deadline is reached. The last two restart the device and run only when this policy allows a restart at all. The panel also states the outcome plainly: when those tries are used up and the update still fails, an alert is raised either way, and a ticket opens too only because the ticket dropdown is on. Set it to Off and nothing else changes; the alert is still raised and the device still shows the problem, you just do not get a ticket. The Next three install times box in the same column names the fleet's next three patch runs, shown in your own time zone with the note that each device uses its OWN local clock and has four hours from its start time to check in.
Look at what happens when an update will not install. Scroll to Software patching (third-party apps) and read the one thing a person sees.
"When the app is open" is its own radio list of four, shipped on Default (Leave it open and try again next time), with Ask them: "Close and update / Wait", Close the app and update anyway, and Leave it open and try again next time under it. Its hint is the reason it exists: most app updates cannot replace a file the app is still using, and this is the only thing about app patching the person at the device ever sees. Left on the shipped choice, that app is skipped for now and tried again at the next slot; nobody is cut off and no ticket is raised. Further down, Create a ticket when third-party updates are broken on a device ships Default (Off), and the hint says exactly what it covers: one ticket for the whole device when the update tool itself is broken, never one for each app. An app winget cannot match simply reads as Not managed on that device and nothing else happens, which is why a ticket here is a choice rather than a need.
Scroll to Software patching (third-party apps) and read the one thing a person sees. Open the Agent tab.
It holds two fields and nothing else. Check-in interval (seconds) sets how often the agent phones home, and its hint names the real bounds: honored between 25 and 300 seconds, with a value outside that range clamped to the nearest end. Log level sets how verbose the agent's own diagnostics are, reading Default (warn) with error, warn, info and debug behind it. The same fallback line sits under the pair: a blank field falls through to the shipped default, shown as the placeholder. There is no update-ring field here. The ring is a platform decision made per instance, not a policy field anyone sets on this screen.
Open the Agent tab. Open Permissions and arm one command.
Armed command types is a checklist of every agent command an automation or the AI operator may run on 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 is unchecked on a new policy, and the hint under the heading is exact: "Everything else is refused." A command that is not armed here cannot be run against these devices no matter what asks for it. This walk ticks device.state.read, the harmless read, and saves; reloading the tab shows it still ticked.
Open Permissions and arm one command. Go back to All policies and find the new row.
The list carries every policy the instance has, with its device type, its owner and what it reaches. The new policy reads KB walk - safe to delete policy, Workstation, MSP, and, in the Applies to column, "No client and no tag yet" - the honest state of a policy that has been written but not pointed at anything. The four shipped defaults above it read "Every client, unless they are given another". New Policy lives on this tab and on Tags.
Go back to All policies and find the new row. Open the Clients tab and give the policy to one client for one device type.
Clients is one row per client and one dropdown per device type, and every dropdown already names a policy: Bluebird Dental's Workstation cell read "Default (Default Workstation Policy)" because nobody had given that client anything different. The dropdown only offers policies of that type that are not already tag-scoped, so the only other choice here was the new policy. Picking KB walk - safe to delete policy took effect immediately, with no Save: reloading the page shows the cell reading the new policy's name, and the All policies row's Applies to column changed from "No client and no tag yet" to "1 client". The count under the cell still reads no devices, because nothing has enrolled for this client yet. The client roster on a shared demo tenant grows over time as other walkthroughs add their own test clients; this walk only touches Bluebird Dental's row.
Open the Clients tab and give the policy to one client for one device type. Read the same assignment back on the client's own record.
Clients > Bluebird Dental > Devices carries a Policies for this client card at the bottom, under the install keys and the device roster: one dropdown per kind of machine, with the line "One policy per kind of machine. Blank means the default we set for every client." The Workstation box now names KB walk - safe to delete policy, and Server, Mac and Linux still read their Default. These are the same rows as the Clients tab, reached from the client instead of from RMM, and changing one here changes the other. The client's own RMM tab is not this door: it holds that client's variables, not a policy assignment.
Note: The client's own RMM tab currently renders an empty panel with no content and no empty state. Use the Devices tab's Policies for this client card, or RMM > Policies > Clients, for a client's policy assignment.Read the same assignment back on the client's own record. Open RMM > Devices to see where a real machine would land.
The roster is every enrolled endpoint across every client, with one approval queue beside it: a Roster tab and an Unapproved (0) tab, a Client and Status filter, Online and Offline buttons and a Filters button. This instance has no devices at all, so the table reads "No devices match these filters" and the Unapproved queue is empty. A one-time Set up RMM card sits above it offering to walk the four fleet-wide decisions in one guided pass. Once a machine enrolls here, its own page names the one policy governing it and says why, and each setting on that page shows a chip for where its value came from.
Open RMM > Devices to see where a real machine would land. Click Install agent and pick the client.
Add a device asks for the client first, then shows that client's three installer rows: EXE installer, MSI installer and Linux installer, each with a Download button at the right and a caret at the left that opens that installer's own instructions and command. Under them sits a quick troubleshooting panel, and under that the client's install key with a copy button and a Manage keys link, which opens that client's Devices tab where regenerating the key, named keys for a rollout or a contractor, and the revoked-key history all live. The key itself is masked in this screenshot: it is what a real installer embeds, so it belongs in your password manager and not in a picture. Download the installer, run it on the endpoint, and the device enrolls under that client and appears in the roster within a minute.
Click Install agent and pick the client. Check Settings > RMM > Device Approval.
This is one decision for every client, not something a policy sets, and it is three rows with one of them in effect. Automatic approves every device the moment it enrolls, with nothing waiting in a queue, and it is the row this instance is on; it is also the shipped one. Automatic above a confidence approves a device only at or above a score. Manual leaves every device waiting for a tech. Clicking a row saves it right away. Approval matters because it is what turns on the stronger doors on a device: remote control, script runs and the terminal. Before a device is approved it only reports what it sees, and each of those doors can still be turned off later on that one device's page.
Check Settings > RMM > Device Approval. Open the middle row's details to see where the score lives.
Show details on "Automatic above a confidence" opens the only place that number can be typed: a field labelled Approve at or above, reading 75, with a percent sign and its own Save. No other row has that field, and a blank box is not a way to switch this off - to stop approving on a score, pick the Manual row instead. The panel above it explains what the score is made of: reaching the internet from the same address as devices already approved for that same client, being joined to the same domain those devices report (a device on a different domain scores zero), being signed in as a person who works for that client, and a Microsoft Entra device identity that the agent does not report yet, so it never counts either way. A device below the threshold waits on the Devices page's Unapproved tab. This walk opened the panel and changed nothing: Automatic is still the row in effect.
Open the middle row's details to see where the score lives.
Other ways to do this
The RMM setup wizard
The Devices page offers a one-time Set up RMM card: install the agent, then settle the same handful of fleet-wide decisions this walkthrough touched one page at a time, in a single guided pass.
A tag instead of a client
Pick a tag in the policy's Tag field, then tag the machines - either on each device's own page, or with Add devices next to the tag on the policy's General tab. RMM > Policies > Tags lists every tag-scoped policy together.
Editing a default instead of making a new policy
Open the default policy by its name on the Defaults tab and edit any tab in it. The change reaches every machine still on that default.
Automations reacting to a policy’s alerts
Turning on either ticket dropdown on the Patching tab materializes two real rows in Automations, named after this policy: one for the first time a device hits the problem, one for a later run that finds it still broken with no ticket open. Switch it back off and both rows disappear.
If it did not work
- If a device is not following the policy you expected, work the order: a tag policy on that machine wins first, then the policy its client was given for that device type, then the default for that type. The device's own page names the policy it got and says why.
- If the Clients dropdown does not offer the policy you just made, check its Type. A dropdown only offers policies written for that kind of machine, and a policy's type is set once, when the policy is made.
- If a policy shows no devices under its tag or its client, the policy is real but is not reaching anything yet. Nothing is wrong: enroll a device for that client, or tag a machine, and the count moves.
- If a setting on a device is not what the policy says, look at the chip next to it on the device's Policy tab. It names where that value came from: the shipped default, the policy governing the device, or Corrected, when the policy's own values did not add up and a safe combination had to be used.
- If a device turns out to have scripts or the terminal available sooner than expected, check Settings > RMM > Device Approval. Automatic approves on enrollment with nothing to wait on, and it is the shipped row.
Questions this page answers
What installs on its own?
The table at the top of Patching decides it. Each row is a kind of update. Each column is how bad the problem is. A cell can say Install right away, Install after 3 days, A person installs it, or Never install. A blank cell says Inherit, and it shows in brackets what it will do. Out of the box, security and critical updates go in right away. Regular updates and feature packs wait for a person. Optional patches never install. The table is also the on switch for the weekly install time. If no cell is set to install, that time comes around and finds nothing to do.
Why would I make it wait days after an update is released?
So a bad update does not reach your fleet on day one - if Microsoft pulls it, you were behind it. Each cell in the table carries its own wait, so you can install security fixes immediately and hold everything else for a week. Preview builds are never installed automatically at any setting. If one fix cannot wait, put its KB number in the immediate-install list and it skips both the wait and the table.
When do updates actually install?
On the day and time you set, in each device’s own local time - so a fleet spread across time zones all patches at the same local hour. The next three dates are shown under the fields. A device has four hours from that time to check in; one that was off patches at its next check-in instead of waiting a week. Maintenance windows are not used for this.
Why does a device stop alerting while it is patching?
Installing updates spikes CPU and disk and briefly stops services. Paging on all three every Friday teaches people to ignore the pager, so with "Stay quiet while patching" on (the default) alerts are not raised during a device’s own patch run. Turn it off if you want to see exactly what a patch run does to a machine. Alerts that were already open are unaffected.
What does the person at the device see?
Nothing while updates install - that happens silently. The only thing they ever see is the restart, and only if an update needs one: "Updates are ready. Restart now / Wait". That is why the install time is seeded at 4pm on a Friday: the restart lands while people are still at their desks. Wait postpones it for four hours, up to three times; after that it restarts with a notice first. If nobody answers, it simply asks again - silence is not taken as permission to restart.
When will a device restart on its own?
You choose it twice, because the two situations are different. With someone signed in: ask until they accept (the default), tell them and restart, restart without asking, or do nothing. With nobody signed in: keep trying until it restarts, restart now (the default), or do nothing. The device itself reports which situation it is in - nothing is guessed. Servers are separate and off entirely by default: they install and then wait for a person, because restart order usually matters. A device that installed updates and still has not restarted after three days, plus two days of grace once it is back online, gets a final 15-minute countdown it cannot postpone; set that to 0 to switch it off.
What happens when an update fails to install?
The failure is diagnosed from the error code and what the device reports about itself, and one repair is run - restarting update services, clearing the update cache, a component reset, DISM or SFC, or reclaiming disk space - then the update is tried again. After three attempts in a day it stops and opens a ticket containing the diagnosis, everything that was tried, and the evidence from the device. This needs automatic restart turned on, because every repair ends in one.
What does "Create a ticket when an OS patch fails after every retry" do?
When a Windows update will not install, we diagnose it and run a repair, then try the update again. We do that up to three times in a day for that one update on that one machine. If it still will not install, the device gets an alert either way. This is a dropdown with three choices: Default, On, and Off - it decides whether a ticket opens too. It reads Default (On) out of the box, which is how the portal has always worked. Set it to Off and nothing else changes: the alert is still raised and the device still shows the problem, you just do not get a ticket. One ticket per failing update per machine, not one per try. If that ticket is closed and the update fails again the next night, a new one opens, because the machine is still broken. Set it to On (or leave it on the Default that already means On) and two rows show up in Automations, named after this policy. One is for the first time an update gives up. The other is for a later night when the same update fails again and no ticket is open for it. They both log each run.
What happens to an app someone has open when its update is due?
It depends on the choice under "When the app is open". The shipped one is "Leave it open and try again next time". It skips that app for now and tries again at the next slot. Nobody is cut off and no ticket is raised. "Close the app and update anyway" shuts the app down first. If it will not close, we skip it rather than update under it. The third choice asks the person, with a Close and update button and a Wait button. If they pick Wait, or say nothing at all, we run nothing that slot. We ask again at the next one. Every other app still updates.
Why is "Create a ticket when third-party updates are broken on a device" off?
Because most app problems are not worth a ticket. An app we cannot match simply reads as "Not managed" on that device and nothing happens at all. This is a dropdown with three choices: Default, On, and Off. The only thing it covers is the update tool on the machine being broken, which stops every app update there. That already shows as a condition on the device, on the client overview and on the dashboard. So a ticket is a choice, not a need, and it reads Default (Off) out of the box. Set it to On if you want one anyway. You get one ticket for the whole device, never one for each app. It closes out on its own when the tool starts working again. Set it to On and two rows show up in Automations, named after this policy. One is for the first time we find the tool broken. The other is for a later run that finds it still broken with no ticket open. They both log each run.
What do the Agent settings control?
The Agent tab controls two things: the check-in interval, which sets how often the agent phones home, and the log level, which controls how verbose its diagnostics are. The update ring (canary, early, or stable) still exists in the system and shows read-only on the device's Monitoring tab, but it is not editable here or anywhere else on this tenant; it is a platform decision made per instance, not a policy field you set. Leave a field blank to inherit the default.
How do I install the agent on a device?
Click "Install agent" on this roster (or New, then Device, in the header). Pick the client the device belongs to and its three installer rows appear: EXE installer, MSI installer, and Linux installer, each with a Download button at the right and a caret at the left that opens that installer's instructions and command. Download the one you want and run it on the endpoint; the device enrolls under that client and appears in this roster within a minute. A machine already in the roster with no agent of ours has "Install agent" in its row menu, the three dots at the right of its row, which opens the same box with that machine's client already picked. The line under the rows shows the client's install key with a copy button, and "Manage keys" opens the client's Devices tab, where regenerating the key, named keys for a rollout or contractor, and the revoked-keys history live.
What is the Device Approval page for?
It sets who approves a new device. Three rows sit here, and one of them is in effect. Automatic approves every device that enrolls. The middle row approves a device only at or above a score. Manual waits for a tech. Click a row and it saves right away.
Which row is on when we start?
Automatic. Every device that enrolls is approved as soon as it is set up. Nothing waits in a queue. You can pick a different row at any time.
What does approving a device turn on?
Approving turns on remote control, script runs, and the terminal. Before that, a device only reports what it sees. You can turn each of those off later on the device page.
How do I approve only above a score?
Pick the middle row. Then click Show details on that row. A field named "Approve at or above" opens under it. Type a whole number from 1 to 100 and click Save. No other row has that field. A device below your number waits on the Unapproved tab.
How do I choose which devices a policy applies to?
The "Applies to" group has four parts: Type, Owner, Tag, and Also assigned. Type is set once, when you create the policy, and cannot change after that. Owner is always MSP for now. Tag is optional - leave it empty unless a few machines need something different from the rest of their client. Also assigned links to the Clients tab, where you give this policy to a client for its device type. A device uses the policy its client is assigned for its type. With no client assignment, it uses the MSP default for that type. A tag always wins over both.
How do monitoring thresholds work?
A threshold only fires an alert after it stays past the limit for the whole sustain window - one short spike never pages. A blank field uses the shipped default for that field, shown as the placeholder. Defaults are set on the safe side.
What do I fill in here, and what happens next?
Give it a name and pick the type of machine. The type is set once and cannot change later, so pick the right one now. Leave the tag empty unless a few machines need something different. Press "Create policy" and it opens. You set the monitoring, patching, agent and permission rules after that. Each one has its own tab.
Was this helpful?