Scheduling scripts to run at a later time

One of the most common tasks that Exchange administrators perform is scheduling scripts to run at a later time. This can be useful when performing maintenance after hours or running monitoring scripts on a regular basis. In this recipe, you'll learn how to schedule your PowerShell scripts to run with the Windows Task Scheduler. In PowerShell Version 4, we have some powerful new cmdlets to manage Windows Task Scheduler.

How to do it...

To create a scheduled task that runs from one of your Exchange servers, perform the following steps:

1. Open the Windows Task Scheduler by navigating to Start | All Programs | Accessories, click on the System Tools folder, and then click on the Task Scheduler shortcut.
2. From the Action menu, click on Create Basic Task.
3. Give your task a name and description and click on Next.
4. On the Trigger screen, select how often you'd like the script to run (Daily, Weekly, Monthly, and so on).
5. When asked what action you want the task to perform, select Start a Program.
6. Use the following syntax in the Program/Script field and click on Next:

   C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe - ` command ". 'C:\Program Files\Microsoft\Exchange ` Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer ` -auto; c:\Scripts\MoveMailboxes.ps1".
   

7. You will receive a prompt that says It appears as though arguments have been included in the program text box. Do you want to run the following program? Click on Yes.
8. This will bring you to a Summary screen, where you can click on Finish.

How it works...

The syntax used in this example may look a little strange at first. What we are actually doing here is scheduling PowerShell.exe and using the -Command parameter to execute multiple statements. This allows us to pass the contents of a PowerShell script to PowerShell.exe. In this case, our script has multiple lines and each statement is separated by a semicolon.

The first thing we do is dot-source the RemoteExchange.ps1 script located in the Exchange Server bin directory. This file initializes some Exchange shell variables and imports several Exchange-specific functions.

The next line of the task calls the Connect-ExchangeServer function using the -Auto parameter, allowing the Exchange Management Shell environment to automatically load from the best Exchange Server in the local AD site.

Finally, we provide the path to our .ps1 script that utilizes any required Exchange Management Shell cmdlets and the script is executed, carrying out whatever it is that we need to be done.

It's worth mentioning here that you do not have to use a .ps1 script file with this syntax. You can replace the call with the MoveMailboxes.ps1 file with any valid PowerShell commands. If you have a script that contains multiple lines, you can continue to separate each line using a semicolon.

When using this method, make sure that you configure the scheduled task to run as a user that has administrative access to your Exchange organization. In addition, RBAC should be considered to minimize and use the least required privileges when dealing with accounts that are used to run actions within the task scheduler.

Also, if you have User Account Control (UAC) enabled, you may need to enable the option to Run with highest privileges in the properties of the scheduled task, this for using elevated privileges. Additionally, you will probably want to enable the option to Run whether user is logged on or not in the properties of the scheduled task.

There's more...

The previous example demonstrated scheduling a task from an Exchange server using the installed Exchange Management Shell tools. Since all of the Exchange Management Shell connections utilize PowerShell remoting, it is possible to schedule a script to run from a workstation or server that does not have the Exchange tools installed. The only requirement is that the machine must be running PowerShell v2 or later.

To schedule a task from a machine that does not have the Exchange tools installed, use the steps from the previous example, but use the following syntax for the program action:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command ` "$s = New-PSSession -ConfigurationNameMicrosoft.Exchange - `ConnectionUri http://ex01.contoso.com/PowerShell/; Import- ` PSSession $s ; c:\Scripts\MoveMailboxes.ps1"

You can see here again that we are scheduling the PowerShell.exe program and specifying the script using the -Command parameter. The difference is that this time, we are not using the locally installed Exchange tools. Instead, we are creating a manual implicit remoting connection to a particular Exchange server. The length of the command line wrapping makes it difficult to read, but keep in mind that this is all done on one line.

When using this method, you can configure the scheduled task to run as a user that has administrative access to your Exchange organization, or you can provide the explicit credentials used to create the session object and run the script as another user.

Scheduled tasks can since Version 4 of PowerShell can also be added using the cmdlets.

An example of this would look like the following:

$TaskCommand = ` "c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe"
$TaskArg = '-command "$s = New-PSSession -ConfigurationName ` Microsoft.Exchange -ConnectionUri ` http://ex01.contoso.com/PowerShell/; Import-PSSession $s; ` c:\Scripts\MoveMailboxes.ps1"'
$TaskStartTime = [datetime]::Now.AddMinutes(15)
$TaskAction = New-ScheduledTaskAction -Execute "$TaskCommand" ` -Argument "$TaskArg" 
$TaskTrigger = New-ScheduledTaskTrigger -At $TaskStartTime -Once `
Register-ScheduledTask -Action $TaskAction -Trigger $Tasktrigger ` -TaskName "Scheduled task - Move Mailboxes" –User ` "contoso\administrator" -RunLevel Highest

We created a variable named TaskCommand, which refers to powershell.exe, including the full path. Secondly, we are creating the TaskArg variable, which is used to decide what arguments in powershell.exe should be used. TaskStartTime is using the current time, plus 15 minutes Finally, we use these variables and register the scheduled task.

See also

• Manually configuring remote PowerShell connections
• Using explicit credentials with PowerShell cmdlets