Scheduled tasks with idle condition
Problem: You use Group Policy to create a scheduled task that runs only after the computer has been idle for some time.
If your task has a time trigger, you notice that the task runs based on the trigger only and ignores the idle condition. If it is an “on startup” task, it does not run at all. (“On startup” plus idle condition means “run as soon as the idle condition is satisfied”.)
Analysis (note: “Task” means “task with an idle condition”):
The task scheduler obeys an idle condition in a task only after the computer has been restarted after the task was configured.
Any change to the task definition interrupts the idle condition, including GP pref application in Update (event 140, updated) mode. (In Replace mode the task definition is deleted and recreated, resulting in a new task.)
GP prefs are applied during any GP update.
The first GP update happens after the time when startup tasks are triggered.
A task scheduled to run “on startup” does not run until the next startup after it was configured.
Setting the “apply once” pref option prevents the pref item from being applied more than once.
- (1, 2) A time-triggered task from GP pref will always run based on the time trigger only.
- (2, 3, 4, 5): A startup task from GP pref will not run at all.
- (2, 3, 4, 6) A task from GP pref that is set to “apply once” runs based on the configured conditions.
Configure the task as a startup task and set “apply once”, as well as an appropriate “wait for idle” period. Each time the definition is changed, the “apply once” option must be cleared, the task saved, the option set again, and the task saved. This changes the unique ID and the target systems will apply the pref at the next GP update. The task will then run after the next startup, when the pref will again not be applied due to the filter. This has the downside that filter IDs will accumulate on the target systems.
A startup task without an idle condition will run unless preempted by a GP update.
This is, of course, all necessary only because there is a bug in the Windows 10 task scheduler that causes the behavior in no. 1 above. It should be noted, however, that no. 1 is also the statement that I am least confident about. My observations are consistent with it being true, but it is possible that the behavior can be explained in a way that does not require such an egregious bug.