- The History of Orchestrator
- OIS 6.3 Versus Orchestrator 2012
- Summary
OIS 6.3 Versus Orchestrator 2012
On the surface, certain areas of Orchestrator 2012 appear to differ greatly from the OIS 6.3 release, but the underlying concepts and processes remain relatively the same. All user interfaces have had facelifts, and the OIS Operator Console has been completely rebuilt from scratch.
The next sections discuss these changes and include a brief overview of the features that were improved or rebuilt. Additional detail about each of these features and their uses and configuration options is available in Chapter 3, “Looking Inside System Center 2012 Orchestrator,” and Chapter 4, “Architectural Design.”
Terminology Changes
Thanks to rebranding and the Microsoft acquisition, several terms have changed between OIS 6.3 and Orchestrator, but much parity exists between the legacy and the new Orchestrator features. Some pieces, such as the License Manager, were removed altogether; others, such as the Orchestration console, were rebuilt from the ground up. In general, however, the interfaces and features in Orchestrator should be familiar if you have used OIS 6.3. Table 2.1 lists the terminology changes within the architecture features.
TABLE 2.1 Feature Terminology Changes
OIS 6.3 |
Orchestrator 2012 |
SQL Data Store |
Orchestrator Database |
Opalis Management Server |
Orchestrator Management Server |
Opalis Action Server |
Orchestrator Runbook Server |
OIS Client (Authoring Console) |
Runbook Designer |
Policy Testing Console |
Runbook Tester |
OIS Operator Console |
Orchestration Console |
Deployment Manager |
Deployment Manager |
OIS Web Service (WSDL) |
Orchestrator Web Service |
Database Configuration Utility |
Data Store Configuration |
License Manager |
— |
Orchestrator Database
A Microsoft SQL Server database stores all data and configurations. This database is a critical feature and should be configured for high availability. If the SQL Server goes down, runbook servers cannot execute any runbooks. Orchestrator uses one database with a default name of Orchestrator and a correlation of SQL_Latin1_General_CP1_CI_AS.
Orchestrator Management Server
The management server exists primarily to establish communication between the design features and the SQL database. It is not a critical runtime feature and does not necessarily need to be highly available. This feature fills the same role as the OIS management server in the previous release.
Orchestrator Runbook Server
The Orchestrator runbook server is the feature that actually executes runbooks. You can deploy multiple runbook servers to allow for load balancing. This feature handles the same responsibilities as the action server in the previous release.
Runbook Designer
The Runbook Designer console is used to design, test, and implement all runbooks. This feature is not critical to the operation of existing runbooks and, therefore, does not necessarily need to be highly available. This feature is essentially the same as the OIS 6.3 Client.
Runbook Tester
The Runbook Tester, which is launched within the Runbook Designer, has a similar function and layout to the OIS 6.3 Policy Testing console. This tool is used to test runbooks before deployment and publishes runtime data about each activity as the runbook steps through from beginning to end.
Orchestration Console
This console, displayed in Figure 2.7, provides IT operators with a thin-client interface into Orchestrator. The Orchestration console is not critical to the runtime of runbooks, but it enables users to view the state of runbook execution, start and stop jobs, view running and pending instances in real time, and review the execution history of runbook instances. The Orchestration console supersedes the OIS 6.3 Operator Console, and although the underlying technology has changed significantly, it serves the same purpose.
FIGURE 2.7 The Orchestration console.
Deployment Manager
The Deployment Manager is largely unchanged from OIS 6.3 and is used to deploy runbook servers, IPs, and runbook designers. Figure 2.8 shows the Deployment Manager managing integration packs.
FIGURE 2.8 Orchestrator Deployment Manager.
Orchestrator Web Service
The Orchestrator web service allows for programmatic access to Orchestrator. In addition to providing access for the Orchestration console, this web service uses REST and ODATA standards to make it easier for developers to integrate their programs with Orchestrator.
Data Store Configuration
This utility supersedes the OIS 6.3 Database Configuration Utility and is used to configure the database server and the database itself (see Figure 2.9).
FIGURE 2.9 Orchestrator Data Store Configuration details.
Services
Services have undergone a makeover as well. Table 2.2 lists these changes.
TABLE 2.2 Services Terminology Changes
Opalis 6.3 |
Orchestrator 2012 |
Opalis Remote Execution Service |
Orchestrator Run Program Service |
OpalisActionServerWatchdog |
Orchestrator Runbook Server Monitor |
OpalisActionService |
Orchestrator Runbook Service |
Opalis Management Service |
Orchestrator Management Service |
OpalisRemotingService |
Orchestrator Remoting Service |
Other Terminology Changes
Other terminology changes relate to the user interface, detailed in Table 2.3. The following sections focus on these.
TABLE 2.3 User Interface Terminology Changes
OIS 6.3 |
Orchestrator 2012 |
Custom Start |
Initialize Data |
Foundation Object |
Standard Activity |
Object |
Activity |
Object Palette |
Activities Pane |
Policy |
Runbook |
Policy Folder |
Runbook Folder |
Policy Module |
Job Process |
Publish Policy Data |
Published Data |
Request |
Job |
Trigger Policy |
Invoke Runbook |
Workflow Control |
Runbook Control |
Activity
Activity is synonymous with object in OIS 6.3: It refers to the tasks dragged and dropped in the Runbook Designer to build runbooks.
Standard Activity
Standard activities are all activities that are available in an out-of-the-box installation; they exclude activities provided by integration packs. These standard activities are sorted into different categories, based on their function. An example of these categories is Runbook Control. Chapter 7, “Runbook Basics,” discusses categories for standard activities.
Initialize Data
The Initialize Data activity is just a name change from the OIS Custom Start object, and operates in a similar way. It allows a runbook to gather user-defined input parameters. This enables runtime values to be gathered via the Orchestration console or through an interface utilizing the web service, such as the Service Manager self-service portal.
Activities Pane
The Activities pane is the pane on the right side of the Runbook Designer that holds all the activities that can be used to build a runbook. Figure 2.10 shows the Activities pane, with some optional integration packs.
FIGURE 2.10 The Activities pane in the Runbook Designer.
Runbook
A runbook is synonymous with a policy in OIS 6.3: It is the collection of activities that orchestrates actions.
Runbook Folder
Runbook Folder replaces the legacy term Policy Folder. These folders contain one or more runbooks and are used to organize runbooks in both the Orchestration console and the Runbook Designer.
Job
A job is a request to run a specific runbook that is waiting to be assigned to a runbook server for processing. These runbooks are assigned first come, first served.
Job Process
A job process is the actual process that executes on the runbook server that executes an instance of a job.
Published Data
When activities run, data is collected. This includes the output of the activity, the time it ran, and whether it was successful. The information is placed in the pipeline data bus. This data can be referenced by another activity farther down the line in the runbook. Referred to as published data, this data was known as published policy data in OIS 6.3. Figure 2.11 shows some common published data from the Compare Values activity.
FIGURE 2.11 Viewing published data.
Job
A job is a request to deploy and run a runbook on a runbook server. You can monitor jobs in the Orchestration console, previously shown in Figure 2.7. A job identifies the runbook but does not uniquely identify each specific occurrence of that runbook’s execution.
Jobs can deploy a runbook to multiple runbook servers or can run multiple occurrences of the same runbook on a single runbook server. These occurrences, referred to as instances, enable you to uniquely identify each specific occurrence. For example, a System Center Operations Manager alert can trigger an Orchestrator runbook. If Operations Manager sends three alerts that are the same, the job is the request to run a runbook each time that alert is generated. The instance uniquely identifies each execution of that runbook and enables you to view data about that specific occurrence, such as the time it started and what data it generated.
Invoke Runbook
This activity resides in the Runbook Control category and replaces the OIS legacy Trigger Policy object. It allows another runbook to be called from within a runbook. A related activity, Return Data, enables you to send back the data generated by the invoked runbook to the Invoke Runbook activity. This powerful pair of activities plays a big part in more complex multipart runbooks.
Runbook Control
This activity category replaces the old Workflow Control category and contains activities that are used to control the behavior of runbooks.
Concept Changes
Conceptually, Orchestrator has not changed much from OIS 6.3. General practices and ideas still apply, and your OIS policies largely still function in Orchestrator as runbooks. If anything, greater emphasis has been placed on the power of Orchestrator’s integration with the other System Center components.
Microsoft provides updated IPs for the System Center 2012 components that leverage some of the new features and functionality in those other products. It is also worth noting that the IPs for the legacy System Center products have been updated to work with Orchestrator because the Opalis Integration Server IPs are not compatible with Orchestrator.
Previous versions required that you monitor an application for a certain event to occur in order to trigger a runbook, thus the monitor was a passive monitor. For this passive monitoring system to work reliably, the data being monitored had to be consistent enough to trigger the correct runbooks at the right time. System Center 2012 Orchestrator does not need to monitor events in external applications to trigger runbooks. Runbooks can be triggered via the web service; using integration with other applications or the System Center 2012 Service Manager component can eliminate unnecessary development efforts and issues from data inconsistencies. Chapter 6 explains this integration in more detail.
Architecture and Feature Changes
The architecture for Orchestrator remains largely unchanged from OIS 6.3, aside from some new terminology and prerequisite changes (see Table 2.4). As Figure 2.12 shows and Chapter 3 explores further, the SQL database is still at the heart of Orchestrator. A familiar set of features operates around that SQL database.
TABLE 2.4 Single Server Prerequisite Changes
Feature |
Opalis 6.3 |
Orchestrator 2012 |
Processor |
2.1 GHz dual-core Xeon 3000 series or equivalent |
2.1 GHz dual-core Intel microprocessor or better |
Memory |
2GB |
1GB |
Hard Disk |
381MB |
200MB |
Operating System Roles and Features |
Windows Server 2003 SP2 or later |
Windows Server 2008 R2 or Windows Server 2012 with System Center 2012 Service Pack (SP) 1, IIS, .NET Framework 3.5.1 and .NET Framework 4 |
Database Server |
SQL Server 2005 or 2008 |
SQL Server 2008 R2 or SQL Server 2012 with System Center 2012 SP 1, using SQL_Latin1_General_CP1_CI_AS collation |
FIGURE 2.12 Architectural diagram.
Prerequisite/Sizing Changes
As is typical with newly released Microsoft software, hardware and software prerequisites have been updated.
These changes should not necessarily be considered upgrade prerequisites—as stated earlier in the “OIS Migration to Orchestrator” section, no upgrade path from OIS to Orchestrator exists. Chapter 5 discusses this further.
Apart from these relatively minor changes, the Orchestration console has been rebuilt and thus has different requirements. The old Operator Console required JavaScript on the accessing browsers and Java parts on the web server hosting the console. The new Orchestration console requires Silverlight on accessing browsers.
Sizing and performance guidance has stayed consistent with this new release. The management server is still limited to one per environment, is needed only to connect the Runbook Designer, and does not need to be highly available. The database and runbook servers are the features required for runbooks to execute. Each runbook server is limited by default to 50 runbooks per runbook server. If you are using Service Manager with the Orchestrator connector, you will want the Orchestrator web service to be highly available as well.
Licensing Changes
Microsoft has done a considerable amount of work to simplify the license options for System Center 2012 into an easy-to-understand processor-based licensing model. All the components of System Center 2012 have been consolidated into a single SKU, so purchasing either license offering gives you access to every component. Two editions are available; the only difference between the two is in the number of managed OSEs allowed per license (see Table 2.5).
TABLE 2.5 Licensing Changes
License Offering |
Components Included |
Components Included |
System Center 2012 Datacenter Edition |
App Controller Configuration Manager |
Configuration Manager Configuration Manager |
System Center 2012 Standard Edition |
Data Protection Manager Endpoint Protection Operations Manager Orchestrator Virtual Machine Manager |
2 per license on premises,2 in public cloud |
System Center Advisor, which offers configuration monitoring cloud services for Microsoft server products, is offered at no cost to users of those products. For information on Advisor, see http://blogs.technet.com/b/momteam/archive/2013/03/06/system-center-advisor.aspx and https://www.systemcenteradvisor.com/.