-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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".
| Purpose | Direction | Protocol / Port | Where |
|---|---|---|---|
| Dashboard (browser) | Inbound to the GK server | TCP 8443 (HTTPS) | Windows Firewall on the GK server |
| RSJ Agent check-in | Inbound to the GK server | TCP 8443 (HTTPS) | Windows Firewall on the GK server |
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" `
dir=in action=allow protocol=TCP localport=8443If 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.ps1to trust the certificate on machines that need a clean padlock.
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.
| Connector | Talks to (outbound HTTPS 443) |
|---|---|
| Cisco Meraki | api.meraki.com |
| Action1 |
app.eu.action1.com (EU region) |
| M365 - Service Health |
graph.microsoft.com, login.microsoftonline.com
|
| M365 - Licence Usage |
graph.microsoft.com, login.microsoftonline.com
|
| WatchGuard Endpoint | WatchGuard Cloud API (deu region) |
| Domain Security | Public DNS + the domains you monitor (SPF/DMARC/TLS checks) |
| Internet Health | The URLs you test (default: Google, Microsoft 365, GitHub) |
| School Services | The cloud services you tick (ParentPay, Wonde, RM Unify, etc.) |
| SSL Certificates | The hosts you list (TLS handshake on their port, usually 443) |
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.
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, Windows Event Log, Active Directory, AD Account Health, Devices Left On Overnight, Exam Marking Software.
Two things each target needs:
-
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 off to a high port. By default this is TCP 49152-65535 on modern Windows.
- Windows ships a built-in rule group for exactly this. The simplest way to
enable it on a target (or via GPO across many) is:
Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)"
- In a domain this is normally done once as a GPO applied to the computers you want monitored, rather than per machine.
-
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.
Symptom when this isn't set up: the connector reports targets as "Server unreachable -- Could not connect via WMI/DCOM", 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).
These connectors poll network hardware using SNMP over UDP.
| Connector | Protocol / Port | Target |
|---|---|---|
| Printers / MFDs | UDP 161 (SNMP v2c) | Printer management IP |
| Switches (SNMP) | UDP 161 (SNMP v2c) | Switch management IP |
| UPS | UDP 161 (SNMP v2c) | UPS network management card |
| WatchGuard Firebox | UDP 161 (SNMPv3) | Firebox management IP |
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.
These reach LAN devices over a specific TCP port (not WMI, not SNMP):
| Connector | Protocol / Port | Target |
|---|---|---|
| Veeam | TCP 9419 (HTTPS REST API) | Veeam B&R server (v11/12/13) |
| Dell iDRAC | TCP 443 (Redfish API) | iDRAC management IP (not the server OS IP) |
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.
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.
| Symptom | Most likely cause |
|---|---|
| Can't open the dashboard from another PC | Inbound TCP 8443 not allowed on the GK server |
| A cloud connector shows nothing | Outbound 443 blocked by egress filtering to that vendor |
| A Windows server/client shows "unreachable via WMI/DCOM" | WMI firewall rule not enabled on target, GK service account not local admin, or a managed endpoint firewall blocking it |
| Some Windows machines work, others don't | Third-party endpoint firewall policy on the failing machines |
| A printer/switch/UPS shows nothing | SNMP not enabled / wrong community string, or UDP 161 blocked between VLANs |
| Veeam / iDRAC shows nothing | The device-specific port (9419 / 443) blocked between the GK server and the device |
| WatchGuard Firebox shows nothing | UDP 161 blocked, SNMPv3 credentials mismatched, or no SNMP management station/packet filter entry on the Firebox allowing the GK server |
| Agents not appearing | Endpoints can't reach the GK server inbound on 8443 |
See also: Connectors for what each connector does, and Troubleshooting for general first-run checks.
Last updated: 2026-09-23 (v0.182.4)