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.
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.
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 minutes is just a needlessly complicated way to write trigger at every xx:x0 in Task Scheduler.
Apparently, it isn’t. Apparently, it means exactly what it says: The task is triggered at X and then, and only then it is repeated. No initial trigger, no repetition. I seems that there is no simple way to schedule trigger at every xx:x0 in 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 commends 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 missed option.
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:
- Run task as soon as possible after a schedule start is missed or
- If the task fails, restart every
2. Add additional trigger. Such as:
- When creating or editing task
- When you start
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.