Windows - Configuration - Set Service Startup Type

What the Service Startup Type Configurator does

This Automox Worklet™ configures the startup behavior of Windows Services by setting their startup type to one of four states: Automatic, DelayedAutoStart, Manual, or Disabled. The Worklet uses the Service Control Manager (sc.exe) to directly modify service configuration rather than PowerShell cmdlets, providing broader compatibility with older PowerShell versions.

The Worklet first evaluates the current startup type of the specified service on each endpoint. If the service's startup type does not match your desired configuration, the endpoint is flagged for remediation. During remediation, the Worklet changes the startup type using sc.exe and verifies the change was successful.

Why configure Windows Service startup types

Misconfigured Windows Services create operational failures and security exposure. Services set to Manual when they should start automatically cause application crashes and failed workloads. Services running unnecessarily consume memory, CPU cycles, and network bandwidth while expanding attack surface. When Print Spooler runs on servers that never print, it exposes CVE-2021-34527 Print Nightmare vulnerabilities without providing any operational value.

Automating service startup configuration enforces security baselines across thousands of endpoints simultaneously. Disabling unnecessary services reduces attack surface, improves boot times, and prevents resource exhaustion. Enabling critical services to start automatically maintains business continuity for line-of-business applications and monitoring agents.

Security frameworks mandate specific service configurations. CIS Benchmarks require disabling Remote Registry, Server service on workstations, and other unnecessary services. NIST 800-53 CM-7 requires restricting functions, ports, protocols, and services to only those required for operation.

How service startup type configuration works

1. Evaluation phase: The Worklet queries the service using sc.exe qc to retrieve the current START_TYPE value. It compares the current startup type (Automatic, DelayedAutoStart, Manual, or Disabled) against your configured target state.

2. Remediation phase: If the startup type does not match, the Worklet executes sc.exe config to set the service to the desired startup type (auto for Automatic, delayed-auto for DelayedAutoStart, demand for Manual, or disabled for Disabled). The Worklet then verifies the change succeeded and reports the result.

Service startup configuration requirements

• Windows 10, Windows 11, Windows Server 2016 or later

• PowerShell version 2.0 or later (sc.exe is native to Windows)

• Administrator privileges to modify service configuration

• Valid Windows Service name (e.g., 'spooler', 'wuauserv', 'winrm')

• Startup type must be set to one of: Automatic, DelayedAutoStart, Manual, or Disabled

Expected service behavior after configuration

After successful remediation, the targeted service starts according to its configured behavior. Automatic services launch during system boot before user login. DelayedAutoStart services launch approximately two minutes after boot, reducing startup contention and improving login performance. Manual services remain stopped until explicitly started by applications or administrators. Disabled services cannot start under any circumstances until the startup type changes.

Verify the configuration by running sc qc servicename from the command line and checking the START_TYPE field matches your desired setting. The Automox Activity Log documents all configuration changes for compliance audits. Subsequent Worklet evaluations confirm the endpoint maintains the configured startup type, preventing configuration drift.

How to validate set service startup type changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for set service startup type.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Set-Service, Select-String, Write-Output.

4. Validate remediation effects from script operations such as Set-Service, Start-Process, Select-String, then rerun evaluation for compliance.