Windows - Configuration - Start SentinelOne Agent Service

What the SentinelOne service restart Worklet does

This Automox Worklet™ restores SentinelOne EDR coverage on Windows endpoints by restarting the SentinelAgent service whenever it is stopped. The Worklet first confirms the SentinelOne Agent application is actually installed by enumerating both the 64-bit and 32-bit Windows uninstall registry hives (HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall) for a DisplayName matching Sentinel*.

When the application is present, the evaluation script reads the SentinelAgent service with Get-Service Sentinel* and checks the Status property. Any state other than Running, including Stopped, StartPending, StopPending, and Paused, flags the endpoint for remediation. The remediation script issues Start-Service SentinelAgent and falls back to sc.exe start SentinelAgent if the PowerShell cmdlet returns an access denied error. The Worklet exits 0 on success and a non-zero code with stderr context when the service cannot be brought to Running.

The evaluation phase is idempotent. Endpoints with SentinelAgent Status=Running pass the Get-Service check and exit 0 without calling Start-Service, so the policy can sit on an hourly cadence against every Windows endpoint expected to carry the EDR agent without generating false remediation activity in Automox logs.

Why keep the SentinelOne agent service running

SentinelOne is autonomous on the endpoint, but the SentinelAgent service can stop for reasons outside the agent's control: a Windows feature update that resets services, a third-party driver conflict, an aggressive power policy on a laptop returning from sleep, or a non-persistent VDI image that resumes from a stale snapshot. When SentinelAgent is stopped, the endpoint loses real-time behavioral analysis, static AI scanning, network containment, and Storyline event correlation. The host still appears online in your asset inventory and still answers to your monitoring tools, but it returns zero EDR telemetry to the management console.

The gap is hardest to see in the SentinelOne console itself, where a stopped-service endpoint reads as Disconnected and looks indistinguishable from a laptop that is simply offline overnight. A SOC analyst chasing a phishing alert has no way to tell whether the endpoint is asleep, off-network, or sitting at someone's desk with the agent stopped and no Storyline data being recorded.

SentinelAgent stops for predictable reasons on Windows: a feature update servicing pass resets the SCM record, a third-party driver conflict trips the agent's self-protection watchdog, an aggressive power policy on a laptop returning from S3 sleep leaves the service in StopPending. Scheduling this Worklet on an hourly or two-hourly cadence catches a stopped SentinelAgent on the next agent check-in, calls Start-Service to bring it back to Running, and confirms the transition before the gap turns into a missing 24 hours in an incident response timeline. The activity log captures each restart with the recorded service state, which is the artifact a SOC analyst can reference when reconstructing the Storyline coverage window.

How the SentinelOne service restart works

1. Evaluation phase: The Worklet enumerates the 64-bit and 32-bit uninstall registry hives with Get-ChildItem and filters DisplayName for Sentinel* using Where-Object. If no SentinelOne entry is found, the script exits 0 and the endpoint is not flagged (this prevents false positives on hosts running a different EDR). When the application is present, the script runs Get-Service Sentinel* and inspects the Status property. A Status of Running exits 0; any other state, or a missing service object, sets the exit code to flag the endpoint for remediation.

2. Remediation phase: The remediation script issues Start-Service SentinelAgent under the Automox agent's SYSTEM context. If Start-Service returns an access-denied or service-not-found exception, the script falls back to sc.exe start SentinelAgent and re-queries Get-Service to confirm the transition to Running. A successful start exits 0; a service that refuses to start (tamper protection conflict, missing driver dependency, corrupted installation) exits non-zero with the captured exception in stderr so the failure surfaces in the Automox activity log instead of going silent.

SentinelOne service restart requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, or 2022 endpoint with the SentinelOne Agent already installed

• Automox agent running under SYSTEM (the default), which holds the SERVICE_START rights the Service Control Manager requires for SentinelAgent

• PowerShell 3.0 or later for Get-Service, Get-ChildItem, and Start-Service; sc.exe is used as the fallback path

• SentinelOne tamper protection configured to allow local service start (Worklets running as SYSTEM are normally exempt, but check the site policy in the SentinelOne console if remediation exits non-zero on more than one or two endpoints)

• Schedule the policy on a recurring cadence (hourly or every two hours is typical for EDR uptime enforcement) so a service that stops between scans is restored within the next evaluation window

Expected SentinelOne EDR state after remediation

The SentinelAgent service transitions from Stopped (or StopPending, StartPending) to Running on the next evaluation. Get-Service Sentinel* returns a Status of Running and a StartType of Automatic. The agent reconnects to the SentinelOne management console within two to five minutes, the host status flips from Disconnected to Active, and the last-contact timestamp begins updating again. Behavioral AI, static AI, network containment, and Storyline correlation resume on the endpoint, and any events queued locally while the service was stopped are uploaded to the console.

Validate on a pilot endpoint by running Get-Service SentinelAgent and confirming Status is Running and StartType is Automatic. Cross-check the SentinelOne console for the host's last-contact timestamp and Storyline event stream. Subsequent Automox policy runs report the endpoint as compliant without applying remediation again, because the evaluation phase finds the service already running and exits 0.

This Worklet restarts the service but does not change its StartType or harden it against future failures. If the same endpoint keeps appearing in remediation activity, treat that as a signal to investigate the root cause: a driver conflict, a tamper-protection policy fight, a corrupted agent install (reinstallation via the SentinelOne console is usually the right next step), or a recurring Windows update that disables third-party security services. Pair this Worklet with a SentinelOne agent health check policy so persistent failures roll up alongside endpoints where the service is simply stopped.