Agent Settings
Agent deployment, device management and monitoring policy

Shared secret

Agents authenticate using this shared secret. The deploy options below hand it to each endpoint for you — you don't set it on machines by hand.

Loading...

Minimum 16 characters. If you change it, re-deploy your endpoints so they re-enrol with the new secret.

Deploy an agent

Two ways to get the agent onto devices: download a script and run it on each device (or deploy it through Group Policy or Action1), or let Groundskeeper find devices in Active Directory and push the agent to them over WinRM.

1. Download the deploy script

Each endpoint installs the RSJ Agent — the shared host that runs Groundskeeper's monitoring as a pulled module. The installer (RSJAgentSetup.exe) is given this server's address and the shared secret above, installs the host, and enrols the machine for Groundskeeper; the host then downloads (“pulls”) the Groundskeeper module by itself. There is no separate “Groundskeeper Agent” on the box — the host installs to C:\Program Files\RSJ Software\RSJ Agent and keeps its settings in C:\ProgramData\RSJ Software\Agent. The deploy script below does it all in one step:

  1. Downloads RSJAgentSetup.exe (the RSJ Agent host installer) from this server
  2. Installs the RSJ Agent host silently and enrols this machine for Groundskeeper — the secret is handed over in a locked-down file, never on a command line. The host then pulls the Groundskeeper monitoring module automatically
  3. Verifies the RSJ Agent service is running and enrolled — the device appears on the dashboard within ~5 minutes, once it has pulled its module

Hostname or IP with optional :port — it must be reachable from the endpoints, not just from this browser. Run the script once, as Administrator, on each endpoint. To deploy through Group Policy or Action1, use the same script as the package.

Handle with care: the downloaded script contains the agent shared secret in plain text. Treat it like a password and delete it once deployment is complete.

2. Find devices in Active Directory and push the agent to them

Searches Active Directory for Windows computers that do not have the agent. This server must be joined to the domain and have the Active Directory PowerShell tools (RSAT-AD-PowerShell) installed. Computers that have not signed in for 30 days or more are left out. On a shared AD forest (e.g. a multi-school trust), set a scan scope below so discovery only returns this school's own OU.

Devices it finds appear under Devices › Unregistered, where you choose which to deploy to. Pushing needs WinRM enabled on the target (off by default on Windows 10/11 clients); for those, use the script above.

Devices

Deploy selected requires WinRM enabled on target devices (off by default on Windows 10/11 clients) — use the deploy script on the Deploy tab for devices without it. To scan Active Directory again, use Run AD discovery on the Deploy tab.

🔍

Discovery not yet run

Use Run AD discovery on the Deploy tab to scan Active Directory for Windows computers without the agent installed.

Click the Excluded tab to load.

Monitoring policy

Choose which agent conditions create feed events. Uncheck items your school doesn't use — for example, if you run Sophos or ESET instead of Windows Defender, uncheck both Defender options. The agent still collects all data; these settings only control what triggers alerts. Role-gated checks (servers, Hyper-V, DNS/DHCP) only ever fire on devices that hold the role.

Device offline
Alert when a device hasn't checked in for more than minutes
Pending reboot
Alert when a client device has an outstanding Windows reboot (checked once per day per device)
Windows Defender disabled
Uncheck if your school uses a third-party AV (Sophos, ESET, Avast, etc.)
Defender signatures out of date
Alert when antivirus signatures are more than 3 days old. Untick if you use third-party antivirus.
BitLocker off (clients only)
Uncheck if your school uses alternative drive encryption or has a policy exemption
Domain firewall disabled
Off by default — can be noisy where firewall policy is managed externally via GPO
Unexpected local admins
Alert when accounts outside the allowlist hold local Administrators membership (Cyber Essentials: user access control). Built-in admin accounts are always allowed; add other expected accounts to agent.local_admins_allowlist in config.yaml.
Windows update compliance
Warn when a Windows update released days ago is still not installed, critical after days (Cyber Essentials allows 14 days from release; a device on the newest update is current however old it is)
More agent checks
Volume disk space
All fixed volumes on every device — warn at % used, critical at %
Automatic services not running (servers)
Services set to start automatically that are not running. Delayed-start and trigger-start services are left out.
Hyper-V health (Hyper-V hosts)
Replication in a critical state, and paused VMs (Hyper-V pauses VMs when host disk runs critically low)
DNS & DHCP health (role holders)
DHCP scope utilisation — warn at %, critical at % — plus DNS service down and failed resolution tests
Security events (servers / DCs)
Account lockouts, account create/delete, group membership changes; failed-logon burst warning at in the collection window
Agent self-health
Warn when a device's agent reports that some of its checks are failing, so a partly working agent shows up in the feed instead of quietly sending less data
End-of-life & outdated software
Push a feed event when a device runs unsupported software or an end-of-life OS (critical — Flash, Python 2, Windows 7/8, Server 2008–2012), or outdated high-risk apps below their patch floor / Windows 10 unless ESU-enrolled (warning). Pairs with the Reports Software Inventory card.
SQL Server backup age (SQL hosts)
Per-database full-backup age on detected SQL Server instances (e.g. SIMS) — warn at days, critical at days since the last full backup. tempdb is excluded; a permissions gap on the instance produces no data rather than an alert.