Should I repair or reinstall an offline RMM agent?

Prefer a vendor-supported repair when the installed package, device identity, and tenant mapping are intact and evidence identifies a narrow dependency. Use a controlled reinstall only after supported repair is unavailable or has failed, removal and re-enrollment are documented, alternate access exists, and duplicate records can be reconciled.

Does a new RMM heartbeat prove the agent is fixed?

No. Verify the correct tenant and device identity, current inventory, monitoring, a fresh patch scan, a bounded script, remote access where in scope, and audit evidence after the normal ingestion interval.

When should an RMM agent repair be stopped and escalated?

Stop when authorization, tenant placement, endpoint identity, alternate access, business impact, or the failure cause is unclear; when suspected compromise exists; or when rollback cannot be performed safely.

Vendor-neutral RMM agent recovery

Repair, reinstall, or stop?

A missing check-in is not proof that an agent needs reinstalling. Use this four-state decision matrix to preserve evidence, protect tenant and device identity, choose the narrowest supported recovery path, and prove every privileged function works before closing the incident.

Download the decision matrix CSV Run the 24-step offline-agent checklist Troubleshoot a failed upgrade Verify agent removal Open the installation troubleshooting guide Print this matrix

RR-01 · Supported repair

Identity is intact; one dependency is proven

Choose this when: The expected signed package, service, agent identity, device record, and tenant mapping remain intact, and evidence isolates one network, certificate, policy, clock, platform, or resource dependency.
Required before change: Current vendor procedure, authorization, maintenance window, alternate access, rollback, expected recovery interval, and preserved failure-window evidence.
Success proof: Correct identity, new heartbeat, current inventory, monitoring, fresh patch scan, bounded script, remote access where in scope, and corresponding audit evidence.

RR-02 · Module repair

Check-in works; one function does not

Choose this when: The heartbeat and identity are current but patching, scripting, inventory, monitoring, or remote access is stale or failing.
Required before change: Module logs and status, policy and job history, underlying platform evidence, a bounded test, rollback, and the function's normal result schedule.
Success proof: A new function-specific result after the normal schedule, with audit evidence and no unintended policy, identity, or tenant change.

RR-03 · Controlled reinstall

Supported repair failed or state is irrecoverable

Choose this when: Supported repair is unavailable or has failed, package or enrollment state is demonstrably damaged, and official removal plus re-enrollment behavior is documented.
Required before change: Explicit authorization, alternate access, the correct tenant/site package, trusted package evidence, tamper-protection procedure, rollback, and a duplicate-record reconciliation plan.
Success proof: The old agent is cleanly removed, the new identity is correct, duplicate automation is absent, all functional tests pass, and old/new records are reconciled.

RR-04 · Stop and escalate

Authority, identity, access, or impact is unclear

Choose this when: Device identity, tenant placement, authorization, alternate access, failure cause, business criticality, or production impact is unknown.
Do not: Restart, repair, remove, reinstall, re-enroll, or suppress alerts merely to make a dashboard green. Preserve current facts and gaps.
Resume only when: A named technical and business owner accepts the next step, authority and safe access are confirmed, missing facts are resolved, and one evidence-based path is approved.

A green check-in is not the finish line

Confirm the endpoint returned under the intended customer, site, and durable device identity. Then test inventory, monitoring, alerting, one bounded script, a fresh patch scan, and remote support where in scope. Wait for each function's normal ingestion or execution interval and preserve the matching audit record. A heartbeat alone proves only that one communication path produced a recent event.

Before repair

Preserve package and publisher, service and process state, agent/device IDs, tenant mapping, timestamps, logs, last known successful functions, authorization, and alternate access.

Before reinstall

Add the official removal and enrollment procedure, correct tenant/site installer, trusted package evidence, tamper-control steps, rollback, duplicate search, and record-reconciliation owner.

Before closure

Reconcile the full affected cohort into recovered, unaffected, deferred, failed, retired, duplicate, unsupported, or time-bounded exception states—each with an owner and next action.

Primary references and interpretation limits

Microsoft: Service Control Manager describes the Windows service database and service-control model used when confirming service identity and state.
Microsoft: Windows Installer logging documents installer logging modes that can preserve evidence for MSI-based agents.
Microsoft: Windows Installer best practices describes servicing, rollback, package, and security considerations for MSI packages.
Microsoft: App Control debugging and troubleshooting documents evidence sources for application-control blocks. Vendor-specific agent procedures, identities, cleanup tools, and return codes remain authoritative.