- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Orchestrator 2012 Overview
Orchestrator is made up of the Runbook Designer, where IT Pros create runbooks by dragging activities into the workspace, configuring and linking them, in a similar way to how Visio works. The Runbook Server is the central hub that runs the actual tasks, the Orchestration Console is a web based interface that tracks the execution of runbooks and the new web service lets you access Orchestrator functionality from other programs. The Deployment Manager is used for registering Integration Packs (IPs) as well as deploying them to your runbook servers.
The Orchestration Console, for checking on Runbooks and their statistics as well as executing of runbooks by non-administrators.
Orchestrator caters for different roles of people in IT organizations; IT Professionals will spend their time in the Runbook Designer (known as the Operator Client in Opalis) creating workflows whereas IT Managers will visit the Orchestration web console (known as the Operator Console in Opalis) to check statistics on how the runbooks (known as Policies in Opalis) are performing. Certain end users might approach Orchestrator as a one button “fix” for something – running a clean-up job in an ERP system for example– again through the Orchestration console. Developers on the other hand use the Orchestrator Integration Toolkit (known as the Quick Integration Kit, QIK, in Opalis) to create custom activities and Integration Packs to integrate with other systems.
Orchestrator lets you connect to web services and systems across platforms and then execute system level tasks in those systems or execute scripts (PowerShell, .NET, Jscript, VB etc) and then communicate results via email or published notifications.
Scalability for Orchestrator is difficult to gauge, the overall rule is that if you expect to have more than 50 runbooks executing concurrently, you need another server as the jobs will queue up. You can create a very processor and memory intensive runbook with only a few activities or a very light runbook with many complex tasks involved, it all depends on exactly what the runbook does. Specific runbooks can be assigned to a particular server if necessary. As your IT team come to rely more and more on Orchestrator you’ll definitely want to add more Runbook servers (called Action servers in Opalis) to provide availability. When a Runbook server is unavailable, runbooks will automatically run on the next available server.
There’s a bit of overlap between the Service Manager 2012 (SCSM) and Orchestrator 2012 products but the way to understand the difference is that SCSM is all about automating and standardizing business processes whereas Orchestrator is about IT processes and workflows.
Installation of Orchestrator 2012
You need a machine with at least 1 GB of memory, 2 GB or more is recommended, with a dual core CPU, and at least 200 MB of free disk space. All components require Windows Server 2008 R2; you also need to have IIS (for the Orchestration Console); the install program can enable this automatically, along with .NET Framework 3.5 SP1. You also need to install .NET Framework 4. Orchestrator requires a SQL 2008 R2 database, either local or remote. Finally the Orchestration Console relies on Silverlight 4 which you’ll be asked to install the first time you open the Console if it’s not installed. The Runbook Designer can be installed on a Windows 7 client as well as on the server.
As in the other System Center 2012 installers, Orchestrator comes with a pre-requisite checker and a simple installer that makes installation a snap.
For old hands with Opalis 6.3 the installation is a lot smoother, compared to the many steps involved in downloading the Java components / JBoss for the Opalis installation. If you already have Opalis in your environment the “upgrade” to Orchestrator 2012 is a matter of exporting your runbooks from Opalis and importing them into Orchestrator.
In this second part of five in the overview of Orchestrator 2012 we looked at the components of Orchestrator and the installation experience. In part three we’ll look at the steps involved in creating Runbooks.
