Uniportal Runner

A feature of the Datto RMM and NinjaOne integrations. Add one Uniportal-managed script to your RMM so the AI can run common Active Directory and device tasks without you writing or maintaining scripts.

The Uniportal Runner is a feature of the Datto RMM and NinjaOne integrations, not a separate integration. You turn it on by adding a single script to your RMM, once. After that, Uniportal can run its own managed scripts for common tasks, like creating an AD user or resetting a password, on your customers' domain controllers and devices. You don't write those scripts and you don't maintain them.

This is an option, not a requirement. You can still build and run your own scripts in Datto RMM, and some jobs will always need that. The Runner covers the basic workflows so you only script the ones that are specific to you.

Uniportal-managed, not AI-written

The scripts the Runner executes are written, tested, and maintained by Uniportal. The AI does not write PowerShell on the fly and send it to a customer's domain controller.

The AI's job is to decide which managed script fits the ticket and what inputs to pass, such as which username. The script itself is fixed before the AI ever sees the ticket.

What it covers

The managed scripts cover the everyday helpdesk work that usually forces you into the RMM. Each one shows up on the Agent Tools page as its own tool with its own Mode. A few examples:

AD users: search and read an account, create a user in a specific OU, update profile fields, enable, disable, or unlock an account, reset a password, and investigate a repeat lockout.
Groups and OUs: add or remove a group member, see why a user has access through nested groups, and move a user to another OU with the Group Policy impact shown first.
Offboarding: Preview AD Offboarding plans the whole thing without changing anything, then each step runs as its own tool.
Servers, sync, and files: find a customer's domain controller, start an Entra Connect sync so an AD change reaches Microsoft 365 now, and read or change folder permissions on a file server.
Device health: Get Device Performance for "it's slow" tickets, and Get Device User Sessions to find who is logged on.

We're adding more AD tools as we go, so treat this as the shape of it and not the full catalog. Your Agent Tools page always has the current list. If there's a specific AD task you want, let us know.

How it works

You add one script, named Uniportal Runner, to your RMM. When a ticket calls for a task, Uniportal sends the job through your RMM to the right device, and the Runner on that device picks up the Uniportal-managed script for that task and executes it.

Each run reports back through these states: dispatched, fetched (the device picked it up), then completed, failed, or expired. A run that never got to the device shows dispatch_failed, and one the device never picked up shows expired. Neither is reported as done.

Two things are enforced on that path:

Nothing runs unless Uniportal signed it. The Runner only executes scripts that carry a Uniportal signature. Anything else is not run. That is why you paste the Runner in unchanged: it is the part that does the checking.
Passwords do not pass through your RMM. For Create AD User and Reset AD User Password, if the technician doesn't supply a password, Uniportal generates one and shows it to the technician. It is not in the script result.

The AD tools also carry their own limits, built into the scripts:

Protected accounts and groups. Changes to protected admin accounts, and to privileged groups like Domain Admins, are refused unless the technician confirms and the AI passes an explicit override. Privileged groups are never copied when you mirror a colleague's memberships.
Before and after. Change tools report the state before and after, and whether the change was verified. A change that was already in place reports that nothing changed.
Previews. Moving an object and changing file permissions both support a preview, so the technician sees the plan first.
Domain controllers are never moved, and file permission changes refuse system paths and never remove SYSTEM or Administrators.

Prerequisites

Datto RMM or NinjaOne already connected to Uniportal. The Runner rides on that connection. Set up Datto RMM or NinjaOne first.
Admin/Owner role in your Uniportal tenant.
Access in your RMM to create a component (Datto RMM) or a script (NinjaOne).
An online Windows device in the RMM to test on. Ideally a domain controller at a test customer, not a production one.

Setup

The Runner script is on the integration page for your RMM, under Integrations > Datto RMM or Integrations > NinjaOne. Open that page and start the Uniportal Runner setup. It is a three-step dialog, and you copy the script from it. The steps are the same in both RMMs. The details in step 1 differ, so pick your RMM below.

Add the script to your RMM

The dialog shows exactly what to enter and has a copy button on each field. Use those instead of retyping. It also has Copy script and Download buttons for the script itself. The script is filled in for your workspace, which is why you copy it from the dialog and not from somewhere else.

