Windows - Configuration - Start Rapid7 Insight Agent Service

What the Rapid7 Insight Agent service starter does

This Automox Worklet™ verifies that the Rapid7 Insight Agent service is running on Windows endpoints and starts it when it is stopped. The Worklet first checks both the 64-bit and 32-bit uninstall registry hives to confirm Rapid7 Insight Agent is actually installed. On 64-bit systems, it opens the Registry64 view of HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall using the .NET RegistryKey API and checks the DisplayName of each subkey. On all systems, it also walks HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall using Get-ChildItem and Get-ItemProperty. Endpoints without the agent installed exit cleanly and report as not applicable, so the policy is safe to scope broadly across mixed fleets.

When the agent is installed, the evaluation script calls Get-Service -DisplayName "Rapid7 Insight Agent" to read the current service state. If the service status is Running, the endpoint exits compliant. If the service is stopped or in any other state, the endpoint is flagged for remediation. The remediation script then calls Start-Service -Name "Rapid7 Insight Agent" inside a try/catch block. A successful start writes a confirmation message to standard output; a failure writes an error and exits non-zero so the Automox activity log captures the triage signal.

The script does not reinstall the agent, set the service startup type, change Rapid7 InsightVM scan configuration, or modify the agent's check-in interval. Its job is narrow: bring the Rapid7 Insight Agent service back to a Running state on every endpoint that already has Rapid7 deployed so the security telemetry stream stays uninterrupted.

Why keep the Rapid7 Insight Agent service running

The Rapid7 Insight Agent service is the on-endpoint runtime that feeds InsightVM vulnerability scans, InsightIDR behavioral telemetry, and InsightOps asset data back to the Rapid7 Insight platform. When the service stops on a Windows endpoint, the host disappears from live coverage. Scan results go stale, last-seen timestamps drift, and the endpoint may be reported as patched against CVEs that it has never actually been re-scanned for.

Common stop triggers on Windows include service dependency failures after a cumulative update, manual stops by a local admin, and snapshot or template provisioning that brings the OS back online without restarting non-essential services. Compliance teams running CIS, NIST 800-53 SI-4 continuous monitoring, PCI-DSS 11.5, or SOC 2 CC7.2 controls treat a stopped security agent as an uncovered host, so catching and correcting the condition automatically keeps audit evidence intact.

How Rapid7 Insight Agent service enforcement works

1. Evaluation phase: The evaluation script checks both the 64-bit registry hive (via the .NET RegistryKey API with a Registry64 view) and the 32-bit hive (via Get-ChildItem and Get-ItemProperty) for a DisplayName matching "Rapid7 Insight Agent". If no install record is found, the endpoint exits compliant and is marked not applicable. If the agent is installed, the script calls Get-Service -DisplayName "Rapid7 Insight Agent" and checks the Status property. Any value other than Running flags the endpoint as non-compliant and schedules remediation.

2. Remediation phase: The remediation script calls Start-Service -Name "Rapid7 Insight Agent" inside a try/catch block to bring the service back to Running. A successful start writes a confirmation message to standard output and exits zero. If Start-Service throws an exception, the script writes a failure message and exits non-zero so the failure surfaces in the Automox activity log for triage.

Rapid7 Insight Agent service requirements

• Windows 10, Windows 11, or Windows Server 2012 R2 / 2016 / 2019 / 2022 endpoint with the Automox agent installed

• Rapid7 Insight Agent already deployed; the Worklet does not install the agent, only starts its service

• PowerShell 5.1 or later in the SYSTEM context (the default Automox agent context already meets this)

• Local SYSTEM rights to query and start Windows services

• Network reachability to *.insight.rapid7.com on TCP 443 so the agent can re-establish its session after the service returns to Running

Expected Rapid7 Insight Agent state after enforcement

After remediation, Get-Service -DisplayName "Rapid7 Insight Agent" reports Status: Running. The agent completes its handshake with the Rapid7 Insight platform within a few minutes, the endpoint's last-seen timestamp in the Rapid7 console refreshes to the current run window, and queued telemetry uploads. Validate locally with Get-Service -DisplayName "Rapid7 Insight Agent" | Select-Object Name, Status and confirm the value is Running. From the Rapid7 InsightVM or InsightIDR console, confirm the endpoint moves from a stale or uncovered state back into active coverage.

Subsequent Automox policy runs evaluate the same endpoint and find the service already Running, so remediation does not fire again. If the service stops between runs because of a Windows update, a dependency failure, or an operator action, the next evaluation catches it and the Worklet restarts the service without an admin touching the endpoint. The Worklet does not interfere with Rapid7's own service watchdog, and it does not change scan schedules, agent versions, or InsightVM site assignments; those remain controlled from the Rapid7 console.

If the Worklet runs repeatedly on the same endpoint and the service keeps stopping, that pattern is a signal to investigate the root cause. Check the System and Application event logs for agent errors, look for a conflicting security product, and review recent Windows updates. Persistent failures often point to a corrupted install that needs a clean reinstall from Rapid7, which is outside the scope of this Worklet.