In this part of Orchestrator 2012 RunBook Concepts series, let’s cover how to test, save and run your existing RunBooks.
For the first two parts:
Part 1: http://blogs.technet.com/b/meamcs/archive/2012/03/06/system-center-2012-orchestrator-runbook-basics.aspx
Part 2: http://blogs.technet.com/b/meamcs/archive/2012/03/09/system-center-2012-orchestrator-runbook-activities.aspx
Part 4: http://blogs.technet.com/b/meamcs/archive/2012/04/09/system-center-2012-orchestrator-link-conditions.aspx
In RunBook Designer console, on the top bar you’ll notice three button:
Check Out: To be able to edit an existing RunBook, it must be checked out. Main purpose for that action is to prevent concurrent editing of same RunBook by different users.
If someone else is already editing RunBook, you will notice a pop-up window informing that someone is already editing RunBook.
Check In:After you finish your editing, you can Check In RunBook and so that all your changes will be committed. And also other users can then edit RunBook.
Undo Check Out: If you click Undo Check Out button when editing the RunBook, all changes you made are reverted.
Before you run Runbooks, you can test it with RunBook Tester and also easily debug each activity or entire RunBook. This is especially helpful for troubleshooting issues. But don’t be confused about terms, RunBook Tester will apply each activity changes to your current environment, that means it will not use a demo or isolated env.
Please also note that tester runs in the currently logged user context. Orchestrator Service account will not be used for testing purposes. So it would be better to open RunBook Tester as Administrator with high-level security token.
When you click RunBook Tester from the toolbar, Tester starts and loads relevant RunBook
RunBook tester interface consists of five panes;
Run Time Properties:This is one of the mostly used pane. It displays resolved published data items. It’s important because if you use several published items for activities, you may want to see what data is carried between activities. Best way to see them in a clear way is RunBook Tester.
Design Time Properties: Displays design-time information for each activity. This is same with Activity details page.
Workspace: Displays active current Runbook. You can set a breakpoint for each activity.
Breakpoint will be marked with a red round on activity and tester will stop on it.
Log: Displays detailed information for each activity.
You can expand each entry to show details.
Resource Browser: Displays the counters, variables, computer groups and schedules.
You can predefine each of them and make available for all RunBooks.
Computers Groups and global items can be added within Connections Node.
Lets add a computer set to use it within activities.
Now you can use Computer Group within an activity;
This activity will be performed for all computers which members of previously created Computer Group.
You can start your test with different options;
Step Through: Runbook starts with first activity and after completion, it waits for your input. You can click Step button to move one step forward. So you can view design time properties for each activity easily.
Waits for my next click..
To start a RunBook, firstly you must click Check In button to commit changes. Then just navigate related Runbook tab and click Run.
To stop, just click Stop button on the Toolbar. You can track activity’s success&failure progress on Log Pane;
All related events will be logged under Events Pane;
Also to track RunBook changes, In the RunBook Designer, select Audit History tab at the bottom and click individual items.
This is important if there are multiple Runbook designer users in your environment. You can track each Runbook change easily within Audit History.
Next part we’ll cover how to design basic and complex Runbooks.
Great series Anil, keep goin.
Please cover designing comlex runbooks
Great series Anil, do they have a active forum for orchestrator yet? I have some questions about some of the activities.
There is a Orchestrator Technet Forum :