Windows - Maintenance Tasks - Remove Scheduled Task

What the scheduled task remover does

This Automox Worklet™ removes a specific scheduled task from Windows Task Scheduler by exact task name. The Worklet queries the local task store with Get-ScheduledTask, and on any endpoint where the task is registered it calls Unregister-ScheduledTask with -Confirm:$false. Triggers, actions, principals, and the underlying XML definition are removed in a single call.

You provide the task name through the taskName Worklet variable. Copy the value verbatim from the Name column in Task Scheduler so the lookup matches exactly. The Worklet does not enumerate by task path, so a task name that is unique across the fleet gives the most predictable result.

Evaluation is idempotent. If the task is already gone the Worklet exits 0 and remediation is skipped. If the task reappears after a vendor reinstall, image refresh, or GPO push, the next policy run removes it again. Both phases write status to the Automox activity log so you can audit which endpoints removed the task and when.

Why retire orphaned scheduled tasks fleet-wide

Scheduled tasks outlive the software that created them. Vendor uninstallers routinely leave behind update checkers, telemetry agents, and post-install cleanup jobs that keep firing every logon or every hour against binaries that no longer exist. Old maintenance jobs from a previous IT team continue to run scripts pointed at retired file shares. Tasks orphaned by a deprecated application show up as "The task image is corrupt or has been tampered with" entries in the operational log and become a recurring noise source during endpoint audits.

Removing a scheduled task through a single Automox policy run replaces the work that would otherwise require opening Task Scheduler on every endpoint. The evaluation phase uses Get-ScheduledTask to confirm the task exists; remediation calls Unregister-ScheduledTask -Confirm:$false on the endpoints that fail the check. A task that lives on a thousand machines is gone after one policy run, with the deletion logged in the Automox activity feed so the next audit cycle has evidence the cleanup actually ran.

How named-task removal runs on Windows

1. Evaluation phase: The Worklet runs Get-ScheduledTask -TaskName $taskName -ErrorAction SilentlyContinue against the local task store. If the cmdlet returns a task object, the endpoint is flagged non-compliant and exits 1. If the lookup returns nothing, the endpoint is compliant and exits 0 with no remediation.

2. Remediation phase: The remediation script re-checks for the task, then calls Unregister-ScheduledTask -TaskName $taskName -Confirm:$false inside a try/catch. Success writes a confirmation line to the activity log and exits 0; a failure during Unregister-ScheduledTask is logged with Write-Error and exits 1.

Scheduled task removal requirements

• Windows 10 or later, or Windows Server 2019 or later (the ScheduledTasks PowerShell module ships with these releases)

• PowerShell 5 or later; PowerShell 7 also works because the ScheduledTasks module is compatible

• Local administrative rights for the Automox agent context, which the default agent installation already has

• Set the taskName Worklet variable to the exact task name as listed in Task Scheduler (right-click the task, choose Properties, copy the Name field verbatim)

• The task name should be unique within the fleet; Get-ScheduledTask matches by name only and will act on any task that shares the name regardless of its folder

Expected Task Scheduler state after the named task is unregistered

After a successful policy run, the named task is no longer present in Task Scheduler. Validate from PowerShell by running Get-ScheduledTask -TaskName <name> -ErrorAction SilentlyContinue and confirming the call returns no object; an empty result is the success signal. The on-disk XML definition under C:\Windows\System32\Tasks\ and the matching registry entries under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks are removed by Unregister-ScheduledTask as part of the same call. The Automox activity log records the exit code from the remediation script alongside the task-name confirmation line.

Plan for downstream impact before applying the Worklet broadly. If the task was driving a maintenance job, a logon script, or a vendor update checker, that workflow stops after removal. Stage the Worklet against a pilot group of three to five endpoints, confirm no end user workflow regressions, then expand to the full target group. If a vendor installer or an Active Directory GPO re-creates the task on the next reboot, schedule the Worklet on a weekly policy so the next evaluation removes it again without manual intervention.