## SMA – Scheduled RunBook that calls a System Center Orchestrator (SCORCH) RunBook fails

This is a guest post by Tom. He regularly posts at www.workingsysadmin.com/

Updated with a workaround

Check out this System Center Orchestrator (SCORCH) runbook.

It’s not very complicated. The Initialize Data item doesn’t do anything unique and the Logging items just pops information into an SQL database. The Run .Net Script item is the “do something” part of this runbook. The function of that script isn’t really important for this post. All it does is clean up (delete) files in a few different directories. It figures out which directories need cleaning up based on the current date. There are no additional modules or add-ins used in this script.

I want to automatically run this SCORCH runbook every 15 days. To accomplish this, I created an SMA runbook with that schedule. The SMA runbook looks like this:


workflow Clean_Up
{
$SCOserverName = "management-server"$URL = Get-OrchestratorServiceUrl -Server $SCOserverName$MyRunbookPath = "\path\to\runbook\Clean UCM"
$PSCredName = "service_account"$PSUserCred = Get-AutomationPSCredential -Name $PSCredName$runbook = Get-OrchestratorRunbook -ServiceUrl $URL -RunbookPath$MyRunbookPath -credentials $PSUserCred$job = Start-OrchestratorRunbook -runbook $runbook -credentials$PSUserCred
$job }  The service_account credentials are stored as an SMA asset. This script gets those credentials and remotely executes the SCORCH runbook named in$MyRunbookPath.

This whole thing isn’t very interesting. There’s a SCORCH runbook that deletes some files and there’s an SMA runbook that calls it every 15 days. Here’s the interesting part: If you trigger the SMA runbook manually, everything works perfectly. If you let the SMA schedule trigger the process, you get this error:

At line:2 char:12 + $URL = Get-OrchestratorServiceUrl -Server$SCOserverName + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cannot find the ‘Get-OrchestratorServiceUrl’ command. If this command is defined as a workflow, ensure it is defined before the workflow that calls it. If it is a command intended to run directly within Windows PowerShell (or is not available on this system), place it in an InlineScript: ‘InlineScript { Get-OrchestratorServiceUrl }’

So what is different between triggering this job manually and letting an SMA schedule trigger it? I have no idea. I’m going to contact Microsoft and report back with my findings.

Update after troubleshooting with Microsoft

The short version of the troubleshooting is that we did a bunch of tests and didn’t find a solution to this problem… or even identify a cause… but we did come up with a workaround: delete and recreate the SMA schedule you’re using under a different schedule name.

Here’s the testing matrix that ended up being relevant and the results:

Existing Runbook with Existing Schedule: Does NOT work

Existing Runbook with New Schedule: Works

New Runbook with Existing Schedule: Works

New Runbook with New Schedule: Works

So, while there were no interesting answers uncovered or bugs identified, there’s at least a workaround for this type of problem.