Moorfox
Why does my RMM agent show a machine offline when it is on?
Most of the time the machine is asleep, the agent service has stopped, or outbound HTTPS is blocked. Ask the user to press a key and wait 30 seconds. Then check sleep states with powercfg /a, the service with Get-Service or sc query <name>, and the path to the vendor with Test-NetConnection <control-plane-host> -Port 443.
If those pass, look at the clock (w32tm /query /status, then w32tm /resync), at TLS inspection on the site proxy, and at whether the machine was imaged with the agent already installed. A cloned identity shows up as one device that flaps between online and offline.
The dashboard says the machine is offline. The user on the phone says it is on and they are working on it. Both are telling the truth: the machine is powered up, and the agent on it has not checked in.
The gap is almost always one of seven things, and the first three cover most tickets. Before working the list, ask the user to press a key and wait 30 seconds, then compare the last-seen time on the dashboard with when the user says they last used the machine. If it was fine until a particular date, ask what changed on that date: a new firewall, a new filter, a re-imaged machine. Then start at the top.
Is the machine asleep or hibernating?
Windows laptops sleep when the lid closes and after a timer. With Fast Startup on, "shut down" is a hibernate of the kernel session, so the machine the user "shut down and turned back on" never fully restarted. In both cases the user sees a dark screen and a lit power LED and calls it on. A sleeping machine cannot run the agent, so the dashboard shows it offline.
powercfg /a lists which sleep states the machine supports. powercfg /requests shows what, if anything, is holding it awake. powercfg -h off turns off hibernation and Fast Startup together. For desktops, set Power Options to "Put the computer to sleep: Never" when plugged in; a laptop is going to sleep whatever you do, so tune the alert instead (see the FAQ).
Is the agent service running?
The machine is awake and the user is logged in, but the service that talks to the dashboard has stopped, is stuck in "Stopping", or is crash-looping.
Check it with Get-Service (filter on the agent's service name) or sc query <name>. Open Event Viewer > System and filter on Service Control Manager. Event ID 7031 or 7034 is a service that terminated unexpectedly; 7000 is a service that failed to start. A stopped service usually just needs starting. A service that dies again within seconds, or one whose binary is missing from the install directory, wants a reinstall over the top, which keeps the device identity.
Is outbound HTTPS blocked or broken?
The agent connects outbound on port 443 to the vendor control plane. Web filters, DNS filtering, new firewall rules, or proxies performing TLS inspection break that connection while user browsing continues. "The internet works" is not evidence.
Run Test-NetConnection <control-plane-host> -Port 443 and nslookup <control-plane-host> from the machine. Then check the proxy the service account sees, which is not the same as the proxy in the user's browser: netsh winhttp show proxy. TLS inspection swaps the vendor's certificate for the proxy's own, and an agent that pins or validates the certificate refuses to talk through it. The fix is on the proxy or filter, not the machine: exclude the vendor's hostnames from inspection.
Is the clock wrong?
TLS fails when the machine's time falls outside the certificate's validity window, and the agent cannot connect at all. A dead CMOS battery on an older desktop, or a VM restored from an old snapshot, puts the clock years out. A clock more than a few minutes out also breaks domain logons, since Kerberos tolerates 5 minutes of skew by default, so this one often arrives with a second ticket attached.
w32tm /query /status shows the time source and how far off the machine is. w32tm /resync forces a sync. If the time is wrong again after a reboot, the CMOS battery is the fix.
Was the machine imaged with the agent already installed?
Two machines take turns being offline, or one device on the dashboard flips between online and offline with the last check-in jumping between two places. That is a cloned identity. The image was captured with the agent installed and not sysprepped, so every machine built from it enrols as the same device.
On the clone, uninstall the agent, remove any leftover agent identity files or registry keys, and reinstall so it enrols as a new device. Then fix the image: sysprep before capture, or install the agent as a post-imaging step.
Is the machine on a network the agent has never seen?
Captive portals in hotels or cafes, guest VLANs that allow web browsing but block other traffic, or VPN clients that route all traffic and drop it when the tunnel is down. The user can often open a web page, so they report the internet as working.
Ask where the machine is. On a captive portal, opening a browser and accepting the portal page brings the agent back. On a guest VLAN or behind a full-tunnel VPN, the same Test-NetConnection test above tells you whether the control plane is reachable from that network at all.
Did an agent update fail halfway?
The agent is mid-update, the update failed, and the old binary is gone while the new one never started. The service shows stopped and the install directory is missing its executable, or the logs end with a download or signature error.
Reinstall the agent over the top. The reinstall replaces the binary and re-registers the service without changing the device identity, so the machine comes back as itself. If it fails again, check free disk space and write permission on the install directory.
How do I stop these tickets coming back?
Set desktops to never sleep when plugged in. Exclude the RMM vendor's hostnames from web filtering and TLS inspection at every client site as part of onboarding, not after the first outage. Sysprep images, or install the agent after imaging. Set offline alerts per device type: a laptop that sleeps every evening should not page anyone, while a server offline for 5 minutes should.
The Moorfox agent connects outbound only over HTTPS, so nothing inbound is ever needed. Offline alerts are split into workstation and server thresholds, with per-device overrides, so a laptop sleeping overnight is not an alert while a server is. The device page shows the last check-in time and the agent version, and a cloned image shows up as one device flapping, which is the tell for the identity case above.
Frequently asked questions
Does the RMM agent need an inbound port open on the firewall?
No. The agent connects outbound only, over HTTPS on port 443, the same way a browser does. Nothing inbound is needed, so the site firewall does not have to change.
Why does the dashboard show a laptop offline every evening?
The laptop is asleep. Windows laptops sleep on lid close and on a timer, and the agent cannot check in from a suspended machine. Set the offline threshold for workstations to hours, or turn it off for laptops, so nobody gets paged for a sleeping box.
Why did every machine at one site go offline at once?
That is the site, not the agents. Look for a new firewall rule, a web filter or DNS filter, TLS inspection turned on, or an ISP outage. One agent failing is a machine problem; all of them at once is a network problem.
How long should offline alerts wait for workstations versus servers?
Workstations: hours, or no alert at all for laptops, because they sleep. Servers: minutes, because a server that has been unreachable for five minutes is already an incident.