Scheduled Tasks and PowerShell: A Quick Study in Automation

So you have this manual process that you’ve been doing for awhile now every day at 0 dark thirty and have finally taken the time to sit down and bang out a beautiful PowerShell script that does it all for you. After a few days of running the script and watching the output fly by on the screen, you think to yourself, “Wouldn’t it be great if I could just set this to run automatically?” For those savvy *nix admins, you’d set up a cron job on your favorite distro and just let it fly, but what are your options in Windows?

Scheduled Tasks

Scheduled Tasks have been around for quite some time, but their capabilities and, subsequently, their complexities have changed as Windows has matured.The tool that you use to manage scheduled tasks changed names between the release of Windows Server 2003 and Windows 2008 from “Scheduled Tasks” to “Task Scheduler”. It can be found under Start -> All Programs -> Administrative Tools -> Task Scheduler in Windows Server 2008 and under Server Manager -> Tools -> Task Scheduler in Windows Server 2012.

Tasks are made up of the following:

• General Information
  • General information about a task is referring to the Name, Location, Author and Description of a task.
• Security Options
  • Security options control the security context in which a task runs.
  • You can set the task only to run when you are logged in or not. If you choose to run it when you are not logged in, you will need to save your password unless is only to have access to basic local resources.
  • You can set the task to run under a different set of credentials, such as the Local System or as a service account set up specifically for the task if it needs access to network resources.
  • You can set the task to run as an administrator in the context of UAC with the “Run with highest privileges” checkbox.
• Triggers
  • Triggers control when a scheduled task is run.
  • At the most basic level, you can create triggers that fire daily, weekly, monthly, one time, when the computer starts, when you logon to the computer, or when a specific event is logged in the event log.
  • For complex tasks, you can setup multiple triggers for a single task.
• Actions
  • Actions are the actions a task takes.
  • Possible actions that can be taken are Start a program, send an e-mail, or display a message. The latter two options are deprecated as of Windows Server 2012, as in most situations you will use either a command line SMTP utility or a function in your PowerShell to send a message.
• Conditions
  • Conditions are extra controls you can build into the task to prevent it from running a muck in certain scenarios.
  • Conditions that can be set are whether to run the task only if the computer is idle, whether to run the task if the computer is on battery power, whether to wake the computer to run the task and whether to run the task if the network is available.
• Settings
  • Settings allow you to go a bit further than conditions do in controlling how the task is run.
  • You can stop the task after a certain period of time.
  • You can retry the task immediately if it fails or if the schedule is missed.
  • You can control whether the task starts a new instance of itself or finished the old one before running again.
  • You can also control whether or not the task can be run on demand or whether it has to be started by one of its triggers.
• History
  • History is a quick overview of what has happened with a task over the last few runs it has been run.

To create a new task, click either “Create Basic Task…” or “Create Task…” in the Actions pane on the right side of the window. It is recommended that you use the Create Basic Task wizard until you are more familiar with tasks in general.

Get to the point!

Now that the basic overview is out of the way, you may find yourself asking, “But I thought those were just for programs and batch files?” Not so, my friend. It is possible to run PowerShell scripts from a scheduled task, it just takes a bit more trickery than a batch file. Here’s what you need to do:

1. If you have not already done so, set your PowerShell script execution policy to something that is appropriate for the type of script you are going to execute. I tend to go for bypass, because all of my stuff is custom written and I do not take the time to sign my PowerShell scripts. This can be done by running the PowerShell CLI as an Administrator, typing “Set-ExecutionPolicy bypass”, hitting enter, and the pressing “Y” to confirm.
2. Create a new task by using the basic task wizard or the create task wizard.
3. Choose the triggers appropriate to how you want the system to start your task.
4. Under Actions, add a new action and select “Start a program”.
5. In the program/script field, enter the following:
   C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
6. In the Add arguments field, enter the following:
   -Command & “<path to your script>”
7. In the Start in field, enter the root path to your script.
8. When all is said and done, it should look roughly like this:
   
9. Save your task and give it a try!

As always, be careful and have fun!

Update 7/11/2013: If you have a need to do this on a large scale or on a regular basis, I would recommend taking a look at System Center Orchestrator 2012. Not only does it give you the ability to schedule, but deep integration with the rest of the System Center suite sweetens the pot even more. Give it a look!