System Center 2012 SP1 - Orchestrator: Tools
We’re back with our look at System Center 2012 SP1 – Orchestrator. In my previous post, we looked at Microsoft Orchestrator’s components, and I introduced the different server components used to build out the service fabric. In this post we will focus on System Center 2012 SP1 – Orchestrator tools.
There are two tools provided with the Orchestrator product to manage and operate the environment: deployment manager and runbook designer. Both of these tools require that the Orchestrator management server is online and functional before they will connect, and the users must be a member of the relevant security groups with permissions to use the service. These tools connect to the management server and to the data store, so it is important that you allow traffic to pass across your firewall to these services if you have decided to deploy the tools remotely.
This environment management tool is used for three main tasks which enable a streamlined and maintainable control pane for managing Single Server Orchestrator environment to global distributed highly scaled implementations. The primary tasks addressed through the tool are:
- Deploying additional runbook servers to the environment
- Registering new integration packs with the management server
- Deploying the registered integration packs to both runbook servers and the Runbook Designers
Used to create, edit, manage, and maintain runbooks within the environment, the Runbook Designer presents a folder-based hierarchy to store and organize runbooks, as well as delegate access control to these resources. The Runbook Designer has two modes of operation, design mode and test mode.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Design mode: Runbooks are created and checked out to design mode, at which point the user has the ability to graphically draw on the design canvas through the use of activities and links in a Visio-esque experience. These workflow drawing represent the task that you wish to automate and can range from simple single activities to complex runbooks that can call other runbooks.
Test mode: While the runbooks are checked out to design mode, you will need to validate that the runtime behavior of the workflow is as you designed it prior to checking in the runbook and is ready to use. To assist with this process, the designer includes a runbook tester, which provides a PVR-style experience to step through each activity, view the link that is taken based on the results of the previous activity, and any values that are passed between these activities on their links (which is officially called the “pipeline“).
The runbook tester allows you to manipulate data presented on the links (pipeline), so that you can alter the values and influence the behaviors of the activities you are testing, as well as the links that might be activated as a result of this manipulation. While the runbook tester allows you to step over other runbooks that might be part of your workflow, it does not allow you to step into and debug these child runbooks in order to accomplish what you need to open additional instances of the runbook tester and debug each runbook in sequence.
Now that we have a good overview of the different components of Orchestrator, we are well placed to begin the exercise of deploying our first orchestration environment! Check back for more on this topic.