Designing a Runbook
Updated: May 13, 2016
Applies To: System Center 2012 SP1 - Orchestrator, System Center 2012 - Orchestrator, System Center 2012 R2 Orchestrator
When you plan a new runbook, you should start with a defined process that you want to automate. This process determines your choice of runbook activities. Specifically, determine the following:
When and how often is the runbook going to run?
What steps make up the workflow?
What activities reflect the steps in my workflow?
What type of data is required to begin the workflow?
What data are generated from each activity?
What results are produced at the end of the workflow?
How are the runbook results reported?
Consider the following points as you design your runbook:
Failure and Warning links - It is important to handle all results from an activity. An activity provides a default success string, but does not provide a default failure case. Consider if you should reverse an activity or write the result to a log file.
Replace the default strings - When you look at the workflow in a runbook, the labels should identify what the individual activities are doing. Rename links and activities labels to a descriptive name.
Link colors - Change the color of your links when there is a condition or branch. It is common to use GREEN as success and RED for warning or failed. You should use standard associations, but not use too many colors or you lose their descriptive purpose.
Limit the number of activities per runbook - Too many activities in a single runbook make it difficult to administer and troubleshoot. Consider splitting a runbook into several subtasks and create child runbooks for each of those subtasks. You can invoke the child runbooks from a parent runbook. You can reuse these child runbooks in other workflows.
Runbook logs - By default, logging options are disabled for runbooks. When you enable logging, the data significantly increases the size of your database. As an alternative, you can log to an external system or file.
See Also