Windows - Maintenance Tasks - Start Service Worklet

What the Windows service restorer does

This Automox Worklet™ restarts Windows services that have stopped on managed endpoints. The Worklet reads a ServiceNames array from policy configuration, queries each entry with Get-Service, and calls Start-Service against any service whose Status is not Running. The script handles common targets such as BITS (Background Intelligent Transfer Service), the Automox Agent service amagent, Windows Update services wuauserv and UsoSvc, Defender services WinDefend and Sense, and third-party agents from CrowdStrike, SentinelOne, Rapid7, Carbon Black, Splunk, and similar vendors.

The evaluation script never modifies the endpoint. It only enumerates the configured services and exits non-zero when any one of them is stopped or missing, which is what flags the endpoint as non-compliant in the Automox console. Remediation is gated behind that non-compliance signal, so the Worklet never touches a healthy endpoint.

When remediation runs, the script starts each stopped service, waits two seconds for the service control manager to settle, and re-checks Status to confirm the transition to Running. Services that fail to start log the underlying Win32 exit code to standard error without halting the loop, so a single misconfigured entry does not block the rest of the array from being restored.

Why enforce a Windows service uptime baseline

Stopped services are how silent compliance failures begin. A laptop reboots into a state where the EDR sensor never reattached, a server's backup agent crashed at 02:14 and no one pages until the next restore test, a Windows Update service was disabled by a third-party utility and the endpoint quietly stops receiving patches. The CIS Microsoft Windows benchmarks (sections 5.x on system services) and NIST 800-53 control SI-4 both assume the security-relevant services on an endpoint stay running. None of that is true by default on a fleet of thousands of endpoints.

The services that matter most for compliance are also the ones most likely to silently stop. EDR sensors fail to reattach after a kernel-mode driver update, backup agents crash on a malformed archive and exit without restarting, the Windows Update service gets disabled by a third-party hardening utility. The Worklet walks the ServiceNames array on every agent check-in, calls Start-Service against any entry whose Status is not Running, and writes one activity-log line per service. The resulting evaluation report maps directly to CIS section 5.x and NIST 800-53 SI-4 evidence requests, with per-endpoint timestamps showing when each service was restored.

How Windows service uptime enforcement works

1. Evaluation phase: The Worklet iterates the ServiceNames array and runs Get-Service -Name <name> -ErrorAction SilentlyContinue against each entry. A missing service (null return) is treated as non-compliant; a Status value other than Running is treated as non-compliant. The script writes one line per service to Write-Output for activity-log evidence (for example, "amagent: Stopped" or "wuauserv: Running"), then exits 1 if any service was stopped or missing, or 0 if every service was already Running.

2. Remediation phase: The remediation script re-enumerates the same ServiceNames array, skips services already Running, and calls Start-Service -Name <name> on the rest. After each start attempt it sleeps two seconds and runs Get-Service again to confirm the service reached the Running state. Services that fail to start (for example, a disabled StartupType or a missing dependency) are caught with try/catch, the Win32 error is written to Write-Error, and the loop continues so one failure does not block the remaining services. The script exits 0 when every targeted service ends in Running and non-zero when any service is still stopped after the start attempt.

Windows service restoration requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025 endpoint with the Automox Agent installed

• PowerShell 5.1 or later; the Automox Agent already provides this context

• Local System or administrator privileges to call Start-Service against the target services (the Automox Agent runs as Local System by default)

• Populate the ServiceNames array in both evaluation.ps1 and remediation.ps1 with the exact service Name values (not DisplayName); confirm with Get-Service | Select Name, DisplayName, Status before scheduling

• Each target service must have StartupType set to Automatic or Automatic (Delayed Start); a service marked Disabled requires Set-Service -Name <name> -StartupType Automatic in a companion Worklet before Start-Service will succeed

• Allow two seconds of settle time per service; the Worklet handles this internally, so the total runtime scales linearly with the array length

Expected service state after remediation

After remediation runs, every service named in the ServiceNames array reports Status=Running on the endpoint, the activity log captures one line per service confirming the transition, and the endpoint flips to compliant on the next Automox evaluation cycle. Services that were already running are left untouched. The Worklet is idempotent: a second run on an already-compliant endpoint detects nothing to do, writes the per-service Running confirmations to Write-Output, and exits 0.

Validate by running Get-Service -Name <name> | Select Name, Status, StartTime on the endpoint and confirming StartTime is recent for the restored services. Audit evidence lives in the Automox activity log: each policy run captures the per-service status lines and the final exit code, which together prove that the service was stopped, that the Worklet ran, and that the service returned to Running without manual intervention. For services that fail to start despite remediation, the Write-Error output names the Win32 error code (commonly 1058 for Disabled, 1068 for a missing dependency, or 5 for an access-denied condition) so the next investigation starts with a specific failure mode rather than a generic timeout.