At each runbook you can configure Job Concurrency, default setting is “1”. The job concurrency setting lets you configure the maximum number of simultaneous jobs, for an individual runbook, so that you can carry out multiple requests for the same runbook at the same time. With the default setting of “1” only one instance of the runbook will run at the same time.

There are some scenario where you need to modify this setting, also a couple of scenario where you should not modify it. For example if you have a runbook working with a counter you should not have multiple runbooks instances running, as they will all affect the same counter. Another example are runbooks that starts with a Monitoring activity, they cannot run multiple instances. Before modifying this setting it is also important to look into what the runbook is doing, if the runbook for example creates a new unique computer name it sometimes will result with multiple computers with the same name.

I did a test with two runbooks, the first runbook trigger the second runbook. 5.1 trigger a new instance every 30 seconds, and invoke the 5.2 runbook. When 5.1 invoke runbook 5.2 it is also pass a timestamp to runbook 5.2. Runbook 5.2 writes the timestamp from runbook 5.1 and a new timestamp to a text file. Runbook 5.2 then sleeps for 3 minutes and ends.

As runbook 5.1 trigger a new instance of runbook 5.2 every 30 seconds, and runbook 5.2 only runs one instances at the same time, there will be a queue. You can check the queue with the following SQL query against your Orchestrator database

SELECT [Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.Id, [Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.ParentId,
[Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.ParentIsWaiting, [Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.StatusId,
[Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.CreationTime, POLICIES.Name, DATEDIFF(MINUTE,
[Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.CreationTime, GETUTCDATE()) AS QueueTime
FROM [Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs INNER JOIN
POLICIES ON [Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.RunbookId = POLICIES.UniqueID
WHERE ([Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.StatusId NOT LIKE ‘4’)
AND ([Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.StatusId NOT LIKE ‘3’)
AND ([Microsoft.SystemCenter.Orchestrator.Runtime.Internal].Jobs.StatusId NOT LIKE ‘2’)

This is a example of the result from the SQL query

• ID is the runbook job instance ID
• ParentID is the job that started this job. As you can see in the image all jobs have a parentID that starts with 45723… that is the 5.1 runbook, the runbook with the Invoke Runbook activity
• ParentIsWaiting is set to “1” if the runbook that trigger this job is waiting until this job is complete. When you configure a Invoke Runbook activity there is “Wait to completion” option, if you check it the parent runbook will wait until the runbook it trigger is completed
• StatusId is current stats of the job.
  • 0 = Pending
  • 1 = Running
  • 2 = Failed
  • 3 = Canceled
  • 4 = Completed
• CreationTime is when the job was created in the database
• Name is the name of the runbook running
• QueueTime is number of minutes between “NOW” and CreationTime, number of minutes it has been in pending state

Next image is an example of the log file that the 5.2 runbook writes to. As you can see the delay between the runbook was triggered and the time it executed is growing fast when only one runbook instance is allowed to run simultaneous.