Monitoring Benefit
Server Connectivity reports whether ENow can still reach a monitored server. It is not a test of any service running on that server — it is a test of the monitoring itself.
That makes it the first indicator to read whenever something looks wrong, because it answers a question none of the other tests can: are these results current? Every other check for a server shows what it last measured. If the server stopped being reachable an hour ago, those results describe an hour ago, and nothing on the individual test pages says so.
Without this test, "everything is green" and "we stopped looking" are indistinguishable.
Read this before working any other check on the same server
| What you see | What it means |
|---|---|
| Connectivity healthy, one check failing | The server is reporting and the result is current. Work that check. |
| Connectivity failing, other checks look normal | Those results are stale — they are the last thing the server said before it went quiet. Work the connectivity, not the checks. |
| Connectivity failing on one server | That server: powered off, rebooting, agent stopped, or the path from the ENow web server has changed. |
| Connectivity failing on many servers at once | Not that many separate failures. Look at the ENow web server, its database, or a network change between it and the estate. |
What makes a server stop reporting
| Cause | What to look for |
|---|---|
| The server is off, rebooting or decommissioned | The most common cause by a distance. A virtual machine that was migrated, patched or retired is easy to lose track of, and it will sit red indefinitely. |
| The ENow agent service is stopped | Check the ENow services on the monitored server are running and set to start automatically. |
| A network or firewall change | Something between the server and the ENow web server changed. This is the direction that matters here. |
| Credentials or permissions changed | The monitoring account's rights on that server were altered, often as part of a wider hardening change. |
| The server was renamed or re-addressed | ENow is still looking for what it was told to monitor. Update the configuration rather than waiting for it to recover. |
How do we verify the monitoring test results?
- Confirm the server is powered on and reachable from the ENow web server — not merely from your workstation, which may take a different path.
-
Test the path from the ENow web server:
Test-NetConnection -ComputerName <monitored server> -InformationLevel Detailed - Check the ENow services are running on the monitored server, and confirm they are not in a start-then-stop loop by reviewing their recent history.
-
Confirm WMI is answering, since most server-side checks depend on it and it fails independently of the network:
Get-CimInstance Win32_OperatingSystem -ComputerName <monitored server> | Select-Object CSName, LastBootUpTimeThe last boot time is worth having anyway — an unexpected reboot explains most short outages here.
-
Check the agent's cache on the monitored server to see when it last collected anything. The files live under:
\Program Files (x86)\ENow\Mailscape Agent\Cache\Their timestamps tell you whether the agent is still working and failing to report, or has stopped altogether — two different problems.
- Compare against other servers. One server quiet is a server problem; several at once is a problem closer to the ENow web server.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
| One server not reporting | Work that server in order: powered on, then services, then the network path back to the ENow web server. |
| Several servers stopped at the same moment | Look at the ENow web server, its database, or a shared network change — not at the individual servers. |
| A server reports intermittently | Usually a service restarting repeatedly or a saturated link. Check the agent's logs for a crash-and-restart pattern. |
| Connectivity is fine but one test never updates | Different problem. The server is reachable, so work that individual test rather than connectivity. |
| A decommissioned server still appears | Remove it from monitoring rather than leaving a permanently red indicator. A dashboard with known-bad tiles stops being read. |
| Recovers on its own each night | Compare against the server's reboot schedule and any backup window before treating it as a fault. |
Comments
0 comments
Article is closed for comments.