Running a SharePoint PowerShell script from Task Scheduler

There are often times where you may want to run a PowerShell script for SharePoint on a schedule – for example, a backup routine, report, or script to automate a process – just like the good old days of running a batch file in Task Scheduler. Well, things aren’t really that different these days either – yes, the scripting language may have changed, but Task Scheduler can still be used as before.

In this example, I am going to script the backup of a site collection and run it every night at 2:00AM. First, the script:

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
Backup-SPSite -Identity http://intranet.pacdomain2.local -Path C:\Install\Intranet.bak –Force

Although the script is quite simple, note the Add-PSSnapin command on the first line. We need this because we are going to run the script using the standard Windows PowerShell console application and not the SharePoint 2010 Management Shell that has the snap-in already loaded. The –erroraction switch is there to prevent any errors should the snap-in already be loaded through a profile on the server.

Save your script to a local drive on the server as a PS1 file.

Next, load Task Scheduler from Start > All Programs > Accessories > System Tools. The version I am using here ships with Windows Server 2008 R2, but the concepts should be the same on earlier releases.

To create a new scheduled task, click Create Task from the right-hand “Actions” panel. At a minimum, you should fill out the following information:

General Tab

• Name of the task – e.g., Intranet Backup. A description is also useful, but not mandatory
• Ensure the user account running the task has the following permissions:
• Log on as a batch job rights in the User Rights Assignment section of the server Local Security Policy. These rights could be set on the server itself or by Group Policy if managed from Active Directory – see http://technet.microsoft.com/en-us/library/dd277404.aspx for details
• Permissions to use PowerShell on the SharePoint farm. You can add these for a new user by running Add-SPShellAdmin –UserName domain\username in the SharePoint 2010 Management Shell console as a current administrator – see http://technet.microsoft.com/en-us/library/ff607596.aspx for details
• Permissions to be able to perform the script operation in SharePoint. For example, for the site collection backup in this example, the account used in the scheduled task required:
• dbo access in SQL to the database hosting the site collection
• Membership of the local Administrators group on the server – you may be able to experiment with fewer permissions than this, but this was required on my development server, which is also a domain controller
• Select Run whether the user is logged in or not and tick the Do not store password checkbox
• For certain operations, you may also need to enable the Run with highest privileges option. As this should only be enabled when necessary, I would recommend testing the script from Task Scheduler with the option disabled and only enable if the script does not work without it

Triggers Tab

Click New and add your schedule, as required. In the example below I am going for daily at 2:00AM

Actions Tab

Click New. Ensure the action is set to Start a program and type Powershell.exe in the “Program/Script” box. In the “Add arguments (optional)” box, type &'c:\scripts\script.ps1' replacing the path and name with the details for your script. Wrapping the file path and name in single quotation marks allows you to specify spaces in the text.

When you click OK to confirm task creation, you will be prompted to enter the password for the account you selected to run the script. Enter the password and click OK.

You should now see your script in the Task Scheduler Library (if not, click Refresh in the right-hand panel). To test the script, highlight it in the console and click Run from the right-hand panel.

Check that the changes required are performed (for this example it was checking to ensure the backup file was being created in the folder when the task ran) and leave it to run on the schedule. Don’t forget to perform regular checks in the future to test the script continues to run as expected.