Vendor-neutral RMM agent recovery

Repair or reinstall an offline RMM agent?

An offline RMM agent is a failed relationship between endpoint and platform—not automatically a missing service. Use these 24 checks and the decision table to preserve evidence, isolate the failing layer, protect tenant identity, choose a supported repair or controlled reinstall, and confirm every privileged function before closure.

Open the repair vs reinstall matrix Download the matrix CSV Download the 24-control evidence CSV Open the Markdown quick reference Open the agent installation troubleshooting guide Trace certificate or TLS failures Troubleshoot failed remote access Troubleshoot a stuck job Troubleshoot first enrollment Re-run endpoint acceptance Verify a clean uninstall Print this checklist

Repair versus reinstall decision table

Do not choose the action from a red dashboard icon alone. Identify the first failed layer, preserve the current identity and logs, and use the narrowest vendor-supported action that can restore service without hiding the cause.

Evidence	Preferred path	Why	Required proof afterward
Expected package, service, agent identity, and tenant mapping are intact; a narrow service, network, clock, certificate, proxy, policy, or resource dependency is proven.	Vendor-supported repair	Preserves enrollment identity, configuration, audit continuity, and failure evidence while correcting the verified dependency.	New heartbeat plus current inventory, monitoring, patch scan, bounded script, remote access where applicable, and audit evidence.
Agent is healthy but one module is stale or failing.	Repair the module or underlying platform dependency	A full reinstall may not repair Windows Update, a proxy, trust, policy, or security-control failure and can create a second record.	Function-specific success after the normal schedule, not just agent check-in.
Supported repair is unavailable or has failed; package or enrollment state is irrecoverably damaged; removal and re-enrollment behavior are documented.	Controlled reinstall	Reinstallation becomes justified only when evidence, authorization, alternate access, correct tenant/site package, rollback, and record reconciliation are ready.	Clean old-agent removal, correct new identity, no duplicate automation, full functional tests, and old/new record reconciliation.
Device identity, tenant placement, authorization, alternate access, or failure cause is still unknown.	Stop and escalate	Repair or reinstall could enroll the wrong tenant, erase evidence, strand the endpoint, or trigger privileged automation unexpectedly.	Named owner, due date, escalation path, preserved evidence, and an approved next test.

1. Confirm impact

Confirm the endpoint is expected to be online and still in managed scope; rule out planned shutdown, sleep, retirement, or stale inventory.
Record the platform device ID, last heartbeat, last inventory, last successful job, console URL, and displayed time zone before changing anything.
Group affected devices by customer, site, operating system, agent version, policy, network, and first-failure time to distinguish one endpoint from a shared outage.
Confirm approved alternate access, workload criticality, backup state, authority, maintenance window, stop conditions, and customer communication.

2. Verify endpoint state

Use an independent source to confirm power, boot, sleep, network, and isolation state; restore the underlying endpoint first when it is not actually reachable.
Verify the supported agent package, service, startup type, binary path, version, and signature are present and expected.
Capture service state, exit code, process state, crash evidence, and recent start attempts before performing one authorized restart.
Collect agent and operating-system logs for the failure window, preserving timestamps, time zone, first error, and remediation history.

3. Test connectivity

Verify DNS, routing, proxy path, and vendor service status for the exact documented platform endpoints.
Test required outbound ports, TLS negotiation, certificate chain, inspection behavior, and endpoint clock without disabling controls globally.
Review proxy, content-filter, EDR, antivirus, and application-control logs for a specific block or quarantine event.
Confirm trusted time, certificate validity, and trust-store health; repair only the verified narrow dependency.

4. Protect identity

Match local enrollment identity to the intended customer tenant, site, and platform device record before allowing automation to resume.
Search for duplicate, renamed, retired, reimaged, or replacement records using stable hardware and agent identifiers—not hostname alone.
Check whether enrollment credentials, tokens, or certificates were rotated, expired, or revoked and correlate the change to an authorized record.
Separate a heartbeat failure from stale inventory, patching, scripting, or remote-support modules so one broken function does not trigger a destructive reinstall.

5. Repair safely

Define the expected recovery interval, functions to test, success evidence, stop condition, escalation point, and rollback before execution.
Fix the diagnosed service, network, certificate, policy, platform, or resource dependency first and preserve the actor, command or change, time, output, and result.
Prefer the vendor-supported repair path to an immediate reinstall so enrollment identity, configuration, and failure evidence remain intact.
If reinstall is necessary, authorize it explicitly; prove the old agent is removed; control tenant and site placement; and reconcile old and new records before scaling.

6. Validate and close

Confirm a new heartbeat, current inventory, expected agent version, and healthy service state after the documented ingestion interval.
Test monitoring, one bounded script, a fresh patch scan, and remote support separately; capture the corresponding audit evidence.
Reconcile the whole affected cohort into recovered, retired, duplicate, wrong-tenant, offline, unknown, or owned-exception states.
Record the cause, prevention change, monitoring improvement, residual risk, approver, review date, customer acceptance, and closure evidence.

When is an offline RMM agent resolved?

Resolution requires more than a green heartbeat. The endpoint must report under the correct customer and durable device identity; monitoring, scripting, patching, and remote support must produce current results and audit evidence; duplicate or retired records must be reconciled; and every unresolved endpoint must have an owner, due date, escalation path, and time-bounded exception.

Offline RMM agent FAQ

Should I repair or reinstall an offline RMM agent?

Prefer the vendor-supported repair path when the installed agent identity is correct and evidence identifies a narrow service, network, certificate, policy, platform, or resource dependency. Use a controlled reinstall only when the supported repair path is unavailable or fails, the package or identity is irrecoverably damaged, and you can preserve evidence, authorize removal, control tenant placement, and reconcile the old and new records.

Does a new heartbeat prove an RMM agent is fixed?

No. Confirm the correct customer and durable device identity, current inventory, expected agent version, monitoring, a bounded script, a fresh patch scan, remote support where in scope, and corresponding audit evidence after the normal ingestion interval.

What should be recorded before reinstalling an RMM agent?

Record the platform device ID, tenant and site mapping, last heartbeat and successful job, installed package and signature, service state, logs, enrollment identity, affected functions, authorized alternate access, removal method, rollback, and the plan for reconciling duplicate or retired records.