This article is a follow-on to my previous post, Cool Tool: New Command Line Utility to Start a Runbook , where I talked about using the web service to quickly start a runbook with named parameters. Now it’s time to put that into action!
Orchestrator administrators know that Orchestrator is not built to be a scheduling tool. Sure, it can use a “Monitor Date/Time” activity to actively start new runbook jobs on a regular basis. The problem is that it’s a bit clunky . Let’s say I wanted to have a runbook run every Monday at 10:15pm. Here’s how would I do that:
- Put a Monitor Date/Time Activity at the beginning of my runbook and set it to run every hour at 15 minutes past the hour.
- Create a Schedule (under Global Settings) and call it “Monday 10-11” and set it so that it runs on any Monday, and that the only hour permitted is from 10pm to 11pm.
- Add a Check Schedule activity to the runbook at point it to the schedule just created
- Change the link conditions from the Check Schedule activity to the next activity so that it triggers the next activity only when the current time conforms to the schedule requirements.
The screen shots of steps 1 through 4 are below:
Now this process will give me the results I needed. The activities after the Check Schedule activity will run every Monday at 10:15 PM. So here’s what’s clunky about that:
- This runbook is a monitor, so it is always running and therefore always consuming one of the available slots in your policy limit
- When you have multiple scheduled runbooks set up like this, they are all always running and consuming your policy limit.
- This runbook will trigger the Check Schedule activity every hour. 24 hours in a day x 7 days is 168 (yes, I had to get a calculator).
- So every week, this runbook will fire 167 times and then be stopped at the Check Schedule activity.
- One time per week, it will continue past that activity.
- This means you have 167 entries in the Orchestrator Console showing a job ran where it actually didn’t do anything. This gets to be a big distraction as an admin.
- Now multiple this by however many scheduled runbooks you have.
- There is no easy (or even remotely easy) way to get a list of runbooks that are scheduled so you quickly know “I have a runbook starting tonight at 9PM and another one at 10PM”.
So now do you see why we always say that Orchestrator *can* do scheduled runbooks, but it’s not designed to be a scheduling tool? Now that you know what *not* to do, here’s an easy way to do scheduling using something as simple as Windows Task Scheduler. It’s installed on every Windows Server, so it’s not like you have to go buy something else. However, if you already have some enterprise scheduling tool, you can transfer this knowledge to that and get the same benefit.
First of all, I opened Task Scheduler and created a new folder called System Center 2012 Orchestrator. You might just call it Orchestrator, but the marketing / branding folks around here will beat me with a wooden (compostable) spoon if I don’t use the correct term.
Then you just right-click and select Create Task to open the Create Task form.
In the form, enter a name and description, and set the task to Run whether a user is logged on or not (since it an automated thing running a web service).
Click on the Triggers tab and then click New . Let’s assume I’m going to keep my Mondays at 10:15 PM schedule. Here’s what that would look like:
As you can see, there are some options that I can set here that I couldn’t even replicate in the runbook without some complex PowerShell script or something, like time zone synchronization, random delays, expiration, and so on. When I click OK, this schedule is saved and I could actually add a number of schedules here if I wanted to mix and match monthly with daily or some other combination.
Click on the Actions tab – this is where the runbook is triggered from. Click New and the New Action form appears. I select Start a Program and then enter the path to my SCOJobRunner.exe utility, and the command line arguments I need to start the runbook. If I’m running this on the same server as my Orchestrator Web Service, I don’t need to specify the web server or credentials (credentials are already specified in the task definition). All I need to specify is the runbook ID or path and the parameters needed (if any). For example:
-RunbookPath:"\Scheduled Runbooks\Run My Script" -Parameters:"Path='Path 1';Other Text='some other text here'"
Noticed how I cleverly used a folder named “Scheduled Runbooks”? This tells me (or anyone else using the Runbook Designer or Orchestration Console) that all the runbooks in the folder are run on a schedule.
Clicking OK brings me back to the Actions tab, where I see I can add even more actions (such as if I want to run multiple runbooks at the same scheduled time).
Now click on the Conditions tab. Here I can specify conditions (go figure) where the task will run or not. Since this is a server, I can generally leave all the settings here alone. However, if you happen to be doing a demo of Orchestrator on a laptop, you should uncheck those AC power and battery options.
Finally, click the Settings tab. Here you can define some additional options to your needs. For me, I’ll leave the defaults.
Clicking OK causes a prompt for the credentials for running this task. Enter those and click OK and you’re back at the main Task Scheduler page and you can see the new task there.
So now if you want to add more scheduled runbooks, you just add them the same way, and now you have a convenient list of runbooks and their start times you can access, and it even shows you the next time it’s going to run. By clicking on the History tab below, you can even see a list of all the times the task ran and the results.
The benefits to this approach, rather than creating Monitor runbooks, are:
- You don’t have monitor runbooks that are constantly running
- You don’t trigger lots of runbooks to start unnecessarily (like 168 times just to get one successful one), so you don’t fill up the long with “junk”
- You get a convenient list of all the runbooks that are scheduled to start and you can control them all from one place.
So hopefully this article has taught you something about scheduling in Orchestrator, a little about Monitors (more on that subject later), and a good use for the command line tool I mentioned in the previous post.
Download the zip file containing the utility here: SCO Job Runner - Command Line Utility
Download the source code to the utility here: http://orchestrator.codeplex.com/SourceControl/list/changesets
Until next time!