The installer said finished. Windows shows the program installed. And yet the PC has not reported a thing in three days. Verification is its own skill — this page shows what 'alive' actually looks like, and how to prove it in two minutes.
An agent is alive when three things agree: the console shows the computer with a recent last-contact time, the PC itself shows the agent service running with its tray icon, and the console's scan data keeps moving — inventory and patch scan times update. Any one of these alone can lie. An installed agent can be stopped; a PC in the console list can be a ghost of a machine retired last month. This guide verifies all three, explains the one delay that is normal (the refresh cycle), and separates the two look-alike problems: a dead agent on a living PC, and a perfectly good agent on a PC that is simply off.
Open Agent → Computers (the Scope of Management list) and read the row for the PC: it should show the computer present, its agent version, and a last-contact time that is recent relative to when the PC is used. A machine used daily should rarely be more than a working day stale. This single column settles most arguments: if last contact is fresh, the agent is communicating with the server, whatever the user believes is installed. If it is days old on a PC that is on the desk and in use, you have a real agent problem to chase — keep reading down this page in order.
Do not panic at a quiet first hour. Endpoint Central agents work on a refresh cycle of about 90 minutes for policy and settings changes: a configuration you just deployed, or a protection setting you just enabled, can legitimately take a cycle to show its effect. The first check-in after installation normally appears much sooner than that, but full scan data builds over the first cycles. The practical rule: verify the check-in the same day, verify scans the next day, and only chase a machine whose last contact stays frozen across a full working day while the PC is demonstrably on and in use.
On the client PC, two signs confirm the agent locally. The agent icon in the system tray shows the agent is present and running for the logged-in user. And in services.msc the ManageEngine UEMS agent service should be present and running — it is the engine that survives logoffs and reboots. If the tray icon is missing but the service runs, the agent is usually fine and only the user-side component has not started. If the service itself is stopped and restarts fail, note what you find: a service that users keep stopping is a policy problem (the protection settings can restrict stopping the agent service), while a service that crashes on a healthy PC is a repair-or-reinstall problem.
A communicating agent should also be a working agent. In the console, open the computer and look at its inventory scan and patch scan times: both should advance on their schedules. A PC whose last contact is fresh but whose patch scan is a month old is telling you something specific — communication works, scanning does not — which points at the agent's health rather than the network. Trigger a scan from the console for that computer and watch whether the time updates. This three-proof check (contact, service, scans) takes two minutes and replaces the much slower hobby of reinstalling agents on suspicion.
The two look identical in the console: an old last-contact time. Separate them with evidence from outside Endpoint Central. Is the PC on the network at all — does it answer a ping, appear in DHCP or switch tables, is someone sitting at it? A laptop on leave, a PC unplugged for a cabin reshuffle, a machine retired without telling IT: these are inventory truths, not agent faults, and the fix is updating your records (and removing genuinely retired machines from the Scope of Management so reports stay honest). A PC that is on, networked and in daily use but silent in the console is the real dead-agent case — work on that machine: check the service, then repair or reinstall the agent using the failure ladder.
Verification should not wait for a user complaint. Once a week, sort the Computers list by last contact and look at the stale end. Every office accumulates a few: the laptop that has not docked in a fortnight, the training-room PC switched off at the wall. A short stale list reviewed weekly stays short; the same list discovered at audit time is a crisis and a lie in your compliance reports. Also watch agent versions in the same view — a machine stuck on a much older agent version while the fleet has moved on is tomorrow's problem announcing itself early (the agent updates guide covers that case).
The console download and client install from the video — the process whose check-in this guide teaches you to verify.
▶️ Watch Full VideoThe first check-in normally appears quickly, but allow the agent a refresh cycle — about 90 minutes by default — before treating absence as a fault. If the PC is on and still missing after a working day, work the failure ladder.
Not necessarily — communication and scanning are separate proofs. A fresh last-contact time with a stale patch scan points at the agent's scanning function: trigger a scan from the console and watch the timestamp, then repair or reinstall if it stays frozen.
The agent runs as a service. Endpoint Central's Agent Protection Settings can restrict users from stopping the agent service and from uninstalling the agent, which is the right setting for office PCs you manage.