MantisOps · Installation Guide

Installing the MantisOps Agent

Last updated October 2026 · Applies to MantisRMM, Mantis360 and MantisNMS

How to install, deploy, update and remove the MantisOps agent on Windows, macOS and Linux, and what to do when an install doesn't go as planned. If you just want the one-line command, see Windows, macOS or Linux.

Overview

The MantisOps agent is one agent for all three products. A single background service runs a module for each product your account is licensed for: MantisRMM management, Mantis360 security posture, and MantisNMS host metrics. The agent checks your licenses itself and starts or stops modules to match, so adding a product to your subscription later needs no reinstall. With more than one product, see MantisOps Complete for how they work together (the Portal Alerts inbox and Devices page, and the cards each product shows for the other).

Every install command contains an enrollment code. The code tells the agent which account (and, optionally, which company) it belongs to. One code enrolls the endpoint into every product your account is licensed for.

Configuration and the device's own secret key are kept in C:\ProgramData\MantisOps (Windows) or /etc/mantisops (macOS and Linux). Both are locked down to administrators/root.

Before You Start

Supported systems

Permissions

• Windows: an elevated PowerShell (Run as administrator), or a deployment tool that runs as SYSTEM.
• macOS and Linux: root, or sudo. The installer stops with Run with sudo/root otherwise.

Network access

The agent only makes outbound connections. No inbound firewall rules or port forwarding are needed. Allow outbound HTTPS (TCP 443) to:

If outbound traffic passes through a proxy or a firewall that inspects TLS, exempt these hosts from inspection and allow WebSocket upgrades. A broken WebSocket shows up as an agent that enrolls but stays offline.

Enrollment Codes

Enrollment codes start with mek_. Find yours in the Customer Portal (portal.mantisops.net) → Agents & Probes → Enrollment codes. The install commands on that page already contain the right code: the code is masked until you click Reveal, and Copy always copies the complete command. The same commands are in MantisRMM under Devices → + Add device.

Which code does what

Who can see and manage codes

• Customer Portal: account admins and owners can see, copy, create, rotate and revoke codes. Everyone else sees <YOUR-ENROLLMENT-CODE> in the commands.
• MantisRMM: users who are allowed to add agents can reveal and copy the install code in + Enroll Agent. Only account admins can create, rotate or revoke codes (Manage enrollment codes). Users restricted to certain companies only see those companies' codes.
• Codes are never displayed during a MantisOps support session.

Rotate or revoke a code

• Rotate replaces a code with a new one. The old code keeps working for a grace period you choose (0 to 720 hours, 24 by default), so scripts can be updated without a gap. The commands in the Portal switch to the new code right away.
• Revoke stops a code immediately.
• Neither affects devices that are already installed. They keep working; only new installs with the old code stop.

Windows

Open PowerShell as Administrator (Start → type "PowerShell" → Run as administrator) and run:

The Portal's Agents & Probes page shows the same install split over two lines ($env:TENANT='…', then irm … | iex). Both do the same thing.

The script:

1. downloads the latest signed agent to C:\Program Files\MantisOps\mantis-agent.exe;
2. enrolls the computer with your code;
3. registers and starts the MantisAgent service, and waits up to about 20 seconds to confirm it's running.

Success looks like:

If anything fails, the script stops with an error that says what went wrong and where the log is, and returns a non-zero exit code to deployment tools. A failed enrollment never leaves an idle service behind. Because nothing is downloaded through a browser, Windows SmartScreen doesn't prompt.

The computer appears in MantisRMM under Devices, and in the Portal under Agents & Probes → Deployed devices, usually within a minute.

Install with a setup code (MantisOps Setup)

For a user who shouldn't have to paste a PowerShell command, send them the MantisOps Setup installer and a short setup code instead:

1. In MantisRMM, go to Devices → + Add device → Windows → Other options: send an install link or download the .exe.
2. Click Generate install link. By default the code works for one computer and expires after 7 days. Tick Reusable for several computers (30 days) for a code several people can use.
3. Click Copy message and send it. It contains the download link and the setup code.

