Scripts, Policies and Automation

This guide covers the Script Library and Automations. For the checks that raise alerts, see Monitoring Policies. For packaged installs and fixes, see Components. Everything that runs on a device appears on Jobs with a live progress bar.

Script Library

Open RMM → Scripts.

• Scripts holds your saved scripts. Built-in scripts are read-only; choose Copy to make your own version.
• Run now runs a script straight away on the devices you choose.
• Jobs holds scheduled runs.
• History lists every run with its output and exit code. Filter it by script, status, device or the automation that started the run.

Automations

Open RMM → Automations. An automation is a rule in three parts: when something happens on a device, and only if your conditions are true, do one or more things.

Ready-made automations

Select Templates to browse 139 ready-made automations in nine groups: Patching, Software, Security, Performance, Availability, Services, Scripts & jobs, Alerts & backups and Install when missing. Search, read what one does, and select Use template. It is created switched off so you can check it before turning it on.

Examples: create a ticket when a device is missing critical updates; install critical updates on workstations; install Google Chrome where it is missing; update applications with known vulnerabilities; restart the print spooler when it stops; clear temporary files when a disk is nearly full; tell the team when a server goes offline.

When (the trigger)

Select the trigger box and type to search. There are 38 triggers:

• Availability — device goes offline or comes back online, not seen for a number of days, agent warning, new device enrolled, not restarted for a number of days
• Performance — any monitoring threshold breached, CPU, memory, disk nearly full
• Patching — missing critical updates, missing updates, restart pending after updates, Windows update failed or installed, update scan failed
• Software — application not installed or installed, applications out of date, applications with known vulnerabilities, application install, update or removal succeeded or failed
• Scripts & jobs — script, component or job failed or succeeded on a device
• Alerts & backups — monitoring alert raised, too many open alerts, backup failed, finished with warnings or succeeded
• Custom — device matches a filter you build

Triggers that describe a state (such as missing critical updates or application not installed) are checked regularly. They fire once for a device when the state becomes true, and again only after it has cleared. Runs started by an automation never set off another automation, so rules cannot loop.

Only if (the conditions)

Conditions compare a value from the trigger with a value you set, using is above, is at least, is below, is at most, is, is not and contains. Every condition must be true.

Which devices

Limit a rule to all devices, chosen customers, groups and filters, or chosen devices. See Groups and Filters. Network devices are never included.

Do (the actions)

Create a ticket, notify administrators, run a component or script, restart a service, install, update or remove an application, update every application, install Windows updates, scan, restart, or run a saved job. A rule can have several actions; they run in order. Set how long to wait before the same rule can fire again on the same device.

Test on a device

Before you turn a rule on, choose Test on a device. Plenix shows whether the rule would fire for that device right now and which part passed or failed, without running anything.

Run history

Each automation keeps a history of when it fired, on which device and what each action did, with links to the device and to the run on Jobs.