Book Image

Microsoft System Center 2016 Orchestrator Cookbook - Second Edition

By : Michael Seidl, Steve Beaumont, Samuel Erskine (EUR), Andreas Baumgarten
Book Image

Microsoft System Center 2016 Orchestrator Cookbook - Second Edition

By: Michael Seidl, Steve Beaumont, Samuel Erskine (EUR), Andreas Baumgarten

Overview of this book

With Microsoft System Center 2016 Orchestrator Cookbook, you will start by learning how to efficiently install and secure System Center Orchestrator. You will then learn how you can create configuration files for SCO 2016. After initial installation and configuration, you will soon be planning and creating functional and fault-tolerant System Center runbooks to automate daily tasks and routine operations. Next you will delve into runbooks; you will learn how to create powerful and advanced runbooks such as Building your Runbook without a Dead End. You will also learn to create simple and advanced runbooks for your daily tasks. Towards the end of the book, you will learn to use SCO for other interesting tasks and also learn to maintain and perform SCO health checks. By the end of the book, you will be able to automate your administrative tasks successfully with SCO.
Table of Contents (8 chapters)

Understanding the Orchestrator architecture

It is very important to understand the whole architecture of System Center Orchestrator before your start installing any of the SCO components.

Getting ready

How to do it…

The SCO architecture is made up of six types of components. The basic automated activity delivered by SCO is called a Runbook, which is commonly known as workflow in other products. The six components, which make up the SCO product are listed and described in the following table and are illustrated in the figure following the table:

SCO component


The Runbook Designer

The Runbook Designer is a tool used for creating and editing Runbooks. Runbooks are stored in the Orchestration database. A subcomponent of the Runbook Designer is called the Runbook Tester, which is used to validate the execution of Runbooks.

The Orchestration database

The Orchestration database is a Microsoft SQL Server database, which stores Runbooks, the statuses of Runbooks, and the security delegation configuration. The database also stores log files and the configuration of the SCO deployment.

The Management Server

The Management Server is the core communication component of the SCO architecture and is responsible for coordinating the communication between the Runbook Designer and the Orchestration database. There is only one Management Server per SCO deployment.

The Runbook Server

The Runbook Server is responsible for executing the instances of Runbooks. When a Runbook is invoked, a copy of the Runbook instance is sent to its assigned Runbook Server, and then it is executed (by default, this is the first installed Runbook Server, which is assigned the Primary role).

The Orchestrator web service

The Orchestrator web service is the interface that enables applications to connect to SCO. Typical tasks performed through the web service are Runbook status views, start, and stop actions.

The Orchestrator browser console

The Orchestrator browser console is a Silverlight supported web console, which uses the Orchestrator web service to communicate with SCO.

The six parts of SCO are illustrated in the following figure:

For the smallest implementation, all the components can be deployed to one server (physical or virtual). You have the option to scale out the deployment using multiple servers to host one or more components of SCO. The deployment choice is determined by the planning activities you perform before invoking the installation of the product. This recipe discusses the factors you must consider to assist with the deployment choice.

About the Management Server

At the time of writing, the current version of SCO supports only one instance of a Management Server per deployment. You can deploy multiple instances of the other parts of the product with a note that we are still dealing with just one database per Management Server. The database instance can be made highly available.

How it works...

The understanding of the SCO architecture is an essential task in order to be successful in automating your task. Before planning your deployment, make sure you understand the architecture and the components of SCO. Afterward, start planning your deployment as described in the recipe, Planning the Orchestrator deployment.