The recipient downloads MantisOps-Setup.exe (signed by MantisOps, LLC) from https://api.rmm.mantisops.net/agent/unified/setup-installer/windows, approves the Windows administrator prompt, types the setup code and clicks Install. When it finishes it shows All set - MantisOps is installed and running. Behind the scenes, the installer swaps the setup code for a one-time enrollment code that's valid for one hour and one computer.

On a computer that already has the agent, the button reads Reinstall. Computers installed this way aren't assigned to a company; assign them in MantisRMM afterwards.

macOS

Open Terminal as an admin user and run:

The same command works on Linux; the script detects the operating system. On a Mac it:

1. saves your code to /etc/mantisops/enroll.token (the file is deleted once the Mac is enrolled);
2. downloads the signed, Apple-notarized MantisAgent.pkg (universal: Apple silicon and Intel) and installs it with the macOS installer, so Gatekeeper doesn't warn;
3. the package installs /Applications/MantisAgent.app, enrolls the Mac and starts the launch daemon net.mantisops.agent.

Success looks like:

If the enrollment is refused, the script stops the daemon and says so, with the log location (see Troubleshooting).

macOS privacy permissions

Apple doesn't let an app grant itself access to the screen, input or protected files. Remote desktop and some features need these permissions for MantisAgent:

Managed Macs (MDM): deploy the MantisOps PPPC configuration profile through your MDM (Jamf, Kandji, Mosyle, Intune and others). It pre-approves Accessibility and Full Disk Access for bundle ID net.mantisops.agent, Team ID 7G5UR2WS94. The profile includes Screen Recording, but Apple doesn't let most MDMs grant it silently, so expect the user to approve Screen Recording once. Double-clicking the profile doesn't grant anything; it has to come from an MDM.

Without MDM: on the Mac, open System Settings → Privacy & Security, enable MantisAgent under Screen Recording and Accessibility, then restart the agent so the change takes effect:

In MantisRMM, a Mac's overview shows whether Screen Recording and Accessibility are granted.

Linux

Run as root, or with sudo:

Keep TENANT=… after sudo exactly as shown, so the code reaches the script. The script downloads the agent for your architecture (amd64 or arm64) to /usr/local/bin/mantis-agent, enrolls it, writes the systemd unit /etc/systemd/system/mantis-agent.service (restarts automatically, starts at boot) and waits up to about 20 seconds to confirm the service is active.

Success looks like:

Check on it at any time with:

Companies & Sites

An enrollment code can carry a company. A device installed with a company's code is placed in that company automatically; there's nothing to add to the command. Ways to get a company's command:

• Customer Portal → Companies → Install on the company's row. The RMM Agent tab has the agent commands and the 360 Probe tab the probe commands, both with that company's codes.
• MantisRMM → Devices → + Add device → pick the company under Enroll into. The command switches to that company's code.
• The Group Policy script has its own Enroll into company picker (see Mass Deployment).
• Create your own code with a Company set.

Devices installed with a code that has no company can be assigned later in MantisRMM. A company can't be added to an enrollment code inside the command: the code itself carries the company.

Mantis360 sites: in Mantis360, Enroll a new endpoint agent lets you pick a site. That command adds the site's Mantis360 install token as ENROLL_360, which puts the host in that site.

Mass Deployment

The install commands are non-interactive and safe to run repeatedly, so any tool that can run a script as SYSTEM or root can deploy the agent.

Group Policy (domain-joined Windows)

The Portal has a ready-made computer startup script: Agents & Probes → Mass deployment with Group Policy (GPO). It installs the agent at first boot and skips any machine that already has the MantisAgent service. It looks like this (copy it from the Portal to get your GPO code filled in):

1. Save the script as Install-MantisAgent.ps1 on a share every domain computer can read (for example \\<dc>\NETLOGON).
2. Open Group Policy Management, create a GPO linked to the OU (or domain) that holds the target computers, and click Edit.
3. Go to Computer Configuration ▸ Policies ▸ Windows Settings ▸ Scripts (Startup/Shutdown) ▸ Startup ▸ PowerShell Scripts and add Install-MantisAgent.ps1.
4. Startup scripts run as SYSTEM and bypass the PowerShell execution policy, so nothing else needs configuring.
5. Run gpupdate /force and reboot a test machine (or wait for the next reboot). It then appears under Deployed devices.

