Documentation

Firewall & Network

This page is also in the Groundskeeper wiki: https://github.com/rsjsoftwareltd/groundskeeper/wiki/Firewall-and-Network

Groundskeeper is self-hosted: it runs on a Windows Server on your own network and reaches out to the systems it monitors. Most connectors talk to cloud APIs over standard HTTPS and need no special firewall configuration. A few reach into your LAN (your Windows servers and clients, printers, switches, UPS units) and those are the ones worth checking if a connector shows nothing or reports devices as unreachable.

This page is the single reference for everything network-related. Each connector on the Connectors page that needs LAN access links back here.

The quick version: allow inbound TCP 8443 to the Groundskeeper server so you can reach the dashboard and so agents can check in. Everything else is outbound from the server, and on a default Windows Server (outbound allowed) the cloud connectors work with no changes. The LAN connectors (Windows servers/ clients, SNMP devices) may need rules on the target devices or your network firewall -- see below.

Inbound -- reaching the dashboard and receiving agent check-ins #

This is the one rule almost everyone needs, and the most common reason "I installed it but can't open the dashboard from my PC".

With Central, the hub contacts each school; schools never connect to the hub. So it is each school's server that must accept the hub's connection.

The installer can add this rule for you (a tick-box during setup). If you declined it, manage the firewall centrally by GPO, or want to add it by hand:

netsh advfirewall firewall add rule name="Groundskeeper Dashboard (TCP 8443)" `
  dir=in action=allow protocol=TCP localport=8443

8443 is the default, not a fixed number. If another program on the server already uses 8443 (door access software is a common one), choose another port: the installer asks on a fresh install (or accepts /PORT=9443 for a silent install), and an administrator can change it later under General Settings, About, Web address port. The firewall rule is named for its port, for example Groundskeeper Dashboard (TCP 9443), and the installer and that setting both move it for you. If you manage the firewall yourself, allow the port you chose:

netsh advfirewall firewall add rule name="Groundskeeper Dashboard (TCP 9443)" `
  dir=in action=allow protocol=TCP localport=9443 profile=any

Changing the port restarts Groundskeeper. Computers already running the agent were told the old port and stop checking in until the agent is set up again from Agent Settings, and a Central hub's saved address for the school needs the new port. Ports 8444 to 8447 are used by other RSJ Software products, so avoid them on a server that may run those too.

