Client Health Dashboard Disagrees After Management Upgrade
A company has 5,000 Windows and macOS endpoints managed by an on-premises Harmony Endpoint server pair in HA. After a management upgrade, the dashboard shows 620 'Not responding', 180 'Policy out of date', and 95 'Not installed'. Helpdesk ticket volume is normal. The primary server runs at 90–95% CPU and its database volume is 82% full. The secondary node last synchronized six days ago. About 40% of clients connect through VPN, and two branch sites use NAT. The security manager wants to mass-reinstall the client on all 620 endpoints tonight. The upgrade window was two days ago, and no client package changed. Most affected clients are in the two NAT sites and on VPN, according to a quick sample.
1. Is this most likely a real endpoint failure or a management/reporting problem? Give your reasoning and the first checks.
Read the worked answer
The pattern points first to management and reporting, not 620 broken clients. No client package changed, helpdesk volume is normal, and the timing follows a management upgrade. A primary at 90–95% CPU with a database at 82% can fail to process status updates and policy-install acknowledgments, so clients appear 'Not responding' or 'Policy out of date' even when they are enforcing policy. The stale HA secondary for six days compounds the problem: the dashboard may read from an inconsistent or lagging data set. The concentration in NAT and VPN sites suggests a reachability or status-callback issue, not a client crash. First checks: sample 10 affected endpoints directly, confirm their last policy version and management connection, check primary server services and database latency, verify HA replication, and compare dashboard counts with client-generated logs. Do not mass-reinstall before those checks.
2. What is your troubleshooting sequence, and what evidence would distinguish server overload from NAT/VPN connectivity?
Read the worked answer
Sequence: 1) validate the management server's health-CPU, memory, database free space, disk latency, and service restarts; 2) check HA replication and whether the secondary is serving stale data; 3) test client-to-server connectivity from one NAT site and one VPN client, including the correct service port and NAT translation; 4) compare the client's local policy version and last connection time with the dashboard; 5) inspect policy-install and deployment logs for the affected group. Server overload is supported by high CPU, slow database queries, long policy-install queues, and affected clients across all networks. NAT/VPN connectivity is supported by failures concentrated in those paths, successful local policy enforcement, and client logs showing connection timeouts or certificate name mismatches. A quick packet capture or firewall session table on the NAT device can confirm whether clients reach the management server.
3. What remediation would you approve tonight, and what would you defer? Include communication to the security manager.
Read the worked answer
Approve only low-risk remediation tonight: free database space to below 70%, restart the non-critical management service if approved, repair HA replication, and correct any NAT or VPN rule that blocks status callbacks. Do not mass-reinstall 620 clients; that adds load to an already saturated server and destroys the evidence needed to distinguish reporting from reality. Defer client reinstallation until a sample of affected endpoints is tested and the server is stable. Communicate with numbers: '620 dashboard alerts, but a 10-endpoint sample shows X enforcing current policy; server CPU and database are the likely cause; we will fix HA and database tonight and re-check at 08:00.' Give the manager a decision point: if the sample shows real policy failures, approve a staged reinstall by site, starting with 20 clients, not 620.