If enrollment fails (for example, the code was rotated), the script stops quietly and tries again at the next boot. Because it skips machines that already have the service, it doesn't upgrade or repair existing installs; use the one-line command for that.

Intune, another RMM, or your own scripts

Deploy the same one-line command you'd run by hand. The installer reads the code from the TENANT environment variable, never prompts when one is set, and exits non-zero on failure so your tool can report it.

• Windows: run the PowerShell one-liner as SYSTEM. In Intune, add it as a PowerShell platform script with Run this script using the logged on credentials set to No and Run script in 64 bit PowerShell Host set to Yes, so the agent lands in C:\Program Files rather than the 32-bit Program Files folder.
• macOS and Linux: run the bash one-liner as root over SSH, Ansible, Jamf or your RMM.
• Running the agent binary yourself: follow the GPO script above. Put the binary in its own folder (C:\Program Files\MantisOps), then run --enroll and --install-service as two separate commands. If both flags are given in one command, the service is installed but the enrollment is skipped. Don't run the agent from a shared folder such as Downloads: uninstalling removes the files in the agent's folder.

macOS with an MDM

1. Run a script as root before the package installs, to stage your enrollment code:
   mkdir -p /etc/mantisops printf '%s' '<YOUR-ENROLLMENT-CODE>' > /etc/mantisops/enroll.token
2. Deploy the signed package from https://api.rmm.mantisops.net/agent/unified/pkg/darwin. Its post-install step finds the staged code, enrolls the Mac, deletes the code file and starts the daemon.
3. Deploy the PPPC configuration profile so remote desktop works without clicking through System Settings.

If the enrollment fails, the code file is kept so that installing the package again retries it.

Updates

The agent keeps itself up to date. A couple of minutes after it starts, and then every hour, it checks which version MantisOps has published for your account and installs it if it's newer. Nothing needs to be scheduled on your side. Admins can also push an update to a single device from the Portal: Agents & Probes → Deployed devices → Update.

Every release is signed. Before installing, the agent checks the release's manifest against MantisOps signing keys built into the agent, and checks the downloaded file against that manifest. Anything unsigned, or that doesn't match, is refused. On macOS the update installs the new signed package, which keeps the macOS privacy permissions in place.

Reinstalling & Upgrading in Place

Re-running the install command on a machine that already has the agent is safe. It's an in-place upgrade: the running agent is stopped, the newest version is put in place, the device is enrolled again and the service is started.

• Same device record. A reinstall on the same machine with an enrollment code keeps its device record: same name, company, groups and history. The agent proves it's the same device with the key it already holds.
• Nothing half-done. On Windows and Linux, if the new enrollment fails, the existing agent is started again on its previous enrollment and the installer reports the error.
• After an OS reinstall or a restore on the same hardware, install with an enrollment code. The device gets its old record back and a new key; anything still using the old key is refused from then on.
• Replaced hardware with the same name: the new machine gets a new device record rather than taking over the old one. Remove the old device once you've confirmed the replacement.

Reinstalling with a legacy tenant-ID command onto a device that already holds a key doesn't work the same way. See Device Security.

Uninstalling

From the console (recommended)

• Customer Portal → Agents & Probes → Deployed devices → Uninstall (account admins and owners). If the device is offline, the uninstall runs the next time it connects.
• MantisRMM → Devices → open the device → the Settings tab → Uninstall (shown while the agent is online).

Uninstalling from the console removes the software from the machine, removes the device from your device list, and clears the device's key, so a later reinstall starts fresh. Delete / Delete Record only removes the device from the list; it doesn't remove the software from the machine.

On the machine

Use Settings → Apps → Installed apps (or Programs and Features), find MantisOps Unified Agent and choose Uninstall. Or, from an elevated PowerShell:

What's removed: the service or launch daemon, every configuration file and secret (including the device key) in C:\ProgramData\MantisOps or /etc/mantisops, the installed program and its logs (on macOS, the whole MantisAgent.app), files left by the older standalone MantisRMM agent, and on Windows the Apps entry and the scheduled tasks the agent created. On Windows, files that are still in use are removed at the next restart, and the ProgramData folders are left empty and locked to administrators. A network probe installed on the same machine is not touched.

An uninstall on the machine doesn't notify the console, so the device stays in your list as offline. Delete it there, or reinstall with an enrollment code, which reuses the record.

Device Security

Every device gets its own secret key automatically: a new device receives it when it enrolls, and an existing device after it has been connected steadily for about 10 minutes. The key is stored in identity.json in the agent's configuration folder, readable only by SYSTEM/administrators (Windows) or root. From then on, every connection for that device must present the key, so your tenant ID or an enrollment code alone can't be used to pose as the device.

You can see each device's state in MantisRMM (open the device → the Settings tab → Device Identity) and in the Portal (Agents & Probes → Deployed devices, Identity column):

Fixing "Key mismatch"

A mismatch happens when an install no longer has the device's key: the machine was reinstalled or restored from a backup or image, or the agent was reinstalled with a legacy tenant-ID command. It can also mean something else is trying to connect as this device.

• If you know the device was reinstalled or restored: either reinstall it with an enrollment-code command (the device is matched to its record and given a new key), or click Reset key. Reset key is in MantisRMM (agent → Settings → Device Identity, for account admins) and in the Portal (Deployed devices, for admins and owners). After a reset, an online, up-to-date agent is issued a new key automatically once it has been connected for about 10 minutes; otherwise it gets one when it next connects. Until then the device is protected only by your tenant ID, like a device that isn't secured yet.
• If you don't know why it happened: check the machine before resetting anything.

Cloned and imaged machines

Don't build a golden image with the agent already installed: every copy would carry the same device identity. Install the agent after each machine is deployed (Group Policy, Intune or your RMM make this easy). If copies already exist, uninstall the agent on each copy (--uninstall) and install it again with an enrollment code while the original machine is online. A machine that enrolls under the name of a device that's connected right now gets its own new device record and key instead of taking over the original's.

Legacy Tenant-ID Installs

Before enrollment codes, install commands and scripts used your account's tenant ID (sometimes with a ~company suffix, and an --enroll-360 / ENROLL_360 token for Mantis360). Since October 1, 2026, those commands can no longer install new devices: the install stops with New installs need an enrollment code. The Portal and MantisRMM still list them under Legacy (tenant ID) for reference.

Tenant-ID installs were retired because a tenant ID isn't a secret. Only installs that would create a new device are refused; devices that are already installed are not affected and keep working. A network probe that registered with the tenant ID before the change and hasn't been approved still waits for approval (see the probe guide).

To switch:

• Replace the tenant ID in your GPO, Intune, RMM and imaging scripts with an enrollment code. For Group Policy, copy the new script from the Portal; it uses the GPO code.
• Replace <tenant-id>~<company> values with that company's code.
• Drop --enroll-360 / ENROLL_360 unless you're assigning hosts to a Mantis360 site. The enrollment code enrolls Mantis360 too.
• Installed devices don't need any change.

One difference to know about now: if a device already holds its own key and is reinstalled from scratch with a tenant-ID command, the install completes but the agent can't connect, and the device shows Key mismatch. Reinstall it with an enrollment code, or use Reset key.

Troubleshooting

The installer prints a clear error and the log path when something fails. The messages below are the ones you'll see.

Logs and service checks

The agent writes mantis-agent.log (startup, enrollment, updates) plus one log per product module (mantis-rmm.log, mantis-360.log) in the folder the agent runs from. Logs rotate at 10 MB.

For an online device you can also fetch the log from MantisRMM: open the device → the Settings tab → Download Agent Log. Enable Debug Log there adds more detail.

Command-Line Reference

The install scripts use these options for you; you only need them for custom deployments. Run them elevated (Windows) or as root.