If you only ever open the dashboard on the server itself (https://localhost:8443), you do not need this rule at all -- loopback traffic is never firewalled. You only need it to reach the dashboard from another machine, or for agents to check in.

HTTPS note: Groundskeeper serves HTTPS on 8443 with a self-signed certificate by default, so the first browser visit shows a certificate warning. That is expected for a self-hosted tool on your own network. The install folder contains tools\Trust-GroundskeeperCert.ps1 to trust the certificate on machines that need a clean padlock.

Outbound -- cloud connectors (no firewall changes on a default server) #

These connectors talk only to vendor cloud APIs over outbound HTTPS (TCP 443). On a standard Windows Server -- where outbound traffic is allowed by default -- they work with no firewall changes. You only need to do anything if your network firewall restricts outbound traffic (egress filtering), in which case allow HTTPS from the GK server to the relevant vendor domains.

If egress is filtered and a cloud connector shows nothing, this is almost always the cause -- allow outbound 443 from the GK server to the vendor domain.

Outbound -- Groundskeeper itself (licence, updates, AI) #

Groundskeeper also makes a few outbound HTTPS (TCP 443) calls of its own. None carries monitoring data. If you filter outbound traffic, allow:

Outbound -- Windows servers & clients (WMI / DCOM) #

These connectors are agentless: Groundskeeper reaches out from the server to each Windows target using WMI over DCOM. This is the area most likely to need firewall and permission work, because the requirement is on the target machines, not the GK server.

Connectors that use WMI/DCOM: Windows Servers, Windows Clients, Endpoint Reports, Hyper-V, DNS & DHCP, Devices Left On Overnight, Exam Marking Software.

Three Windows connectors do not use WMI, so the local-admin rule below does not apply to them:

• Windows Event Log reads the domain controller's Security log remotely. Allow Windows' Remote Event Log Management firewall rules on that server. Membership of its Event Log Readers group is enough; it does not need local admin.
• Active Directory and AD Account Health use the Active Directory tools (RSAT-AD-PowerShell on the Groundskeeper server) to talk to your domain controllers. The FSMO check reaches each role holder on TCP 389, 636 or 9389, and the SYSVOL/NETLOGON check reads those shares over SMB (TCP 445).

Two things each target needs:

1. Firewall -- allow WMI/DCOM inbound on the target (from the GK server):
   • TCP 135 -- the RPC endpoint mapper
   • The dynamic RPC port range -- the endpoint mapper hands the connection
   • Windows ships a built-in rule group for exactly this. The simplest way to
   • In a domain this is normally done once as a GPO applied to the computers
2. Permission -- the Groundskeeper service account needs local admin on the target. WMI hardware/OS queries require administrative rights. The service account that the Groundskeeper Windows service runs as must be a local administrator on each monitored server/client (typically a domain account in the local Administrators group, applied by GPO or Restricted Groups).

Why WMI/DCOM and not WinRM? Groundskeeper deliberately uses DCOM (Get-WmiObject -ComputerName) rather than WinRM, because WinRM is rarely configured in schools and DCOM works out of the box on a domain once the firewall and admin rights are in place -- no per-machine winrm quickconfig needed.

The one exception is pushing the RSJ Agent from Agent Settings (push deploy). That uses WinRM: each target PC must accept inbound TCP 5985 from the Groundskeeper server. Groundskeeper never turns WinRM on for you. If WinRM is off on your PCs, use the deploy script or Group Policy instead.

Symptom when this isn't set up: the connector reports targets as "Server unreachable: SERVER01 -- The RPC server is unavailable." (the firewall), "... Access is denied." (the account), or returns no data for a machine that is clearly online. Check, in order: (1) the WMI firewall rule group is enabled on the target, (2) the GK service account is a local admin on the target, (3) any third-party endpoint firewall on the target isn't blocking it (see the callout below).

Outbound -- SNMP devices (printers, switches, UPS, WatchGuard Firebox) #

These connectors poll network hardware using SNMP over UDP.

What to check:

• SNMP must be enabled on the device. Printers, HP switches and UPS units use SNMPv2c with a read-only community string (commonly public) -- set the same string in the connector config. The WatchGuard Firebox uses SNMPv3 instead (username + authentication password + privacy password) -- configure this in Fireware Web UI or WatchGuard Cloud, not a community string.
• If the devices are on a different VLAN/subnet from the GK server, your network firewall / router ACLs must allow UDP 161 from the GK server to the device subnet. SNMP is frequently blocked between VLANs by default. For the Firebox specifically, an SNMP management station entry or packet filter policy on the Firebox itself must also allow the GK server's IP.
• These are read-only polls -- Groundskeeper never writes to the device.

Outbound -- other LAN devices on specific ports #

These reach LAN devices over a specific TCP port (not WMI, not SNMP):

If these devices are on a management VLAN separated from the GK server, allow the listed port from the GK server to the device on your network firewall. For Veeam, the account also needs the Veeam Restore Operator role.

Third-party endpoint firewalls (the easy thing to miss) #

If your endpoints run a managed endpoint-security firewall -- WatchGuard EPDR / Panda, Sophos, SentinelOne, CrowdStrike, Defender Firewall pushed by GPO, etc. -- that firewall sits on the target machine and can silently block the WMI/DCOM traffic the agentless connectors rely on, even if the built-in Windows Firewall rule is enabled. The managed firewall's policy takes precedence.

If agentless Windows monitoring works on some machines but not others, and the built-in firewall and admin rights look correct, the managed endpoint firewall is the usual culprit. Add an allow rule in that product's policy for inbound WMI/DCOM (TCP 135 + the dynamic RPC range) from the Groundskeeper server's IP.

If you deploy the RSJ Agent to endpoints instead of (or alongside) agentless scanning, the agent makes an outbound HTTPS connection to the GK server on 8443 and reports in -- so it sidesteps the inbound WMI/DCOM firewall question on the endpoint entirely. Agentless is simplest for servers; the agent is often easier for large fleets of clients behind strict endpoint firewalls.

Quick troubleshooting map #

See also: Connectors for what each connector does, and Troubleshooting for general first-run checks.

Last updated: 2026-11-05 (v0.195.0)