SentinelOne Multi-Tenant Deployment for MSPs: The Intune Guide

Deploying an EDR agent to one machine is straightforward. For SentinelOne specifically, the install command is short, and the packaging process is well documented. However, the moment you need to deploy it consistently across dozens of client tenants, and keep every agent on the right version, the right site, and the right policy months later, your work as an MSP can get significantly harder. 

The difficulty lies in the multi-tenant plumbing, which typically involves: mapping each client to its own site and token, pushing the agent through the appropriate delivery mechanism (e.g., Microsoft Intune, NinjaOne, ConnectWise Automate, etc.), and confirming coverage without checking each console by hand. 

This guide walks through a repeatable multi-tenant rollout using Microsoft Intune and RMM platforms, then covers the part most rollouts underestimate: keeping deployments consistent as client counts grow.

What Makes Multi-Tenant Deployment Different

Before you package the installer or write deployment scripts, organize your SentinelOne site structure first, because it determines everything downstream.

SentinelOne organizes tenants in a hierarchy of accounts, sites, and groups. For MSP use, the usual practice is one site per client, with groups inside a site for policy segmentation, such as servers versus workstations. Each site issues its own site token, a unique string that tells an installing agent which site to register with. 

Site tokens register endpoints to the correct client site. If more granular placement is needed, group assignment can be handled inside the site through policy structure, manual or automated grouping, or install-time group targeting where supported.

That token is the pivot point of a multi-tenant rollout. An agent installed with Client A’s token lands on Client A’s site and inherits Client A’s policy. Install it with the wrong token, and the endpoint shows up in the wrong client’s environment, which is both a coverage problem and a client-data-separation problem.

This is why a single reused installer package does not map cleanly across clients. The binary is identical, but the token that binds each agent to the correct tenant is not. Every deployment method below solves the same problem: getting the correct per-client token onto the correct set of machines, repeatably, without hand-editing each install.

Prerequisites Before You Deploy

Confirm the following before you begin deployment:

Prerequisites	Description
Console Access and Role	Ensure you have permission to retrieve site tokens and manage the client sites you are deploying to.
Site and Group Structure	Create one site per client tenant, with groups mapped to how you segment policies.
Site Tokens Pulled	Retrieve the token for each site you are deploying to and store it where your deployment tool can reference it securely.
Installer Versions Pinned	Decide which agent version you are standardizing on. Mixing versions across clients at install time creates version drift on day one.
OS Coverage Mapped	SentinelOne EDR supports Windows, macOS, and Linux. Confirm which client devices fall into each, and that you have the matching installer for each platform.
Delivery Method Per Client	Decide whether each client is reached through Intune, an RMM, or both, based on what already manages those endpoints.

Deploying Via Microsoft Intune

Intune suits clients whose devices are already enrolled in a Microsoft 365 tenant you manage. The Windows agent deploys as a Win32 app.

Package the Installer

Download the current Windows agent from the console, then wrap it with the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) to produce a .intunewin file. Package the MSI where possible, because it gives you a clean silent install command, a matching uninstall command, and a predictable place to pass the site token.

Configure Install and Uninstall Commands With the Site Token

Set the install command to pass the site token as an MSI property. For example:

msiexec /i SentinelInstaller.msi /qn SITE_TOKEN=<client-site-token>

Set a matching uninstall command, and account for anti-tamper if the site requires an uninstall passphrase. Then be deliberate about the detection rule, because this is where multi-tenant Intune deployments most often go wrong. MSI product codes change between agent versions, so a product-code rule is only accurate on a fleet pinned to the exact build you packaged. As soon as clients sit on different versions, or agents update themselves from the SentinelOne console, Intune reads protected endpoints as not installed and pushes the package again. A hard-coded file path has the same weakness, since the agent installs into a version-stamped folder. For any fleet that will span versions, detect on something that survives an upgrade: a custom detection script that checks for the SentinelOne service or registry entry and exits successfully when the installed version meets your minimum, or a file rule using a version comparison rather than simple existence at a fixed path. Confirm exact property names, install paths, registry keys, and the installer filename against the deployment guide for the agent version you pinned.

Assign to Per-Tenant Device Groups

Create an Entra ID device group for each client and assign the packaged app to that group. Because the token is embedded in the install command, each client site needs its own app instance or its own token value. Assigned groups give you tighter control over which devices receive the agent, while dynamic groups reduce manual upkeep as devices come and go. This is the operational trade-off of Intune at multi-tenant scale: the packaging is clean, but you maintain a separate assignment, and effectively a separate package, per client tenant.

Handle macOS Endpoints

macOS deployment uses a separate package and carries extra approval steps. The agent typically requires Full Disk Access, Network Extension approval, and Network Filter or Content Filter approval, all of which can be delivered as configuration profiles through Intune or another MDM so the agent installs without end-user prompts. 

Depending on the macOS and agent versions, additional profiles, such as Notifications or Service Management, may also be required. Deliver the registration token through the install script, token file, or configuration profile, scoping it per client the same way you scope the Windows token.

Deploying Via RMM: The Multi-Tenant Workhorse

For most MSPs, the RMM is the more natural fit for multi-tenant deployment, because it already models clients as separate entities and already runs scripts against them.

Why RMM Fits Multi-Tenant Better

