Good morning/afternoon/evening AskPerf! Blake here with a post I’ve been meaning to write/publish for a year or so now. Here in on the Performance Team, we support a wide range of technologies, with Task Scheduler being one of them. More often than not, the number one Scheduled Task issue we encounter is as follows:
“In Windows 2003/XP, my scheduled tasks ran with no problems. Since we’ve upgraded to Windows 2008/2008-R2/Win7/Win8/2012/2012-R2 , our tasks no longer run.”
With that, we explain that Task Scheduler was completely re-written in 2008/Vista, with one of the main changes being in Security. Here is a snippet from a Technet Article published back on March 3, 2006:
Security. In the Windows Vista Task Scheduler, security is vastly improved. Task Scheduler supports a security isolation model in which each set of tasks running in a specific security context starts in a separate session. Tasks executed for different users are launched in separate window sessions, in complete isolation from one other and from tasks running in the machine (system) context. Passwords are stored (when needed) in the Credentials Manager (CredMan) service using encryption interfaces. Using CredMan prevents malware from retrieving the stored password, tightening security further.
In Windows Vista, the burden of credentials management in Task Scheduler has lessened. Credentials are no longer stored locally for the majority of scenarios, so tasks do not "break" when a password changes. Administrators can configure security services such as Service for Users (S4U) and CredMan, depending on whether the task requires remote or local resources. S4U relieves the need to store passwords locally on the computer, and CredMan, though it requires that passwords be updated once per computer, automatically updates scheduled tasks configured to run for the specific user with the new password.
Enter the new world of Session 0 Isolation .
Prior to Vista/2008 Server, all services ran in the same session as the first user who logged onto the console - this is Session 0. Well, running user apps and services in this session posed a security risk because services run at elevated privileges and can be targets for malicious code.
Enter the new and improved Task Scheduler that uses Session 0 isolation. In Vista/2008 and higher, we mitigate this security risk by isolating services in Session 0, and making it non-interactive. Only system processes and services now run in Session 0. The first user who logs onto a machine does so in Session 1. Subsequent users log into Session 2, 3, 4, etc. Doing this isolation protects services and system processes from tasks ran in this session.
So, how does this isolation prevent my task from running?
- There is no active Shell (explorer.exe)
- If a process/service tries to display a message box, the task will not complete
- Non-interactive
- Apps creating globally named objects
- Possible network communication failures
For more information about Session 0 Isolation, please see the link above.
At this point, we need to determine if there is a simple workaround to get your task to run, or determine if the application vendor needs to be engaged.
Typically, I start with making the following Security changes to my Scheduled Task:
“Run only when user is logged on”
With this option selected, my task will only run if I am logged on with my WillyP account. I can now test and confirm to see that Task Scheduler properly launches/runs my task. Selecting this option also runs my task interactively in my session.
You will see notepad.exe running in the same session as my logged on user – Session ID 2.
Now, let’s look at the behavior when I have the other Security option selected.
“Run whether user is logged on or not”
With this option selected, I am telling Task Scheduler to run my task whether I am logged on or not – aka Session 0 isolated. Let’s see how this looks when my Willyp user is logged off and I schedule a task to run.
As you can see, notepad.exe is running in Session 0. The other process, taskeng.exe, is the Task Scheduler Engine process that started my task.
So, you may be asking yourself, would if I am logged on with this account, and the “Run whether user is logged on or not” is selected - will it be interactive? No, as Session 0 is a non-interactive session, therefore you will not see your Action even if you are logged on as the running user account.
Now, how do we troubleshoot this and get your task to run? Well, in troubleshooting these issues, I’ve come across multiple ways to fix them. You may have to experiment to see which of the following works for you in your scenario.
- If your Task requires UAC Elevation, select the “ Run with highest privileges ” option under Security on the General tab
- If you are launching a Batch script (.vbs/.cmd/.bat/.ps1), modify your script to add some type of logging to see where it may be failing – see the following blog for examples: Two Minute Drill: Quickly test Task Scheduler
- Try creating a new task, but select the Configure for: option to be “ Windows Server 2003, Windows XP, or Windows 2000 ” – this will create an XP/2003 fashioned task
- If running a .vbs / .ps1 script, try launching it from a .cmd / .bat script – for example: “ cscript.exe myscript.vbs” would be in my .cmd/.bat script, and I would then launch it from my Scheduled Task
- Check your scripts for environmental issues – when we run a script, we default to the “%SystemRoot%\System32” folder unless specified in the script (i.e. CD C:\Scripts\Test)
- If you are running nested scripts/programs within one script, try breaking them out as multiple Actions – for example:
So, when script1.cmd finishes, script2.cmd will be launched. Then when script2.cmd completes, script3.cmd will run.
- If running a 3 rd party app/script, engage the app vendor to check if their app/process will run correctly in a non-interactive session
- Try running your script with the SYSTEM account
- Check the History tab for clues as to why your task is not running
- If copying files to network shares via script, use UNC paths instead of mapped drives, especially if you are selecting the “Run whether user is logged on or not” security option
- If all else fails, your only choice may be to “Run only when user is logged on”
As we come across different issues/fixes, I will add them to the bulleted list above.
Play around with the options above and see if you can get your Scheduled Task to run. If you come across a different fix not mentioned above, let us know in the comments below.
Microsoft
