We have a 2012 server that has about 20 scheduled tasks that are used for monitoring. We have built a 2016 server to replace it and as I move tasks to the new server I have run into an issue. Most of our tasks run every few minutes.
In Server 2012 we would schedule the task to start at 1200AM of the current day (so a time in the past) and reoccur every X minutes. The task would start at its next scheduled time. Perfect.
In Server 2016 schedules that start in the past don't run. So we had to schedule it to start in the future. This is fine until you reboot. Now the start time is in the past and it won't run. It doesn't even register a failed run. The Next Run Time column shows that it should run but doesn't.
Besides creating two triggers, one that starts in the future and another that starts on reboot (which we don't want to do since some tasks should only run at specified times), is there a better way? This seems to be a bug. The 2012 version worked great.
UPDATE
There is a workaround for this. Create a one time schedule that runs indefinitely. This works after restarts just like you would expect. I know this isn't great for schedules that are "weird" but works fine for things that we want to run every 3 minutes or whatever.
FYI - I have confirmed with Microsoft through a support ticket I opened yesterday that this is a bug. The support tech confirmed it is internally classified as a bug and a patch is being developed. I was given a target date of release of the patch for July/August.
This affects both Windows 10 and Server 2016. My test systems were patched through to yesterday's cumulative update. The issue did not occur in Server 2012 R2 and Windows 7.
EDIT - As of possibly August, but definitely September 2017, this issue is fixed on systems I have tested it on.
This problem only seems to affect tasks with the
Repeat task every: ...option set.So far, I was under the impression that
trigger at X, then repeat every 10 minutesis just a needlessly complicated way to writetrigger at every xx:x0in Task Scheduler.Apparently, it isn't. Apparently, it means exactly what it says: The task is triggered at
Xand then, and only then it is repeated. No initial trigger, no repetition. I seems that there is no simple way to scheduletrigger at every xx:x0in Task Scheduler (or is there? That might make a good separate Serverfault question.) The fact that the "Next Run Time" column shows something different is not very helpful.We "solve" this problem by scheduling the task to run at 12:00 every day (instead of only one day) and then repeating every
...minutes for 1 day. This means that if a reboot occurs, at 12:00, the tasks will resume. It's not ideal, but it's an acceptable compromise here.I guess you could lower the "task downtime" to 1 hour by creating one trigger for every hour and have the task repeat afterwards every
...minutes for 1 hour.Surprisingly, it seems like it has always been that way (see the first comment to this answer), we just never noticed until now. According to the other comments of the linked answer, the canonical way to solve this issue is to activate the
Run task as soon as possible after a scheduled start is missedoption.So, yes, it's a bug, but it's the "Next Run Time" column which is buggy, not the actual scheduling.
1. Windows 2016 Server necessarily require these options in your job:
I noted these options in the screenshot
2. Add additional trigger. Such as:
etc. within the meaning of: to move a task to start at the desired time
3. In some tasks in Windows 2016 - implemented this approach.