In Datto RMM, open Automation > Components > New Component and set:

Field	Value
Name	`Uniportal Runner`
Description	`Runs scripts signed by Uniportal for Uniportal's AI tools. Do not edit.`
Variable (string, no default)	`ExecutionId`
Variable (string, no default)	`Token`
Category	Scripts
Script type	PowerShell (not Batch)

Paste the script unchanged as the component's script, then Save.

Create both variables with no default value. Uniportal supplies ExecutionId and Token on each run, so there is nothing for you to fill in.

Click Download instead of Copy script if your browser mangles pasted code. Either way, don't edit the script. If you need different behavior, build your own script alongside it. Don't change the Runner.

When the step is done, the dialog marks it Installed. Click Next: link it to Uniportal.

Link it to Uniportal

This ties the script you just created to your workspace, so Uniportal knows which item in your RMM is the Runner. When it's done, the step shows what it linked to: a Datto RMM component UID, or a NinjaOne script ID.

Uniportal needs that link because RMMs run things by ID, not by name. A script renamed or duplicated in the RMM is a different item to it, and Uniportal has to point at the right one.

Test on a device

Run the Runner against a Windows device and check that it succeeds. The step shows the time of the last successful run, for example 10/24/2026, 4:48:41 PM.

Test before you trust it with a ticket. A failure here is a setup problem you can fix in a minute. The same failure during a password reset is a user waiting on you.

Access control and Skills

The AD tools behave like every other Agent Tool, so you control them the same way:

By role. The AD tools are more tools on the Agent Tools list, so a custom role includes or leaves out each one individually. A tool a role doesn't include is denied. Your service desk role can have Get AD User and Unlock AD User without Reset AD User Password or Disable AD User.
By Mode. Set the Mode on each tool individually. Read tools default to Automated and tools that change something default to Approval Required, and you can change either one tool at a time. Resetting a password deserves a tighter setting than reading a device's performance.
In Skills. Uniportal AI calls these tools the same way it calls any other, so you can reference them in a Skill. A Skill carries the judgment: confirming that Michael Scott actually approved the new hire, or that Toby in HR is the one asking to disable an account, before anything runs. A new hire Skill might search for a colleague with Search AD Users, create the account with Create AD User, then start a sync so it reaches Microsoft 365.

Permissions and Modes are enforced by Uniportal, not by the AI's instructions, so they hold even if the model decides it knows better.

After setup

Pick the AD server once. AD tools need to know which device is the customer's domain controller. Find AD Servers shortlists likely candidates from your RMM inventory, the AI profiles the top one with Get Device Execution Context, and once the technician confirms, the device is saved to company memory. Every later AD task for that customer reuses it. The first ticket is the slow one. Run Test AD Management Readiness at that point, so a missing right shows up now and not halfway through an onboarding.
Run file permission tools on the file server, not the AD server, and run Start Directory Sync on the active Entra Connect server, which often is not the domain controller.
Check the job in your RMM after the first few runs, not just the AI's summary. It is the quickest way to learn what these tasks actually do.

Runner or your own scripts

Use the Runner for the standard tasks above. Build your own scripts for anything specific to how you run a customer: a nonstandard OU layout, a file-server cleanup, a vendor tool you only use at one site.

You can use both in the same workspace. The Datto RMM page covers building your own.

Troubleshooting

The test run fails

Check the script was pasted unchanged, with no edits and nothing trimmed. A stray character from a rich text editor is enough to break a PowerShell script. Use Download and paste from the file, or re-copy with Copy script.

Datto RMM: the component won't run

Check the Script type is PowerShell, not Batch, and that both variables exist with the exact names ExecutionId and Token. Names are case sensitive. Also check the API user's Component level is Super (5), as described on the Datto RMM page.

NinjaOne: the script runs but does nothing

Check Run as is System and Operating system is Windows. A script that runs as a standard user can't touch AD, so it can start fine and still not be able to do the job.

An AD change fails with access denied

The Runner executes as whatever identity the RMM agent uses on that device, and that identity needs rights in AD. Run Test AD Management Readiness against the OU in question. It reads the OU's permissions and tells you whether the identity can create users, write properties, and reset passwords there, without changing anything.