Using Windows Task Scheduler to Invoke Scheduled Runbooks

Using Windows Task Scheduler to Invoke Scheduled Runbooks

  • Comments 10
  • Likes

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:

  1. 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.
  2. 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.
  3. Add a Check Schedule activity to the runbook at point it to the schedule just created
  4. 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:

image

image

image

image

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.

image

Then you just right-click and select Create Task to open the Create Task form.

SNAGHTML498f982

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).

image

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:

image

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.

image

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.

image

Finally, click the Settings tab. Here you can define some additional options to your needs. For me, I’ll leave the defaults.

image

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.

SNAGHTML4acad18

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.

image

The benefits to this approach, rather than creating Monitor runbooks, are:

  1. You don’t have monitor runbooks that are constantly running
  2. 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”
  3. 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!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • If I run the Job runner from a command window it works fine but if I run it from the scheduled task I get an (0xE0434352) in the Last run Result and the runbook does not do it's Job :(

  • This is good to keep the number of monitoring runbooks low. However, when you have multiple runbook servers for redundancy, the scheduled job would need to be configured on all runbook servers to sustain the failure of one server but doing so will trigger the runbook multiple times as Windows Task Scheduler does not know if the task is running or not on other servers. What's your thoughts on this?

  • I am trying to run this but it keeps failing with an Unhandled Exception

    Unhandled Exception: System.Data.Services.Client.DataServiceRequestException: An

    error occurred while processing this request. ---> System.Data.Services.Client.

    DataServiceClientException: <?xml version="1.0" encoding="utf-8" standalone="yes

    "?>

    <error xmlns="schemas.microsoft.com/.../metadata">

     <code></code>

     <message xml:lang="en-US">The requested operation requires Publish permissions

    on the Runbook</message>

    </error>

      at System.Data.Services.Client.DataServiceContext.SaveResult.<HandleBatchResp

    onse>d__1e.MoveNext()

      --- End of inner exception stack trace ---

      at System.Data.Services.Client.DataServiceContext.SaveResult.HandleBatchRespo

    nse()

      at System.Data.Services.Client.DataServiceContext.SaveResult.EndRequest()

      at System.Data.Services.Client.DataServiceContext.SaveChanges(SaveChangesOpti

    ons options)

      at System.Data.Services.Client.DataServiceContext.SaveChanges()

      at Microsoft.SystemCenter.Orchestrator.Integration.Administration.SCOJobRunne

    r.SCOJobRunner.InvokeRunbook()

      at Microsoft.SystemCenter.Orchestrator.Integration.Administration.SCOJobRunne

    r.SCOJobRunner.Main(String[] args)

  • I have similar problem as Rob and in Application Event Log is error:

    Source: .NET Runtime

    Eventid: 1026

    Application: SCOJobRunner.exe

    Framework Version: v4.0.30319

    Description: The process was terminated due to an unhandled exception.

    Exception Info: System.IndexOutOfRangeException

    Stack:

      at Microsoft.SystemCenter.Orchestrator.Integration.Administration.SCOJobRunner.SCOJobRunner.Main(System.String[])

    Any ideas?

  • I've an interesting issue. I can run it, and it tells me that a job was created. Even gives me a job id. But nowhere in SCSM does it appear to have created a SR...

  • I also have the error:

    "Application: ScoJobRunner.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception..."

    when running as a sheduled task.  However when I enter the same command that I have scheduled into the command promt, it executes just fine.

  • Any solution to the Publish permissions issue?

  • http://www.kettic.com/winforms_ui/scheduler.shtml

  • Source: .NET Runtime

    Eventid: 1026

    Application: SCOJobRunner.exe

    Framework Version: v4.0.30319

    Description: The process was terminated due to an unhandled exception.

    Exception Info: System.IndexOutOfRangeException

    Stack:

    at Microsoft.SystemCenter.Orchestrator.Integration.Administration.SCOJobRunner.SCOJobRunner.Main

    The problem is that when you start runbooks with scojobrunner.exe at the same time as when the Authorization Cache starts the runbooks will not start. Authorization Cache is running every ten minutes and clear the cache and in that moment the runbook does not have a password when you go thru web services. We have a lot of batchjob running in Orchestrator and we have solved it this way:

    In the evening we run a task that run this command in SQL that disable Authorization Cache:

    use Orchestrator

    --truncate table [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache

    In the morning we run a task that enable Authorization Cache so that you can create new Runbooks:

    use Orchestrator

    truncate table [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache

  • As RP mention, this can create a lot of scheduled task maintenance, which is a reason we're using Orchestrator instead. I generally just add a Run.Net Script activity and add a quick PowerShell script that checks the day of the week if I want it to run on a specific day.