Skip to main content

Manage and Verify Agents

After you deploy, manage the fleet from Configure > Agents. Home dashboard notices for agents that need attention or are offline open this list with the matching filter (sub-orgs included).

When data is flowing, ask questions with AI or confirm a citation in Explore.

The Agents list​

Each row combines device type (workstation, server, or ingest key), connectivity, and collection in one badge.

Filter chips:

  • All
  • Needs attention (collection or health problems)
  • Offline (not checking in)
  • Inactive (silent for a long time)

Sort by health, name, or last check-in. Include sub-orgs is on by default so MSP fleets see client endpoints without an extra toggle.

You can edit description, delete and undelete, and rely on clone detection (shared credential, for example a cloned image that did not re-enroll). See Agent identity and cloning.

Change ownership moves a selected device to another organization (for most MSPs, a client):

  • It is the fix for an endpoint onboarded under the wrong organization, and for a device that changes hands.
  • The move survives later reinstalls, wipes, and image restores.
  • Data collected before the move stays with the organization that owned the device at the time.

See Moving devices and organizations.

If a row says the agent is waiting for its data feed pack, classic Event Log collection has not started yet. That should clear quickly; if it lasts about an hour, see Troubleshooting.

Agent detail​

Select a row. The pane repeats the same status pills as the list, plus a plain-language line when the agent needs attention (including a stop reason when the Windows service stopped for shutdown, uninstall, or upgrade, instead of looking like a mystery offline).

Expanders:

  • Properties: organization, description.
  • System Details: OS, device class (workstation vs server, domain-controller role when reported), agent version, data feed pack version, update status, last ingest / health times.
  • Data feeds: per-feed collection (quiet and caught up vs behind or stuck), skipped-event notices on Event Log feeds, matched-file counts on file sources.

How automatic updates work​

The agent is cloud-managed. It checks the signed CDN for a newer build on your workspace release ring (canary, early-access, or stable), verifies signatures, and applies the update without a technician visit per endpoint.

How soon a published build is picked up depends on the ring: canary is about hourly, early-access is a few hours, stable is about once a day. The first check waits until after startup so a fleet reboot does not stampede the CDN. You can still force or pause updates according to workspace policy; the detail pane's update line is the operator view of that state.

See version and pack version on System Details after a successful apply (next check-in).

Confirm install on an endpoint​

The reliable presence check is the Windows service, not the MSI product code (the GUID changes across versions). The service name is SparkLogsAgent and its display name is "SparkLogs Agent":

Get-Service SparkLogsAgent

Use this same check in RMM and Intune detection rules. See RMM mass-deploy, NinjaOne, and Microsoft Intune.

Verify data is arriving​

Open Explore and confirm events from the endpoint are arriving in the expected organization.

If an agent does not appear or no data arrives, see Troubleshooting.

Delete and remote uninstall​

Deleting a device hides it from the fleet and stops it from sending data. The delete dialog also asks what should happen to the agent still on the endpoint:

  • Uninstall after a number of days (default 60): a grace period, so an accidental delete or a machine that comes back can be undeleted with nothing lost.
  • Uninstall immediately.
  • Never: leave the agent installed and idle.

An optional checkbox also removes local agent state on the endpoint at uninstall time (the same cleanup as PURGE_STATE=1 below). The dialog shows the computed uninstall date, and the deleted device's detail pane shows the same date.

To change the schedule later, select the deleted device and use Uninstall schedule; the dialog opens on Keep current schedule so reviewing it changes nothing. Undelete cancels any pending uninstall and the endpoint resumes on its own, typically within a few hours.

Remote uninstall needs agent 1.9.8 or newer on the endpoint, and the endpoint has to be powered on to receive it. Once a deleted device's agent has checked in and gone quiet, the detail pane shows Agent confirmed dormant with the date; a device that never shows it is powered off or running an older agent. When the scheduled date arrives, the agent uninstalls at its next check-in and finishes cleanup on the endpoint within a day.

Uninstall and reinstall​

Uninstalling the agent removes the Windows service and binaries.

  • By default, local enrollment data and agent state stay on the host, including captured log data not yet uploaded. A reinstall on the same machine continues the same enrollment: same device record, same organization, same workspace.
  • PURGE_STATE=1 on the uninstall command wipes that local state: local identity, all agent state on the endpoint, buffered log data not yet uploaded, agent logs, and crash dumps.
  • A purge leaves the agent's Windows Event Log message file and event source registration in place, so the agent's past events still render correctly in Event Viewer.
  • A purge does not delete the device record in SparkLogs. Reinstalling after one is a fresh install and requires the registration token again.
  • Even after a purge, the endpoint returns to its existing device record and its existing organization. Any registration token in your workspace does that, not only the one the endpoint first enrolled with.
  • The same applies to a machine rebuilt from an image or reverted by a disk-restore tool; see Agent identity and cloning.
  • Reinstalling never moves a device to another organization. Use Change ownership; see Moving devices and organizations.

If there is no device record to return to, what happens depends on why:

  • You deleted the device on purpose: reinstalls into the same organization stay blocked until you undelete it on Configure > Agents. Installing into a different organization enrolls the machine there as a new device.
  • The record was removed some other way (rare): the install just works and the device gets a fresh identity.

Silent uninstall with purge:

# Read MSI product code from registry
$productCode = (Get-ItemProperty -Path 'HKLM:\SOFTWARE\SparkLogs\Agent' -Name ProductCode -ErrorAction Stop).ProductCode
# Uninstall the agent with PURGE_STATE=1 to clear agent identity and state
$p = Start-Process msiexec -Wait -PassThru -ArgumentList '/x',$productCode,'/qn','PURGE_STATE=1','/l*v',"$env:TEMP\SparkLogsAgent-uninstall.log"
# Exit code 0 means success, or 3010 means a reboot is required before uninstall is complete (uncommon)
$p.ExitCode

Omit PURGE_STATE=1 or uninstall via any other method for the agent to keep its identity and state. NinjaOne's native Uninstall Program is a non-purge path; see NinjaOne.