-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting
Common issues and questions. If something here doesn't cover it, ask in Discussions.
This is expected. Groundskeeper serves the dashboard over HTTPS using a self-signed certificate generated at install time, so browsers warn that they can't verify it. On a self-hosted tool on your own network this is normal.
- For a one-off, click through the warning (Advanced -> proceed).
- To remove it on managed devices, the installer ships
tools\Trust-GroundskeeperCert.ps1, which can be pushed via Group Policy to trust the certificate estate-wide -- handy for a wall display or shared machine where you don't want a warning every time.
Yes. Open the same address in your phone's browser (you will meet the same certificate warning as above). On a screen narrower than a tablet the sidebar becomes a narrow icon rail down the left, and the first page you open in a session slides the full menu out with its names for a moment so you can see what the icons mean. Tap the chevrons at the bottom of the rail to open the full menu over the page, tap the page to close it. The activity feed puts each event's buttons in a row under its title, sized for a thumb. Nothing changes on a laptop or desktop.
Work through:
-
Is the service running? Check the Groundskeeper Windows service is
started (
services.msc, orsc query Groundskeeper). The Start Menu folder also has a Stop Service shortcut; starting is via the service or a reboot. -
Right address? It's HTTPS on port 8443 --
https://<server-address>:8443(nothttp, not port 8000). - Firewall: if you're reaching it from another machine, make sure inbound TCP 8443 is allowed to the server on the local network.
-
Logs: check the
logsfolder in the install directory for startup errors.
There is no self-service reset. Recovery is done on the server: remove the
stored password hash from config.yaml and restart the Groundskeeper service,
which returns you to the first-run password prompt. Your configuration and data
are untouched. (Keep the admin password somewhere safe to avoid needing this.)
- Use the Test button on that connector's card in Settings > Connectors -- it exchanges the credentials and does a small live check, and the error it returns usually points straight at the cause (bad key, wrong region, unreachable host).
- Check the credential is current and has the permission level the connector needs (these are listed per connector on the Connectors page).
- For the Windows-infrastructure connectors, confirm the relevant RSAT feature is installed and that Groundskeeper is running on a domain-joined server.
That's the Community edition limit. Pro lifts it. Note that AI and the Central hub don't count against the connector limit -- only actual connectors do.
- Confirm the server can reach
api.rsjsoftware.comover outbound HTTPS -- that's where activation and the periodic heartbeat happen. - If you requested a Community key, allow up to one business day for it to be emailed; activation is then automatic.
- If you already have a key, enter it under Settings > Licence (the "Already have a key?" link on the dashboard banner takes you there).
- Groundskeeper has a 7-day offline grace period, so a brief loss of internet won't stop it working.
No school monitoring data is stored externally. Groundskeeper runs on your server and reads from your systems locally. The only outbound traffic is:
- The licence heartbeat to
api.rsjsoftware.com(install identity and status -- no monitoring data). - Periodic version checks to GitHub (to tell you when an update is available -- no monitoring data).
- If you enable a cloud AI provider, scrubbed monitoring context is sent to that provider. Local Ollama AI sends nothing. See AI Features.
See the privacy notice on the marketing site for the full statement.
No. Every connector is read-only -- Groundskeeper reads status and never writes to, reconfigures or controls a monitored system.
No -- it's optional. The agentless connectors cover a lot on their own. The GKAgent endpoint agent adds richer per-device detail (BitLocker, Defender, firewall, pending reboots, SMART disk health, battery, crash events, local admin audit, update compliance) by running on each endpoint and checking in to your local Groundskeeper server. It's deployed separately via Group Policy.
The agent shares the server's version number. If an endpoint shows an older
agent version, it simply hasn't been updated yet -- deploy the matching
GKAgentSetup.exe from the release. The agent only checks in to your local
Groundskeeper server, never to the internet.
The agent pins your Groundskeeper server's TLS certificate fingerprint the
first time it checks in successfully, and validates against only that
pinned fingerprint on every checkin afterwards -- this is why endpoints don't
need tools\Trust-GroundskeeperCert.ps1 run against them individually just to
stop checkin failing (see the certificate warning note above for the
alternative, estate-wide GPO route). If the server's certificate ever changes
unexpectedly on a later checkin, the agent flags a distinct cert_mismatch
state rather than silently re-trusting it.
That first checkin is a trust-establishing moment: whoever the agent reaches first is the fingerprint that gets pinned, permanently, and there's no way for the agent to tell a legitimate first contact from an intercepted one. In practice:
- Deploy on a network you trust. Run each endpoint's first checkin on the school's own managed LAN, not somewhere it could be intercepted (an unmanaged guest network, a public network, an untrusted wireless AP).
-
For extra assurance, verify the fingerprint afterwards. After an
endpoint's first checkin, you can compare the
cert_fingerprintvalue in that device'sagent-health.jsonagainst your Groundskeeper server's actual certificate fingerprint (viewable via your browser's certificate details when you visit the dashboard). If they match, the pin is genuine.
This is standard Trust-On-First-Use (TOFU) behaviour -- the same model SSH uses for host keys -- rather than something specific to Groundskeeper, but it's worth knowing before a wide agent rollout across an estate.
Last updated: 2026-09-22 (v0.180.23)