You are browsing the archive for Orchestrator.

Avatar of kurtvh

by kurtvh

“Invoke runbook” isn’t working – called runbook is running, but activity doesn’t start.

9:49 am in Service Manager by kurtvh


We had the following scenario: The Orchestrator install is properly installed on dedicated servers and the database is hosted on a “shared” SQL infrastructure. The company where I was working had his own policies for SQL installations, no idea that this could impact the runbook runtime (correct SQL collation was specified ).

Issue description:

A runbook is monitoring Service Manager Service Requests and based on the information in the request other runbooks are called. The issue we experienced was that the called runbooks are getting in a running state, but never start executing the activities. The proper configuration was made in order to “invoke runbooks”, the properties needed for the called runbook initiation are specified. Every runbook was running when we execute them individually. Non of the runbooks that are called via the “Invoke runbook” activity starts executing the activities.

In the console we could see that the runbook was in a running state, but it simply hangs in a running state. Information found in the Orchestrator log files

PolicyModule.exe log files we saw the following errors: (little summary of the interesting parts of it)

<MsgCode>WorkflowContextComProxy::onPolicyInstanceCreated failed</MsgCode>
<Param>Unspecified error</Param>



RunbookService.exe log file errors:

A lot of different state messages, but one state message that helped us finding a solution for this issue.

Error 524 – Procedure InsertRunbookInstanceInputParameters – Message:A trigger returned a resultset and the server option “disallow results from triggers” is true. (-2147217900)



Issue information and solution:

The error message from the runbookservice.exe log file is indicating a setting on the SQL. Information about this SQL setting can be found here.

In order to check this setting you can run the following query on the SQL instance that is hosting the Orchestrator database.

select value
FROM sys.configurations
WHERE name = ‘disallow results from triggers’

In the environment where we experienced the runbook issue the return value was 1. Like indicated in the log file, this configuration is set on true. The required value returned must be 0 in order fix the runbook issue.

To reset the configuration

exec sp_configure ‘disallow results from triggers’,0

After this re-configuration the runbooks can be called from other runbooks and start executing the activities. Problem fixed!

Honors are for my college – runbook ninja – Stijn Callebaut!


Have fun in the further progress of automating your environment!

Kurt Van Hoecke

Avatar of kurtvh

by kurtvh

From Visio drawing to automated provisioning

10:47 am in Uncategorized by kurtvh



This blog post will describe a solution that is posted on the AuthoringFriday System Center blog site. The solution detailed in this blog post is explaining how you can build your own Integration Pack, how to read information out-of a Microsoft Visio file and start building and post this information back as output of the activity. This output of the custom activity in Orchestrator (example server OS deployment) can be further used to actually deploy the infrastructure.

Overview of the overall Process flow of the example used in the build blog post:


The idea of the blog post on AuthoringFriday site was to explain how to read the Visio file and create the Integration Pack, but look at the possibilities you have with this kind of solution. Now these days a project starts and the architect creates a blueprint of the infra for the project in a Visio file. This file is evaluated and updated during the process where it “lands” with the guys that really have to install and configure the infrastructure. There this a manual activity here where people have to look rights and type that information on the left (or the other way around).

The process starts with your Visio template. In the MS Visio template you define what information needs to be specified for a successful provisioning. The example is using a *.vsd file, but this can be changed to any kind of provisioning you want to do. SharePoint sites, POC environment, and so on …. as long as your back-end can do the actual provisioning. The custom activity reads the information and based on this information, other activities can run and create the virtual machine or starts creating sites in your SharePoint environment.

Take this a bit further where you integrate System Center Service Manager in the whole Process. The Service Request is created via the self-service portal. Via the defined approval process, an Automated Runbook Activity is triggered where the file gets picked-up by Orchestrator. The Orchestrator runbook reads the Visio file information and starts building the requested infrastructure in a very automated way.


As you can read, the possibilities in automation with Orchestrator are end-less. If you need another input, it is just a matter of creating the code to read the file…follow a bit the creation if the IP as explained in the build blog post and you have your own input system to build further automation on.

If you like to “play” with the Visio OS deployment solution, I will post a download link of the Integration pack that is created at writing the AuthoringFriday blog post. 

Download link: (available soon)

Have fun and think about how you can automate your environment!

Kurt Van Hoecke