An RMM lets you store each client’s site token as a client-level variable and run one deployment script everywhere. The script reads the token for whichever client it runs against, so you maintain a single piece of deployment logic instead of one packaged app per tenant. RMMs such as NinjaOne, ConnectWise Automate, Atera, and Syncro support this pattern through site or organization variables and scripted software deployment. 

Because the RMM already groups devices by client, you also get a ready-made map of which endpoints belong to which site, which makes both the initial push and later re-runs against missed machines straightforward.

Push the Installer With the Site Token

Deploy the MSI through the RMM’s software deployment or a script, passing the client’s token as the install parameter:

msiexec /i SentinelInstaller.msi /qn SITE_TOKEN=%SiteToken%

Here %SiteToken% resolves to the per-client variable the RMM injects, using your RMM’s variable syntax. The same script then serves every client, and the RMM handles targeting. For macOS fleets, run the equivalent install script with the client’s registration token pulled from the same variable.

Map Policies and Handle Upgrades and Reinstalls

Once an agent registers to the correct site and, where applicable, the correct group, it inherits the policies assigned there. That means per-client policy mapping depends primarily on correct site and group placement. Version upgrades are generally managed from the SentinelOne console through the agent update policy, which keeps upgrade logic out of the RMM. 

Reinstalls and migrations require additional planning because anti-tamper controls can prevent the agent from being removed or replaced. If anti-tamper is enabled, cleanup scripts may require an uninstall passphrase. SentinelOne generates a unique uninstall passphrase per endpoint by default rather than one per client, so the secret you have to retrieve is tied to the specific machine you are working on. Store passphrases securely alongside the corresponding site token, and pull them programmatically where your tooling supports it, so authorized automation can run without a manual console lookup for every device.

Confirm Agent Check-In and Site Placement

After the script runs, confirm each agent checks in and lands on the correct site. Watch for agents appearing on the wrong site, which signals a token mapped to the wrong client variable, and correct the variable before the mistake spreads across that client’s fleet.

Verifying Deployment Across Tenants

Deployment is not done when the script reports success. Confirm the result across every tenant.

• Correct Site Registration: Spot-check that agents from each client appear on that client’s site and no other. Misrouted agents are a common multi-tenant error and easy to miss.
• Coverage Against Known Device Counts: Compare the agent count in each site to the device inventory your RMM reports for that client. Any difference between the two gives you a working list of endpoints that still need attention.
• Offline and Straggler Devices: Identify endpoints that never checked in, went offline shortly after install, or were powered down during the rollout, and re-target them.
• Token and Passphrase Hygiene: Confirm tokens were not exposed in logs or scripts readable by clients, and that you can retrieve the uninstall passphrase for any given endpoint, not just the site token for its tenant.

Run this verification per client, not in aggregate. A high aggregate coverage rate can hide weak coverage in a single client environment. Where your RMM supports it, schedule a recurring check that compares live agent counts to device inventory per client, so new gaps can be detected without a manual audit each time.

The Real Challenge: Drift and Consistency

Deployment is only the starting point. The harder work is keeping versions, policies, coverage, and secrets consistent as more clients are added.

As more clients are added, four kinds of drift can accumulate:

Version Drift	Version drift appears as clients fall onto different agent versions through staggered onboarding and inconsistent update policies.
Policy Drift	Policy drift appears as per-site settings get edited during incidents and never reconciled against your baseline.
Onboarding Gaps	Onboarding gaps appear as new devices join a client without inheriting the correct site and policy, leaving endpoints unprotected.
Token Sprawl	Token sprawl appears as the count of secrets you track securely climbs: one site token for every tenant you add, plus an uninstall passphrase for every endpoint, since passphrases are generated per device by default.

Each type of drift is manageable for a handful of clients. But across dozens of tenants, scripts alone can’t solve the ongoing work of keeping versions, policies, coverage, and secrets aligned.

A Lower-Overhead Path

If that ongoing orchestration is straining your team, it is worth evaluating a platform that manages it for you. Guardz provides SentinelOne Singularity through an MSP-focused operating model. 

The EDR itself is unchanged: the same SentinelOne agent, the same detection engine, the same console when you want it. What changes is the commercial and operational wrapper around it, which is where most of the overhead described above actually lives.

• No SentinelOne seat minimums. You add endpoints as clients grow instead of committing to a seat floor, so a 15-seat client is as workable as a 400-seat one and you are not carrying unused licenses to hold a commitment.
• One contract instead of two. You are not negotiating and maintaining a separate SentinelOne MSSP agreement, or a separate console licensing line, alongside the rest of your stack. One agreement, one invoice, one renewal to track.
• 24/7 MDR triage included. The Guardz MDR team triages the resulting EDR alerts around the clock as part of the platform rather than as a separately priced MDR tier, so the alert volume a fleet-wide rollout generates does not land unfiltered in your ticket queue.
• Full SentinelOne console access retained. Site structure, token handling, policy assignment, coverage visibility, and lifecycle management run inside Guardz, with global configurations set once and applied across clients, and the native console still there when an investigation needs it.

The practical difference is what stops being yours to maintain. The multi-tenant plumbing this guide walks through, one site per client, one token per site, one passphrase per endpoint, one update policy per environment, becomes configuration rather than ongoing operational work.