18

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.

Example Current Schedule

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.

  • 1
    I'm having the same issue and I have not found a fix. Have you? Seems like such a large bug. Also found the Google Chrome's task work, but the task I have made do not. So maybe it is a deeper permission issue? – Tyler Dec 31 '16 at 9:37
  • I found that if I created a "one-time" schedule that started in the future and ran indefinitely it worked. Haven't found anything else yet. – SteveB Jan 3 '17 at 19:44
  • Such an odd error to be allowed into the system. I cant believe only you and I have found it. Is there a way we can report it so it can be resolved? – Tyler Jan 12 '17 at 23:26
  • This problem also caught me when migrating from Windows Server 2012 to 2016, and I think I found an explanation for it (see my answer). Are you sure that previous versions of Windows behaved differently? – Heinzi Feb 9 '17 at 12:09
  • 2
    Yes. 2012 behaved the way we all assume it should. – SteveB Feb 10 '17 at 14:25
5

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.

  • Thank you for the information! I was going mad with frustration. My tasks were imported from an older Server 2012 box to a new Server 2016 machine. That's when I started seeing this issue. – David Gunderson Jul 15 '17 at 15:17
  • Appreciate your efforts. Do you know if a patch has been released already (October 2017)? do you have a reference to a relevant KB article or something of that sort? – yossiz74 Oct 9 '17 at 13:33
  • I do not have a KB for this, but I have found in testing that since the September 2017 cumulative patch, the issue has gone away, so I believe this is now fixed. – Tom Collins Oct 11 '17 at 19:33
  • As of Feb 2018, on Win Server 2016, "Repeat Task Every XX minute" tasks are not running if I disable them and re-enable. – Ben Amada Feb 20 '18 at 11:48
3

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 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 missed option.

So, yes, it's a bug, but it's the "Next Run Time" column which is buggy, not the actual scheduling.

  • The only problem with scheduling it for a day is these are some of our monitoring tasks. I don't want to go hours without them. – SteveB Feb 10 '17 at 14:26
-1

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

I noted these options in the screenshot

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.

protected by Community Feb 6 '17 at 7:26

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.