SCHED_E_PAST_END_BOUNDARY (0x8004131E): Task Scheduler End Boundary Fix

What 0x8004131E actually means

Task Scheduler isn't confused, and your task isn't corrupted. The error message is literal: the trigger you set has an end boundary, that boundary is in the past, and Task Scheduler flatly refuses to start a task it considers expired. You'll see it in Task Scheduler's Last Run Result column as 0x8004131E, or in schtasks /query /v output as SCHED_E_PAST_END_BOUNDARY. The event log entry under Microsoft-Windows-TaskScheduler/Operational spells it out the same way.

I see this most often with tasks someone created "temporarily" six months ago to push a software deployment, then forgot about. The end date was set to that project's deadline. Project finished, task stayed, deadline passed, now every scheduled run fails. Same thing happens on Windows Server 2016/2019 boxes where an admin cloned a task template from a previous quarter and never touched the date fields.

Cause 1: The trigger's end boundary date is in the past (most common)

This is the cause about 90% of the time. Every Task Scheduler trigger has an optional Expire setting. If someone ticked that box and picked a date, the trigger stops firing once that date passes. The task itself still exists, still shows in the library, still looks perfectly configured — it just won't run.

The GUI fix

1. Open Task Scheduler (taskschd.msc).
2. Find the task, right-click, choose Properties.
3. Go to the Triggers tab and double-click the trigger.
4. Look at the Expire field. If it's checked and shows a date before today, that's your problem.
5. Uncheck it, or change the date to something far enough out. Click OK, then OK again.

Unchecking is the honest fix unless you actually want the task to stop on a specific date. If you set it to "never expire" and later need to disable it, just disable the task — don't rely on an end date as a kill switch. That's how these get forgotten.

The command-line fix

If you're dealing with a fleet of servers, GUI clicking is a waste of a Tuesday. Use schtasks to rewrite the trigger. The trick is /Z combined with /ET — /Z deletes the task after its last run (skip that), and the relevant flag is /ET for end time, then omitting it clears the boundary:

schtasks /Change /TN "\MyFolder\MyTask" /ET 23:59

That resets the end time to 23:59 with no date, effectively extending the boundary to the end of the current period. To fully remove it, you need to delete and recreate the trigger, because schtasks won't leave the field blank once it's been set. XML export/import is the cleanest path:

schtasks /Query /TN "\MyFolder\MyTask" /XML > task.xml
:: edit task.xml, remove the <EndBoundary> element
schtasks /Create /TN "\MyFolder\MyTask" /XML task.xml /F

The reason this works is that the XML schema treats <EndBoundary> as optional. Delete the element entirely and the trigger has no expiry — which is what you want in almost every case.

Cause 2: The task was created with a relative end date that already elapsed

Some deployment tools and Group Policy Preferences generate scheduled tasks with end boundaries calculated as "start time + N days." Microsoft Endpoint Configuration Manager (SCCM), for example, used to push maintenance-window tasks with a fixed expiry. If the deployment window was configured for a two-week period and the machine was offline during that window (laptop that went home for a week), the task was created with an end boundary already in the past by the time the client came back online.

You'll spot this pattern when several machines fail the same task and the failure dates cluster around a specific range. The task XML on those machines has an <EndBoundary> that's clearly a day or two before the machine's first successful policy refresh.

Fix

Don't manually patch each machine. Fix the source: the deployment template that's generating these tasks. In SCCM, that's under Software Library > Application Management > Deployment Types — check the user experience settings for any "required after" or deadline configuration. In GPP, open the Scheduled Tasks preference and clear the end-date field so it's not templated.

For machines already affected, the same XML edit from Cause 1 works. Push it via a startup script or remediation:

$task = Get-ScheduledTask -TaskName "MyTask"
$task.Triggers[0].EndBoundary = $null
Set-ScheduledTask -InputObject $task

Setting EndBoundary to $null via the ScheduledTasks PowerShell module is quicker than the XML route and doesn't require exporting anything. It's available on Windows 8/Server 2012 and later.

Cause 3: Clock skew or time zone mismatch on the host

This one is sneaky. The end boundary is clearly in the future — you checked, it says 2027 — but the task still throws 0x8004131E. What's happening is the machine's local clock is wrong, or the trigger's time zone setting doesn't match the machine's actual time zone.

I've hit this on VMs that were restored from an old snapshot without time sync. The VM thought it was March when the hypervisor host knew it was September. Task Scheduler evaluates the boundary against local system time, so from its perspective the boundary had already passed.

The other version: the trigger was created with TimeZone set to a specific region (say, UTC), but the machine is in Pacific. The task creator was in London and set a UTC boundary of 17:00, which is 10:00 Pacific — fine for them, expired for you if the actual deadline was 17:00 Pacific.

Fix

Check the clock first:

w32tm /query /status
w32tm /resync /force

If the offset is huge (measured in hours or days), reseeding from a reliable source usually sorts it. On domain-joined machines, make sure the machine is pointing at the domain hierarchy:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time

For the time zone mismatch, either remove the explicit TimeZone from the trigger (leaving it to local time) or recalculate the boundary. In the GUI, the time zone dropdown lives right under the trigger schedule. If you see a specific zone set and the original task author wasn't in that zone, that's a red flag.

Quick-reference summary

Whichever cause applies, the underlying rule doesn't change: Task Scheduler compares the trigger's end boundary to local system time and refuses to fire past it. Fix the boundary, or fix the clock it's being compared against. Everything else is just where you click.