Agent Management

Agent Properties Modal

Open it with Configure on the agent row, then View Health. The modal has five sections:

1. Information Grid

  • Server Name, Agent ID, Type, Status (with colored indicator), Last Heartbeat, Version, Environment, Mode, Tags

Server Name follows the host machine name. If you rename the underlying computer, the agent picks up the new name on its next start-up and reports it, and the dashboard updates automatically on the following heartbeat — no manual edit needed.

2. Health Metrics

  • CPU and Memory usage cards with color-coded thresholds (green/yellow/red)
  • Values from the latest health report (updated every 30 seconds)

In the Agents list, an agent that has sent no health sample for 7 days shows No health data in 7 days in the CPU column instead of figures. Hover over it to see whether the agent is online and when its last heartbeat arrived. An agent counts as online when its last heartbeat arrived within the last 5 minutes.

3. Collection Control

  • Start Full — begins continuous ETW collection
  • On-Demand — starts time-limited collection
  • Stop — ends all ETW collection, returns to Health Only

A status bar shows the current collection state and active provider count.

4. Interactive Query Session

  • Current session ID and event count (if active)
  • Begin Session / End Session buttons to control live sessions from properties

5. Delete Agent

  • Only organization admins can delete an agent.
  • Requires two confirmations before proceeding
  • Sends a silent uninstall command to the agent ("C:\Program Files\ETDucky\Agent\uninstall\unins000.exe" /VERYSILENT on Windows) over the agent's live connection
  • The modal closes and a message confirms the deletion
  • About one minute later, the agent record and all associated data are permanently deleted from the database

From the moment you confirm, the server answers the agent's heartbeat with the fact that it was deleted, and the agent goes dormant on its next heartbeat. This covers an agent that missed the uninstall command, for example because it was offline when you deleted it. Deleting several agents at once from the selection bar has the same effect for each of them.

  • Windows: the agent stops event collection and does not start it again. It keeps sending heartbeats.
  • Linux: the agent stops uploading events and keeps sending heartbeats. A Linux agent that received the uninstall command removes itself once its heartbeat confirms the deletion. A Linux agent that missed the command stays installed and dormant until you remove it.
  • Dormancy is not stored on the host. After a restart the agent runs until its first heartbeat, about a minute, and then goes dormant again.
  • To bring a deleted host back, register its agent again.

Agent versions earlier than 2.7.8.7 do not act on this answer. They keep running until the uninstall command reaches them or the agent is removed by hand.

Deactivated agents

An agent is deactivated when its organization has had no agent seat for it for 30 days, for example after a subscription ends. A deactivated agent goes dormant in the same way on its next heartbeat. When seats are available again the agent is reactivated, and it resumes on its next heartbeat with its existing enrollment. No reinstall or re-enrollment is needed. See Pricing & Billing for the full sequence.

Inventory Drawer

The Inventory button in the Agent Health modal opens a drawer on the right with the host's latest inventory report. The same drawer opens from the bar that appears when you tick one agent in the list (Inventory); with several agents ticked that button is inert and points to the fleet view under Systems, Patch Management, Agents, By app. The bar's Monitoring button applies a monitoring preset to every ticked agent. The agent reports at start-up and every 24 hours. The tabs are OS, Software, Services, Scheduled, Sockets, Modules and Persistence. The header shows the agent id, platform and the time of the report.

Software tab

One row per installed application with Name, Version, Source (winget, registry, hotfix, a Linux package manager, or MSIX / Store), Publisher, Installed date, Installed for and Install path. The table is wider than the drawer, so scroll it sideways to reach the last two columns.

  • Installed for reads All users for machine-wide apps. On Windows, apps installed in one user's profile show that user's account name. The agent reads a user's list while that user is signed in. While the user is signed out, the agent keeps sending the last list it read, and the row reads signed out, list as of <date>. The list is read again at the next sign-in. Lists for deleted profiles, and lists older than 90 days, are dropped.
  • Install path is the folder the app is installed in when the agent can determine one: the installer's recorded location or the folder of the main program on Windows, the snap mount for snaps on Linux. dpkg, rpm and flatpak packages have no single install folder and show none. Hotfixes and some redistributables show none.
  • MSIX / Store rows are Microsoft Store and other MSIX packages, listed for the user they are installed for, with the package family name in the Source column and the WindowsApps folder as the path. Store-signed apps and sideloaded (developer or enterprise signed) apps are listed. Frameworks, resource packages and Windows inbox components are left out.

