Windows - Security - Install SentinelOne Agent

What the SentinelOne Windows deployer does

This Automox Worklet™ deploys the SentinelOne endpoint detection and response agent to Windows endpoints. SentinelOne provides autonomous endpoint protection with real-time prevention, detection, and response capabilities backed by behavioral analysis. The Worklet treats the agent as a desired-state baseline: if the agent is already installed, the endpoint is marked compliant and the installer is skipped.

Before scheduling the policy, you upload your organization-specific SentinelOne MSI installers to the Worklet payload. Both architectures must be staged: the 32-bit MSI and the 64-bit MSI, both downloaded from the Packages section of your SentinelOne management console (filenames look like SentinelInstaller_windows_32bit_v<version>.msi and SentinelInstaller_windows_64bit_v<version>.msi). The site token, also pulled from the Packages section, registers each agent with the correct site when the installer runs.

The evaluation script queries the Windows registry uninstall keys at HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall on every endpoint, and on 64-bit hosts it also enumerates the same path through the 64-bit registry view, looking for any DisplayName matching "Sentinel Agent". The remediation script picks the MSI that matches the endpoint's architecture, then runs msiexec with the SITE_TOKEN, /NORESTART, and /QUIET arguments to install the agent without user interaction.

Why deploy SentinelOne EDR through Automox

Gaps in EDR coverage create risk for the rest of the fleet. A Windows endpoint without an active SentinelOne agent has no behavioral telemetry, no rollback capability, and no real-time response when an attacker drops a payload. Manual MSI deployment across hundreds or thousands of Windows hosts is operationally expensive and often incomplete. Onboarding scripts miss endpoints that were off the network on imaging day. GPO-driven installs depend on domain join. SCCM rollouts skip developer laptops and field hardware that never check in.

Deploy this Worklet through the Windows workstation and server device groups covered by your SentinelOne site token. The registry-driven evaluation runs on every host under Automox management, msiexec lands the matching architecture installer only where the Sentinel Agent DisplayName is absent, and each result reports back to the Activity Log. EDR coverage moves from incomplete to complete in a single policy window.

How the SentinelOne MSI deployment works

1. Evaluation phase: On 64-bit hosts the Worklet opens the 64-bit registry view with [Microsoft.Win32.RegistryKey]::OpenBaseKey and enumerates Software\Microsoft\Windows\CurrentVersion\Uninstall. It also iterates HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall on every host using Get-ChildItem, Get-ItemProperty, and Where-Object. It matches DisplayName values against "Sentinel Agent". When the agent is present, the endpoint is marked compliant and remediation is skipped. When it is absent, the endpoint exits 1 and the remediation script runs on the next policy window.

2. Remediation phase: The Worklet detects whether the endpoint is 32-bit or 64-bit using [System.Environment]::Is64BitOperatingSystem, then selects the matching MSI from the Worklet payload using the $32bitFilename or $64bitFilename variable. It calls Start-Process against msiexec with the argument list SITE_TOKEN=<your-token> /NORESTART /QUIET and captures the exit code. Exit codes 0 and 3010 are treated as success (3010 indicates a pending reboot), exit code 1618 fails the run with a restart-required message, and any other non-zero code fails the run. Each outcome is written to the Automox activity output so non-compliant results surface in the console rather than failing silently.

SentinelOne deployment requirements

• Windows 7 or later (32-bit or 64-bit), as documented in the script header

• Active SentinelOne tenant with available endpoint licenses

• Both the 32-bit and 64-bit SentinelOne MSI installers downloaded from the Packages section of your SentinelOne console and uploaded to the Worklet payload

• Site token from the Packages section of your SentinelOne management console

• Configure the $32bitFilename, $64bitFilename, and $SITE_TOKEN variables at the top of the remediation script to match the uploaded MSI names and your site token

• Administrative privileges on the target endpoint (the Automox agent runs as SYSTEM by default, which satisfies this)

• Network reachability from the endpoint to your SentinelOne management console hostname for agent registration

• Remove any conflicting endpoint protection agent in advance (CrowdStrike, Carbon Black, and similar products should be uninstalled first to avoid driver collisions)

Expected state after SentinelOne deployment

After a successful policy run, the SentinelOne agent appears in Add or Remove Programs with a DisplayName containing "Sentinel Agent" and a populated DisplayVersion. Registry uninstall keys are written under HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall (the same path the evaluation script queries on subsequent runs). The endpoint registers with your SentinelOne console using the configured site token and begins reporting telemetry.

Validate the install by checking Add or Remove Programs for the Sentinel Agent entry, or by re-running the Worklet and confirming the evaluation now reports "Software is already installed" and exits 0. In the SentinelOne management console, the endpoint should appear under Sentinels with the hostname and the configured site. Subsequent Worklet runs evaluate to compliant because the registry uninstall key is present, so the policy is safe to leave on a recurring schedule as a coverage-enforcement baseline. When the msiexec exit code is 3010, plan a reboot during your next maintenance window so the agent's kernel driver finishes loading and real-time protection becomes fully active.