Create User Based Scheduled Task

What the logon-triggered task scheduler does

This Automox Worklet™ creates a Windows scheduled task that fires when a user signs in. The task runs under that user's account context rather than SYSTEM. The Worklet drives the PowerShell Schedule.Service COM object to build the task definition end to end, so no XML import or schtasks.exe wrapper is required.

The remediation script constructs a new task with logon trigger type 9 (TASK_TRIGGER_LOGON), attaches an executable action with the command path and arguments you specify, and registers the task in the root task folder. The task is registered against the local Users group with TASK_LOGON_GROUP semantics, which is what lets the action run in the signed-in user's profile instead of the SYSTEM context. The default task name is Run at user logon, and the default action is a sample cmd.exe call that writes the user's TEMP path to c:\temp\out.txt for verification.

Edit the $action.Path and $action.Arguments variables in remediation.ps1 to point at the executable, script interpreter, or binary you want to run at logon. The evaluation script always returns exit code 1, so the Worklet recreates the task definition on every policy run. The registered task is re-asserted if a user with local admin, a profile reset, or a competing GPO removes it. A recurring weekly cadence keeps the definition current without surfacing changes to signed-in users.

Why automate logon-triggered tasks at fleet scale

Drive mappings, license activations, profile bootstrap scripts, and per-user telemetry agents all need a hook that fires after the user shell loads, not at boot. Without a fleet-wide runtime for that hook, admins fall back to roaming profile scripts, login script GPOs, or manual Run keys. Each of those mechanisms drifts independently, fails silently when the user has cached credentials, and cannot be audited across a hybrid fleet of domain-joined, Entra-joined, and workgroup endpoints.

Group Policy Preferences scheduled tasks only reach domain-joined endpoints and break entirely on Entra-joined laptops or unmanaged personal machines. Apply this Worklet through a workstation and server policy so the logon-triggered task registers through Schedule.Service on every endpoint in scope from a single configuration. A recurring evaluation rebuilds the task if a profile reset, an in-place upgrade, or a user with local admin removes it. The result is a logon hook that behaves like a GPO without requiring a domain controller.

How logon-triggered task registration works

1. Evaluation phase: The evaluation script unconditionally returns exit code 1, marking the endpoint non-compliant on every run. That forces the Automox agent to invoke remediation each time the policy executes, so the task definition is rebuilt rather than checked. The registration call is idempotent under TASK_CREATE_OR_UPDATE, so every policy run acts as a self-healing assertion of the task's state.

2. Remediation phase: The remediation script calls New-Object -ComObject Schedule.Service and connects to the local Task Scheduler service. It instantiates a task with NewTask(0), sets RegistrationInfo.Description, and enables Settings.Enabled and Settings.AllowDemandStart. It then creates a logon trigger with Triggers.Create(9) and an executable action with Actions.Create(0), assigning your $action.Path and $action.Arguments values. Finally it calls RegisterTaskDefinition on the root folder with flags 6 (TASK_CREATE_OR_UPDATE) and logon type 4 (TASK_LOGON_GROUP) against the Users principal, registering the task as Run at user logon.

Logon-triggered task requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025

• PowerShell 2.0 or later, which is present by default on all supported Windows releases

• The Automox agent's default SYSTEM-level execution context, which has the privilege to call RegisterTaskDefinition against the root task folder

• Edit $action.Path in remediation.ps1 to the executable, script interpreter (powershell.exe, wscript.exe, cmd.exe), or absolute path to the binary you want to run

• Edit $action.Arguments to the arguments that the executable should receive at logon; quote paths that contain spaces

• Rename the task from the default Run at user logon if you plan to ship multiple logon-triggered Worklets to the same endpoint, so each task is uniquely identifiable in Task Scheduler

• Confirm that any file paths referenced by $action.Arguments (such as c:\temp\out.txt in the default example) exist or are creatable in the signed-in user's security context

Expected state after task registration

After remediation exits, the new task is visible in the root of the Task Scheduler library (open taskschd.msc and select the top-level Task Scheduler Library folder). It carries the registered name and the literal description Test Task - Runs when user logs on, and under user's context. The trigger column reads At log on of any user in the Users group, and the actions column reflects the $action.Path and $action.Arguments values you supplied. The next time any user signs in to the endpoint, Task Scheduler launches the action in that user's interactive desktop session.

Inspect the registered task programmatically with Get-ScheduledTask -TaskName 'Run at user logon' | Format-List *, or list every logon-triggered task on the endpoint with Get-ScheduledTask | Where-Object { $_.Triggers.CimClass.CimClassName -eq 'MSFT_TaskLogonTrigger' }. The most recent run result is available via Get-ScheduledTaskInfo -TaskName 'Run at user logon', where a LastTaskResult of 0 indicates the action exited cleanly. Because evaluation always returns 1, the next policy run will report the endpoint non-compliant and re-register the task in place, which is the intended self-healing behavior rather than a failure signal in Automox activity logs.