Scheduled Tasks to Stop and Restart a Service

What the service restart scheduler does

This Automox Worklet™ registers two Windows scheduled tasks that stop a target service at one time of day and restart it at another. The Worklet drives the Windows Task Scheduler from PowerShell using Register-ScheduledTask, with each task wired to a PowerShell action that invokes Stop-Service or Start-Service against the service name you supply in policy parameters.

On every run, the Worklet first unregisters any existing tasks that share the names it manages, then re-registers them from scratch. That keeps schedule changes idempotent: edit the stop time or start time in the policy, redeploy, and the next evaluation rewrites the trigger without leaving an orphaned task in the library. Both tasks register under the root folder of Task Scheduler so admins can find them in taskschd.msc.

Each task is built with New-ScheduledTaskAction (the PowerShell command line), New-ScheduledTaskTrigger -Daily -At (the wall-clock time), New-ScheduledTaskPrincipal -UserId 'NT AUTHORITY\SYSTEM' -RunLevel Highest, and New-ScheduledTaskSettingsSet with ExecutionTimeLimit set via New-TimeSpan and AllowStartIfOnBatteries enabled. The combination runs unattended whether the endpoint is on AC power, on battery, or freshly resumed from sleep.

Why automate service restart cycles

Windows services accumulate memory leaks, stale TCP connections, leaked handle counts, and cached credentials over long uptime. A daily Stop-Service/Start-Service cycle clears that state, holds working-set growth in check, and forces re-authentication against directory services and SQL back ends. The pattern is common for AMAGENT, W3SVC, SQLSERVERAGENT, custom .NET workers, and any application service whose maintainer recommends a recycle window.

Running the restart through Task Scheduler also gives you a local audit trail. Each invocation lands in the Microsoft-Windows-TaskScheduler/Operational event log with the action time and exit status, and the service control manager records the corresponding Stop and Start events under the System log. That trail makes it easy to prove the maintenance window ran on every endpoint without trusting a single central scheduler that has no view of the laptops in the field.

Treating the restart schedule as endpoint state, rather than a one-off ticket, is what makes this approach scale. Each evaluation re-checks the trigger time, principal, and action against the policy values, so an admin edit to taskschd.msc or a competing configuration management run is corrected on the next agent check-in. A brand-new endpoint that joins next week picks up the same pair of tasks the first time the policy evaluates against it.

How service restart scheduling works

1. Evaluation phase: The Worklet calls Get-ScheduledTask against the two task names it manages (one for the stop action, one for the start action). If either task is missing or its trigger time, principal, or action no longer matches the policy parameters, the endpoint is flagged non-compliant. Get-Service is used to confirm the configured service name exists; an unknown service name fails fast and surfaces in the Automox activity log.

2. Remediation phase: The script unregisters any existing copies with Unregister-ScheduledTask -Confirm:$false, then composes both tasks. The stop task gets a New-ScheduledTaskAction pointing to powershell.exe -NoProfile -Command "Stop-Service -Name '<serviceName>' -Force" and a New-ScheduledTaskTrigger -Daily -At <stopTime>. The start task mirrors the pattern with Start-Service. Both are committed with Register-ScheduledTask, the principal NT AUTHORITY\SYSTEM at -RunLevel Highest, and settings that allow execution on battery, restart on failure, and a one-hour ExecutionTimeLimit.

Service restart scheduler requirements

• Windows 8.1, Windows 10, or Windows 11; Windows Server 2012 R2, 2016, 2019, or 2022 also supported

• PowerShell 3.0 or later with the ScheduledTasks module available (shipped in-box on all supported Windows versions)

• Administrative privileges on the target endpoint; the Automox agent's SYSTEM context already meets this for Register-ScheduledTask and Unregister-ScheduledTask

• A valid Windows service name as reported by Get-Service (for example AMAGENT, W3SVC, SQLSERVERAGENT, Spooler, or a custom service short name, not the display name)

• Stop and start times in 24-hour format (HH:MM), with the start time set at least one minute after the stop time so the service has a chance to fully release handles before the start trigger fires

• If the target service has dependent services, plan the maintenance window to absorb the cascade: Stop-Service will halt dependents in order, and Start-Service will restart only the named service unless -PassThru and dependent restarts are layered on top

Expected service restart behavior

After the Worklet runs, two tasks are visible at the root of Task Scheduler under taskschd.msc, one named for the stop action and one for the start action. Get-ScheduledTask -TaskName '<stopTaskName>' returns State Ready, the next run time matches the configured stop time, and Principal.UserId reads NT AUTHORITY\SYSTEM. The same is true of the start task. A subsequent Worklet evaluation reports the endpoint compliant without re-running remediation, because the trigger, principal, and action all match the policy parameters.

At the configured stop time, Stop-Service records an Information event under the System log with source Service Control Manager and event ID 7036 ("entered the stopped state"). At the configured start time, Start-Service records the matching 7036 ("entered the running state"). The Microsoft-Windows-TaskScheduler/Operational log captures event IDs 100, 200, and 201 for action start, action launched, and action completed, including the exit code from powershell.exe. Validate the schedule end to end by running Get-WinEvent -LogName 'Microsoft-Windows-TaskScheduler/Operational' -MaxEvents 50 the morning after the first scheduled run. The Worklet itself exits 0 on a successful registration and non-zero with a stderr message if Get-Service cannot find the service name or Register-ScheduledTask fails.