Skip to main content

​
Platform compatibility

Deployment type: AutomaticOnce the integration is connected and the control is enabled, the agent is pushed to every targeted device via MDM. No manual installation and no user interaction are required.

​
Prerequisites

  • Primo MDM
  • A SentinelOne license, purchased through Primo or already in place
Need a SentinelOne instance? Contact us or write to support@getprimo.com.

​
Which setup applies to you

Three things change depending on where your SentinelOne instance comes from. Check which case you’re in before you start.

​
Connect your SentinelOne instance

The EDR - SentinelOne cards stay greyed out in the control catalog until the integration is connected. Start here.
1

Open the integration

In Primo, go to Settings > Integrations, then open SentinelOne in the EDR/MDR section.
2

Fill out the form

The step is titled Create a service user for Primo and provide the API token.
If the form displays the notice “you probably don’t need to fill site url nor service user token inputs, site ID is enough”, your instance is hosted on Primo’s SentinelOne tenant.Fill in the Site ID only:
  1. In SentinelOne, open Policy & Settings > Sites.
  2. Click the site you want to connect and copy the Site ID.
3

Click Enable

Two things confirm the connection:
  • SentinelOne appears in the Primo main menu, next to Fleet, as a direct link to your console.
  • The EDR - SentinelOne cards become selectable in the control catalog.

​
Deploy SentinelOne to your fleet

Deployment runs through your MDM controls.
1

Create the control

Go to MDM > Controls > Add new control and choose the platform.
2

Enable the matching card

Each card covers one platform and one architecture. Enable the one that matches your devices:
3

Set the targeting

Choose which devices the control applies to: all devices, specific device groups, or a custom target.You don’t need architecture-specific device groups. Each card only applies to the devices matching its platform and architecture, so mixed groups are handled correctly.
4

Confirm

The agent is installed automatically on every device covered by the control.

​
macOS system profile

The macOS agent needs a system profile granting it the system extension, Full Disk Access, notifications, and the network filter. Without it, the agent installs but stays partly inactive, and macOS prompts the user for approvals.
Nothing to do. The control pushes the profile along with the agent — you don’t have to build or upload a .mobileconfig.

​
Exclude the Fleet agent from SentinelOne

SentinelOne can block, throttle, or quarantine the Fleet agent. When that happens, devices show up as Missing agent or offline in Primo while they are actually in use — see Resolve enrollment issues.
On instances provided by Primo, these exclusions are already set on the SentinelOne policy. This section applies to your own instance (BYO), where you have to add them for macOS and Windows.
Add the paths below as Path exclusions in your SentinelOne console, scoped to the site connected to Primo, with Include subfolders enabled and the mode set to Interoperability. Linux agents use the same /opt/orbit paths as macOS.
Excluding the parent folder — /opt/orbit/ on macOS and Linux, C:\Program Files\Orbit\ on Windows — covers the binaries through agent upgrades, which rewrite the executables underneath.

​
Modify or remove the control

Disable the card from the control settings. Disabling stops enforcement on new devices but does not uninstall the agent from devices where it is already running.

​
Uninstall the agent from a device

Anti-tampering blocks any removal that isn’t authorized from the console: an end user who runs the uninstaller only triggers an uninstall request for you to approve or deny.
  1. Get the passphrase: in the SentinelOne console, go to Agent management > Endpoints, open the endpoint, then click Actions > Agent Actions > Show Passphrase.
  2. Uninstall from the console (Actions > Uninstall), or from the CLI with local admin rights:
No passphrase? An agent that never connected to a console takes an empty string. For a leftover agent from a decommissioned console, retrieve its passphrase from that console if you still have access. Otherwise, on macOS, boot the device into Recovery Mode and follow SentinelOne’s uninstall procedure from there. On Windows and Linux, go through SentinelOne Support rather than a script found on a forum.

​
Renew the Service User Token

SentinelOne service user tokens expire — the lifetime is set when the service user is created. Once the token expires, the integration stops syncing and device protection statuses go stale in Primo. Create a new service user in Policy & Settings > Service Users, then paste the new token in Settings > Integrations > SentinelOne. Note the expiry date somewhere you’ll see it before it lands.

​
Migrate to another SentinelOne console

To move your endpoints from one SentinelOne console to another, update the install scripts first, then migrate the endpoints. An endpoint can only migrate if it is online, has no unresolved threats, and is not running a full disk scan. Offline endpoints stay pending until they check in again. You need Global or Account-level permissions on the source console — on a console provided by a partner, that level may sit with the partner rather than with you. Prepare the destination site first: SentinelOne policies can’t be exported, so they have to be rebuilt there. For a full tenant migration, SentinelOne Support can carry the configuration over for you.
1

Update the install scripts in Fleet

  1. Open your Fleet instance at https://<your-tenant>.mdm.getprimo.com.
  2. Go to the Software tab and search for Sentinel (SentinelOne, Sentinel Agent, and similar).
  3. For each package: click Edit, open Show advanced options, and replace the old site token with the new one in the install script.
Devices that install the agent from now on will register against the new console.
2

Migrate the existing endpoints

In your SentinelOne console, select the endpoints to migrate, then go to Actions > Endpoint actions > Migrate endpoints. Enter the new site token and confirm.
The token must belong to a site on the destination console. A token taken from the source console fails silently — no error, and the endpoints stay where they are.
Migration is not destructive: an agent that can’t reach the new console within a few minutes stays registered on the original one.
3

Confirm, then clean up the source console

Track progress with the Console Migration Status filter under More filters — N/A, Pending, or Migrated. The activity log of the source console also records the destination URL for each agent that moved.Migrated endpoints stay listed in the source console, greyed out. They don’t leave on their own: decommission them once the destination console shows them active, or shorten the decommission window so offline agents are swept out automatically. Until you do, the same devices are counted on both consoles — worth settling with your provider before you start.
Before you lose access to the source console, export the passphrases of the endpoints that did not migrate — those are the ones you may have to handle by hand. Migrated agents get a new UUID and a new passphrase from the destination console, so the old ones are useless. Running the first batch before exporting keeps the list short.
4

Update the Primo integration

Go back to Settings > Integrations > SentinelOne and update the Site ID, URL, and Service User Token to match the new console.

​
Unsupported platforms

If your platform is not listed above, you can still install SentinelOne manually: download the installer from the SentinelOne console and deploy it with Fleet as a custom app.