This question comes up a lot: “What permissions are needed to trigger runbooks in System Center Orchestrator?” Sure, you can give all service accounts administrative permissions on all components and that would work somehow, but this is not really what you want to do because you lose control of your environment. Because this information is not available in any docs, me and one of our SCSM TAP customers put together all the permissions that need to be configured to make this thing running smoothly by using the minimum privileges. I hope this will make it to the next version of the SCSM docs somehow …

****************************************************
The complete SCSM SM12 (Beta) Series:
#1 – Service Level Objectives (SLO)
#2 – Service Requests
#3 – Automation of Service Requests
#4 – Enable Self-Service for Service Requests
#5 – Parent/Child Incidents
#6 – Release Management
#7 – Connectors
#8 – Permissions for triggering System Center Orchestrator runbooks
****************************************************

The SCO connector allows you to synchronize runbooks th SCSM and use them in Service Requests (or other requests). If you have no idea what I’m talking about, read this blog post. It describes the process of automating Service Requests by using SCO runbooks. That means that you need permissions to synchronize runbooks to SCSM and later permissions to trigger them as soon as the appropriate runbook automation activities become active. Also, the SCO Administrator has to take care that only runbooks can be synchronized to SCSM that are really needed.

Big Picture – Processes for this scenario

The first table shows the processes involved in runbook triggering.

Permissions in SCSM

The following permissions need to be configured in SCSM.

* This seems to be a problem with SCSM Beta and should be fixed in SCSM RC. Based on an information i got from Microsoft, it should be possible to only give this account read/write permissions on %windir%\temp. But I did not test this myself.

Permissions in SCO

The following permissions need to be configured in SCO.

Important notice 1

If the SCO connector in SCSM does not synchronize the complete runbook folder structure but only one or multiple sub folders, you must still give read and listpermissions on the top level folder (“Runbooks”) to make sure that the connector can traverse the folder structure.

Important notice 2

You can protect folders and/or runbooks by removing the list and read permissions. When configuring the SCO connector, these folders will be hidden and the containing runbooks will not be visible in SCSM nor synchronized. If needed you can create ADDS groups for all runbook folders and use them for giving permissions to the runbooks (the same way as in file system permissions). This way SCO admins can control which runbooks can be synchronized by SCSM.

Important notice 3

You can give publishpermissions only on those runbooks that SCSM needs to trigger. This way SCO admins can control which runbooks can be triggered by SCSM.

Important notice 4

When a runbook contains one or more child runbooks, you only have to give publishpermissions to the parent runbook (the one that is triggered by SCSM). Publish permissions for the child runbooks are not needed because they are triggered within SCO.

SCO Connector Configuration

This table describes the values for the SCO connector in SCSM.

That’s it. With all that information you should be able to configure runbook triggering in SCSM correctly without loosing control and security of your runbooks by giving too much permissions. Have fun trying out!

regards
Marcel