I was recently faced with the challenge of having some Orchestrator 2012 runbooks fire off on a schedule, mainly for custom Active Directory reports that other teams want to receive on a regular basis. Since the days of doing such tedious tasks manually are (thankfully) long gone, I decided to use Orchestrator to automate the creation and distribution of these reports.
The Problem
While it’s a fairly well known fact that Orchestrator has this ability built in via the Monitor Date/Time Activity, I have a hard time stomaching the fact that the runbook has to be running all the time just for its five minutes per week to be useful. So naturally you think about scheduled tasks, but they you have to write a Powershell script for every runbook you want to automate, then create a corresponding Scheduled Task, label it something useful, set it up, test it, and so on. I also considered launching all periodic runbooks from a master scheduler runbook, which wasn’t a bad idea, but everytime I wanted to add another report, I would have to rework this master runbook which would eventually swell to a Krakken-esque monster of lines, activities, data passing, and other headaches.
Kind of like this:
Release the Krakken!
Step 1: Create Runbook Folders in Orchestrator 2012
So my solution is to setup a folder for each schedule in Orchestrator, then a Scheduled Task would kick off all runbooks within its folder when it is invoked. This has the benefit of one task per schedule, and then creating or modifying the schedule for a runbook is as simple as moving it into a folder within Runbook Designer. To accomplish this, we start by creating our folders within Orchestrator, one for each schedule we intend to create. Mine are fairly straightforward; Daily, Weekly, Monthly, and Quarterly. These could follow any schedule that Task Scheduler is capable of.
Create Scheduled Task Runbook folders in Orchestrator 2012
Step 2: Create Powershell Script to Start Runbooks
Next, we need to write a bit of Powershell code that will invoke our runbooks. For this I suggest downloading the System Center Orchestrator Web Service Powershell Module. You can get it from Codeplex here. I’ve been using it for about six months, and it has been a very nice module to have around. Once you have it downloaded, extract it to a central share /directory or copy it to the C:\Windows\System32\WindowsPowerShell\v1.0\Modules folder on the server you intend to invoke the runbooks from. Once you have that taken care of, we’ll create a Powershell script to recursively invoke all runbooks within each folder we created. To keep things simple, I have one Powershell script for each runbook folder. Below is the script I use stripped down to the essentials for clarity. To make it work for your environment, you should only need to change the path of the Orchestrator Web Service Module, the URL of your Orchestrator Web Service (Remember to append the port number if you’re using something other than 443), the folder path to your runbook folder you created in the previous step, and the two log file directories at the end that output the contents of the Powershell $error variable and the identity the script is running under. While those last two lines are optional, I put those in almost every Powershell script I automate to aid in initial troubleshooting, I find it saves some time.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# Import the SCORCH module Import-Module 'D:\Modules\SCOrchestratorServicePowerShellV1_2\OrchestratorServiceModule.psm1' # Set URL for web service $scorh_url = "https://ScorchSVR1.lab.local/Orchestrator2012/Orchestrator.svc/" # Set Folder Path for Runbook Folder $runbook_folder = '\Initiation Runbooks\Scheduled Tasks\Daily' # Get all runbooks within the Daily folder $daily_runbooks = Get-OrchestratorRunbook -ServiceUrl $scorh_url -RunbookPath $runbook_folder # Run through them and start each one foreach ($runbook in $daily_runbooks) { # Get the runbook object $runbook_temp = Get-OrchestratorRunbook -ServiceUrl $scorh_url -RunbookId $runbook.Id # Now start the runbook Start-OrchestratorRunbook -Runbook $runbook_temp } # Output error log $error | out-file "D:\logs\error_DailyRunbooks.txt" # Output identity whoami | out-file "D:\logs\identity_DailyRunbooks.txt" |
Once you have that squared away, save it somewhere the server can reach it and name is something useful. At this point you should be able to run this script from Powershell CLI or Powershell ISE and it should invoke anyrunbooks you have in that runbook folder or at very least, not throw any errors.
Step 3: Create Scheduled Tasks
Finally, we create our scheduled task with a trigger set for our schedule, in this example, it runs daily at 3:00AM. The action for the script is set to Start a program. In the Program/Script field put in the path to the Powershell executable “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” and in the Add Arugments field put in -file “D:\Path\to\script\Daily_Runbooks.ps1”. Make sure the values you put in both boxes are in quotes, I had some issues when I tried to run it without them. That’s it! Now you should be able to kick off the scheduled task manually and it will launch all of the runbooks within the specified runbook folder. For testing purposes I made a simple runbook with a single Send Email activity to test each Scheduled Task to make sure it worked before releasing it into the wild.
Test Send Email Runbook in Orchestrator 2012
Now repeat this process for any schedules you want to create, then move runbooks into the appropriate folder. it’s that easy. It’s worth mentioning that this solution may not be ideal if you have several resource intensive runbooks you want to run on the same schedule. In that case it would probably be best to stagger them a bit, because the scheduled task will kick them all off simultaneously and if you’re runbooks are resource heavy, you may find your management servers throw a bit of a tantrum. Alternatively, you could add a Start-Sleep cmdlet to the powershell script so it will pause for a few minutes or so between starting each runbook. Hope this helps, and happy automating!