OpenFrame

Troubleshooting a Disconnected Device

IT OPERATIONSOPENFRAMEREMOTE ACCESSTROUBLESHOOTING

Phase 10 — Ongoing Operations · Step 3

Section

June 24, 2026

Published

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Troubleshooting a Disconnected Device

Phase 10 — Ongoing Operations · OpenFrame Onboarding

A device shows OFFLINE and you can't remote in. Before you assume the worst, OpenFrame gives you enough on the device's detail page to figure out why — and most causes are mundane. This guide is the systematic walk-through.

First, read the signals

Open the device from Devices. A disconnected machine shows:

  • An OFFLINE badge at the top.
  • Remote Control and Remote Shell buttons greyed out — they need a live connection, so this confirms the client isn't reachable.
  • An Updated / last-contact timestamp telling you when it last checked in.

The gap between "last seen" and now is your first clue: minutes ago suggests a blip; days ago suggests the machine is off or the client is down.

Narrow it down with the Agents tab

Open the Agents tab. Each agent — Fleet, MeshCentral, Tactical — has its own Status and Last seen. Two patterns to read:

  • All three offline, same last-seen time — the whole client lost contact at once. Usually the machine is powered off/asleep, off the network, or the OpenFrame service stopped.
  • One agent offline, others online — a single component is stuck. The updater service usually repairs this on its next cycle; the others still work in the meantime.

Common causes & where to fix them

Recovery happens on the endpoint — the console shows you the problem, the machine is where you solve it:

  1. Machine is off or asleep — the simplest and most common. Confirm it's powered on and awake.
  2. OpenFrame service stopped — on Windows the service is set to auto-restart (SCM), but a disabled or crashed service won't reconnect. Restart it on the machine.
  3. Network / firewall — the client must reach the OpenFrame server outbound. A new firewall rule, proxy change, or DNS issue at the site will cut it off. Verify connectivity from the endpoint.
  4. Agent token / enrollment — if the device was re-imaged or its enrollment token rotated, it may need to re-enroll. Reinstall the agent to re-establish trust.
  5. Client badly out of date — a stalled updater can leave a device unable to reconnect; reinstalling pulls a clean, current client.

When it won't come back

If you've ruled out power, network, and service state and it still won't reconnect, reinstall the OpenFrame agent on the machine (Phase 2). That re-establishes enrollment and pulls current versions in one step.

For a device that's genuinely retired, use the device "…" menu → Archive Device (reversible record-keeping) or Delete Device to remove it. Don't delete a machine you're still troubleshooting — archive it if you want it out of your active list without losing history.

Quick checklist

  • Confirmed OFFLINE badge and checked the last-seen timestamp
  • Opened Agents tab to see which agents are down and when
  • Verified the machine is on, awake, and on the network
  • Checked the OpenFrame service is running (restart if needed)
  • Ruled out firewall / proxy / DNS changes at the site
  • Reinstalled the agent if enrollment or version was the issue
  • Archived rather than deleted anything still under investigation

What's next

That's the technical side of keeping the fleet healthy. The last operational piece is the commercial one: Billing & Subscription Management.

Based on OpenFrame v0.9.19. Connection behavior depends partly on the endpoint OS, network, and agent state — what's on the machine and in your console wins. This expands on Deploy at Scale and the agent install guides in Phase 2.

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Hi all! My name is Vlad and I’ve been brought on to head the marketing team at Flamingo. Thankfully, this isn’t the first time I will be building a marketing department from scratch, so the experience should come in handy. Now it’s time to dive into the world of MSPs and find myself in this new world.

More in Phase 10 — Ongoing Operations

Related Content

Product Releases

Webinars

Case Studies

Blog Posts

Frequently Asked Questions

MSP AI Agents

Yes. In production MSP shops today, 10% to 25% of tickets close before a human opens them. Thread alone has processed 173 million tickets across 750-plus MSP partners at 96% triage accuracy, handing back 490,000-plus technician hours. Agents own the low-risk, high-volume work (password resets, MFA enrollment, known installs, onboarding and offboarding) and flag anything that touches production data or needs judgment for a human to take.
On a five-person desk, reported deployments show $78,000 to $130,000 in annual direct labor savings, roughly 30% fewer escalations, and 15% to 20% better SLA compliance. Broader MSP adoption data adds ticket handling time cut by 45% and five to 12 points of margin, all from reclaimed capacity rather than headcount cuts.

AI MSP

Automate high-volume, low-risk tasks first. Ticket triage and alert noise reduction top the list because they run constantly and a human still resolves the underlying issue. Save security approvals, billing changes, and client-facing actions for later, always with a human in the loop.

About OpenFrame

OpenFrame isn't built to plug into your stack. It replaces it. Instead of duct-taping a dozen tools together (RMM, MDM, SIEM, patching, remote access, each its own login and bill), we bundle it into one unified platform: RMM, MDM, monitoring, automation, remote access, patch management, security monitoring, and ticketing, plus built-in AI copilots. So "does it integrate with X?" usually means: you won't need X anymore.
Most platforms give you one piece and expect you to bolt the rest on. OpenFrame unifies the whole stack in one place, with AI copilots built in. Fewer logins, fewer bills, less duct tape.
Both. It's built for MSPs and MSSPs alike.

AI for MSPs

AIOps, or AI for IT operations, applies machine learning to monitoring data to correlate alerts and predict failures before downtime hits. Industry figures put the impact at roughly a 30% reduction in downtime and up to 50% faster ticket resolution.

AI Infrastructure

Auto-remediation means the platform executes known fixes itself, like restarting hung services, clearing temp files, or retrying failed backups, then logs and documents the action. It typically covers the predictable majority of level-one infrastructure issues while escalating anything requiring judgment.

RMM Automation

The orchestration layer enriches the alert with device, site, and recent history, then picks one of three paths: self-heal a known issue, escalate, or open a ticket. A ticket is created only when judgment or a human touch is required.

Log Aggregation

Loki collects logs from many systems into one place, storing them cheaply by indexing labels instead of full content. You query them with LogQL inside Grafana. It is built to scale across hosts and clients while keeping storage costs low.