Datto RMM configuration survives testing but resets after restart or sync

Field Summary

Datto RMM configuration survives testing but resets after restart or sync is a RMM / PSA / Automation ticket where the visible symptom can be misleading. RMM and PSA tickets need proof of object identity, policy scope, execution context, automation trigger, and endpoint state. Portal status alone does not prove the endpoint or workflow actually completed. The fastest path is to identify which layer changed and prove it with logs or a repeatable test.

Common Symptoms

• Console status does not match endpoint behavior
• Automation runs manually but fails on schedule or trigger
• Ticket, billing, alert, or script sync creates duplicates or misses expected records

Fast Triage

1. Confirm customer/site, asset/ticket, policy, and user context.
2. Check history, output, timestamps, and recent automation changes.
3. Test a tiny known-safe command before production remediation.
4. Compare with a working asset or ticket in the same policy/client.

Likely Causes

• Agent service hung or partial heartbeat
• Policy or group mismatch
• Script execution context issue
• Variable or credential failure
• AV/EDR blocking execution
• API/integration sync drift

Tier 1 Fix Path

1. Refresh the asset/ticket view and confirm last activity.
2. Restart endpoint agent service only when clearly local and safe.
3. Capture run ID, script name, alert ID, ticket ID, or integration object ID.
4. Do not delete/recreate objects until duplicate/orphan risk is understood.

Tier 2 / Admin Investigation

1. Review agent logs, automation history, variables, permissions, API logs, policy inheritance, and AV/EDR events.
2. Check manual versus scheduled execution context.
3. Validate customer/site mapping and sync rules.
4. Escalate with IDs and timestamps, not screenshots alone.

Advanced Remediation

Agent reinstalls, object deletion, and automation rewrites should follow policy, log, and execution evidence.

Verification

• The affected workflow succeeds from the user side.
• The relevant portal/log shows a clean result at the same timestamp.
• The result survives app restart, reconnect, policy refresh, or reboot when relevant.
• No broad bypass or unrelated change was introduced.

Ticket Notes to Capture

• Affected user/device/site/customer
• Exact symptom, error, timestamp, and screenshot or log excerpt
• Scope tested and working comparison used
• Relevant logs/portals checked
• Root cause or most likely layer
• Fix applied and verification result

Escalate When

• Multiple users, sites, or business-critical workflows are affected
• Logs point to vendor, server, security, or policy ownership outside your access
• A disruptive remediation is required
• The same symptom returns after a verified fix

Prevention

Add the final root cause, detection signal, and validation step to the client runbook. If a change caused the issue, add a post-change check that would catch it next time.