Refresh

Refresh asks the agent for a new inventory now. The drawer waits for the agent to report, then reloads with the new report time and Updated just now. A Windows pass runs winget and the offline Windows Update search, so it usually takes 15 to 60 seconds. If no new report arrives within two minutes, for example because the host is offline, the drawer says so and keeps the previous report; the agent reports at its next check-in.

Agents older than 2.8.1.0 send the machine-wide list only. Their rows read All users with no path until the agent updates. Linux agents do not report per-user or Store rows.

Remote Management

Collection Control

  • Start Full/On-Demand/Stop buttons in Properties modal
  • Agent picks up commands on next heartbeat (within 30 seconds)
  • Live Sessions automatically start and stop collection

Configuration Push

  • Changes in the Configure modal are saved server-side
  • Agents poll for updates every 30 seconds
  • Server-side config overrides local AgentConfig.json
  • No agent restart required for most settings

Applying a preset to many agents

Tick agents in the All Agents grid and choose Monitoring in the selection bar to apply one monitoring preset across the whole selection. This is the fastest way to move a set of hosts off Health Only, the one preset that stops behavioural detection and app-baseline learning, and back onto Minimal Monitoring.

  • Presets only, by design: a preset states capture posture, mode and providers explicitly, so every selected agent lands on the same known state. A partial field edit would leave each agent keeping whatever it already had for the keys you did not set.
  • Requires the Technician privilege (administrators and owners have it). Members see the button but get a clear refusal, because the server decides, not the browser.
  • Agents under network isolation and unlicensed agents are skipped, and you are told which ones and why rather than being given a count.
  • Every bulk push is recorded in the audit log with the operator, the preset name, the agents it reached and the agents it skipped.

Organization-wide telemetry and heartbeat settings

Two cards under Team → Workspace set what every agent in the organization is asked to send. Agent Telemetry Directive sets the minimum event level, sample rate and significance profile for bulk event telemetry. Heartbeat Detail turns off optional heartbeat blocks: processes, services, the event log summary, network adapter detail and signed-in sessions. See Configuration for each setting and its rules.

  • Only organization admins can change them. Every save is recorded in the audit log.
  • Agents are sent the settings on every heartbeat and apply them once they run a version that supports them. No agent version available today applies them yet, so agents keep sending everything they sent before.
  • The dashboard sets them for the whole organization. It has no per-agent control.

Self-update checks

Agents check for a new version 5 minutes after they start and then every 6 hours. From agent 2.8.5.2 the 6 hours are counted on the clock, so time a laptop spends asleep counts toward the next check; earlier agents waited 12 hours of awake time while connected, which on a laptop that sleeps overnight was about a day.

Self-update outcome reports

When an agent updates itself, it records the attempt before the installer (Windows) or the package manager (Linux) starts, and on its next start reports how the update ended: succeeded when it is running the new version, failed when it is not, or unknown when no outcome was seen within seven days. A failed report carries the last lines of the installer or package manager output, at most 20 lines and 2,000 characters, with any line that looks like a credential left out.

  • Each attempt is recorded in the agent's private state folder until the server accepts the report, for at most 30 days. A report the server cannot store is dropped rather than resent. A later attempt never replaces an earlier report that has not been sent.
  • The server takes the organization and agent from the agent's own credential, never from the report.
  • The dashboard does not show these reports yet. The agent's version on the Agents page, updated by its heartbeat, remains the way to see which version each agent runs.