OpenFrame

Run a Script on a Device

AUTOMATIONGUIDEOPENFRAMESCRIPTSTUTORIAL

Phase 5 — Scripts & Automation · Step 2

Section

June 19, 2026

Published

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Run a Script on a Device

Phase 5 — Scripts & Automation · OpenFrame Onboarding

There are two places you can kick off a script: from the Scripts section (run one script against many devices) and from a device's own page (run against just that machine). They look similar but behave a little differently — especially around variables — so it's worth knowing both.

Before you start

  • The target device needs the OpenFrame agent installed and online (offline devices can't execute).
  • The script's Supported Platform has to match the device's OS — OpenFrame only offers a script to machines that can run it.
  • Know whether the script takes arguments, environment variables, or neither (the script's description/comments usually say).

Option A — Run from Scripts (one script → many devices)

This is the way to push a single script across a fleet.

  1. Go to Scripts → Scripts List and open the script (click its arrow, or "…").
  2. On the detail page, click Run Script.
  3. Set the Timeout (seconds) if the default doesn't fit.
  4. Add Script Argument and/or Add Environment Var to pass values for this run. This is your chance to override defaults without editing the script.
  5. Pick your targets in the device selector — tick individual machines, filter by Device Tags, or Add All Devices. Switch to Selected Devices to review scope.
  6. Click Run Script. You'll get an Execution Started confirmation, and you can track progress in the activity logs (see Script Results & Output Logs).

Option B — Run from a Device (one device → pick a script)

When you're already looking at a single machine and want to act on it, run from there instead. Open the device's detail page and use its Run Script action (covered step-by-step in Running a Script, Phase 3). You choose a script, supply any inputs, and it runs against that one device.

Use this when you're troubleshooting a specific machine; use Option A when you're rolling something out broadly.

Why variables can behave differently

This is the part that trips people up:

  • Script Arguments are passed on the command line (an argument with an empty value acts as a flag).
  • Environment Variables are passed to the script's environment instead. Many of the bundled Tactical (TacticalRMM) scripts read their parameters from environment variables, not arguments — their comments will literally say "all parameters are passed using environmental variables." If you pass a value as a command-line argument when the script expects an env var (or vice versa), the script ignores it and uses its defaults.

So before you run: check how the script expects to receive input, and put your value in the matching field. When in doubt, open the script's Syntax on its detail page and read the top comments — they tell you which variables it looks for.

Tip: the Run Script screen exposes both Add Script Argument and Add Environment Var precisely because different scripts want different things. Match the field to what the script reads.

After you run

OpenFrame queues the execution and reports back as each device finishes. You won't see output inline — it lands in the activity logs. Head to Script Results & Output Logs to read results and debug anything that failed.

Quick checklist

  • Confirmed the device is online and the OS matches the script
  • Chose the right entry point: Scripts (many devices) vs device page (one device)
  • Passed inputs in the correct field — Script Argument vs Environment Var
  • Selected targets (individually, by tag, or Add All)
  • Ran it and noted to check the activity logs for results

What's next

Ready to build your own instead of running a library script? Create Your First Script walks through the editor, variable inputs, and a test run. To make a script run on a cadence, see Schedule a Script.

Based on OpenFrame v0.9.19. The bundled scripts and their variable conventions come from the TacticalRMM ecosystem and can change — always read the script's own comments before running.

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 5 — Scripts & Automation

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.
An AI agent for an MSP is software that reads a ticket, decides the action, performs it across your tools, and records the result without a technician driving each step. It differs from a chatbot or copilot by taking action, not just suggesting one.

AI MSP

MSPs use AI to triage and route tickets, cut alert noise, schedule patches, assist L1 security work, and draft client reports. Kaseya's 2025 benchmark found 30% already use it to eliminate tedious tasks, with ticket triage the most common starting point.
Start with a readiness assessment, not a tool purchase. Confirm your ticket history is clean and your RMM, PSA, and monitoring systems connect. Then pick one high-volume, low-risk workflow, usually ticket triage, and pilot it on internal tickets before any client sees it.
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.

AI for MSPs

Set a baseline before rollout, then track tickets closed per technician, mean time to resolution, percentage of tickets resolved with no human touch, technician hours reclaimed, and cost per ticket. AI-driven automation commonly cuts operational cost per ticket by 25 to 40%.
No. AI automates routine tickets, patching, and monitoring, but trust, accountability, and complex business judgment still need people. The future of managed services moves technicians from closing tickets to advising clients, which makes the human role more valuable, not obsolete.

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.

AI Infrastructure

AI-powered infrastructure managed services apply machine learning to infrastructure telemetry so providers can predict failures, automatically remediate known issues, and forecast capacity needs. They replace static-threshold monitoring and manual firefighting with predictive, largely automated operations overseen by technicians.