In this chapter, we will cover the following recipes:

• Understanding the Orchestrator architecture
• Planning the Orchestrator deployment
• Installing a single server deployment
• Making the Orchestrator environment highly available
• Deploying an additional Runbook Server

Microsoft System Center 2016 Orchestrator (SCO) is a process automation and multitechnology product connection toolkit. It delivers the following two key challenges of an organization:

• The automation of manual repeatable tasks
• Connecting multiple IT vendor products

The first common IT challenge, the automation of manual repeatable tasks, when coupled with supporting organization policies, can significantly improve IT value and efficiency. The second challenge, connecting multiple IT vendor products, provides organizations with a single logical product SCO to interconnect and coordinate the activities between the typical multi-vendor technology investments.

In order to deliver the capabilities of SCO, we must unpack the product, our toolbox, by planning our deployment (what is the size, type, and the content of the toolbox) and installing the product based on our agreed deployment plan. This chapter focuses on the activities you must perform to have a fully functional SCO installation.

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

The author recommend you to review the latest information on SCO at https://technet.microsoft.com/en-us/library/hh420377(v=sc.12).aspx, as the documentation about the architecture of the product is regularly updated by Microsoft.

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:

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.

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.

The installation of SCO is simple. You must plan the deployment appropriately according to your needs. This recipe discusses and provides steps on common planning tasks to be performed before mounting the ISO for organizations who have successfully deployed SCO.

The authors recommend you to review the latest information on SCO at http://technet.microsoft.com/en-us/library/hh420383.aspx, as the requirements of the product and supported platforms are regularly updated by Microsoft.

There are three planning categories. They are: people, processes, and the technology (SCO product):

1. Identify and agree on the roles and responsibilities of the SCO team. SCO deployments typically have three types of users:
   • Services accounts: They perform actions for the specific components of SCO
   • Administrators: They will typically perform all the activities including, but not limited to, SCO installation, Runbook creation and management, and the delegation of security to operators
   • Operators: They will typically use the SCO console and the Runbook Designer to create and manage Runbooks
2. Identify and document initial prototype processes to be used as the first candidate for automation and testing. The types of processes for this purpose should be simple, repeatable tasks that fall into an organization's required standard service requests. Good candidates are service requests, which do not require authorization and approval. An additional example category is Windows operating system services that can be stopped and started as a part of troubleshooting.
3. Plan for the following technology requirements areas for SCO:
   • SCO deployment type:

The planning activities discussed are the minimum activities the authors recommend. The tasks performed at this stage will ensure that you ask and plan for all your requirements before investing time in the actual installation. An additional benefit is identifying any people or budgetary risks before the deployment.

There are two additional planning areas, which are typically ignored in technology-focused deployments. These areas are communication strategies and stakeholder management:

• The communication strategy: One of the inaccurate myths of SCO is that it would automate the IT professional. SCO, when implemented right, would improve efficiency, but will not replace people. On the contrary, you need to communicate with the people who perform the manual tasks, as they hold the key to how to best automate their efforts. Early engagement with all the IT team members should be one of your key planning tasks.
• The stakeholder management: Stakeholders are all users affected by the SCO deployment. An important category of stakeholders is the management team responsible for policy creation and enforcement. Automation without a good planned organization may lead to conflicts at the political level of your organization. An example of such a scenario is the ability to create Active Directory user accounts with rights to specific organization areas and restricted resources.

This recipe provides the steps required to install all the SCO roles on a single server. The single server deployment is appropriate for test and development environments. This deployment type will assist you with evaluation of the product, initial Runbook creation, and validation prior to deploying in your production environment. Though supported in production, you must plan to implement the multiserver deployment to provide flexibility and availability.

You must plan to review the Planning the Orchestrator deployment recipe before performing the steps in this recipe. There are a number of dependencies discussed in the planning tasks, which you must perform in order to be able to successfully complete the steps in this recipe.

The authors assume that you have access to all the installation media, and the user account performing the installation has administrative privileges on the server nominated for the SCO deployment.

The following figure provides a visual summary and order of the tasks you need to perform to complete this recipe:

The deployment will be implemented in an Active Directory environment and with the Windows Server 2016 operating system. Perform the following steps to deploy SCO on a single machine:

1. In Active Directory, create the required and recommended user accounts and groups. In this example we will create the following groups:
   • Users: SCO_MGTSVCA and SCO_RBSSVCA
   • Groups: SCO_ADMINS and SCO_CON_USERS
2. Install a supported Windows Server operating system, and join the server to the Active Directory domain in the scope of the SCO deployment.
3. Add the two services accounts and the SCO Administrators group to the local Administrators group on the SCO server.

4. On the SCO server, enable the following role and feature:
   • Role: Web Server (IIS) (default settings)—Note that the installation will enable this role for you if it is not found on the target server
   • Feature: .NET Framework 3.5 SP1—You must specify a source file for .NET Framework 3.5 SP1 in the case of Windows Server 2016, and ensure that the ISO for Windows Server 2016 is loaded
5. Optionally install Silverlight. After the SCO installation, you will be prompted to install Silverlight if you run the console on the server.
6. Install a supported version of Microsoft SQL Server. In our example, we will install Microsoft SQL Server 2016 standard edition. The following are the minimum options required for the installation:
   • Instance features: Database Engine Services
   • Share features: Management Tools—Basic
   • Collation: SQL_Latin1_General_CP1_CI_AS
   • Authentication Credentials: Windows Authentication (recommended)
7. Insert or mount the SCO installation media on the server. Login with a user account with administrative rights.
8. Launch the installation using the SetupOrchestrator.exe file. Click on Install under the System Center 2016 Orchestrator Setup section on the wizard page.
9. On the Product Registration page, enter your Organization details and the Product Key (although the product key can be entered post installation, it is a best practice to enter this during the installation to reduce the risk of product evaluation expiry after the default 180 day period). Click on Next.
10. Review the Please read this License Terms page, and accept to continue with the installation. Click on Next.
11. On the Select features to install wizard page, ensure all the options are checked. Click on Next.
12. On the Configure the service account page, type the user account you created for the Management Server service account and password. Click on Test to verify the details. Click on Next.
13. On the Configure the database server page, type the server name, and if applicable, the instance of SQL where the Orchestration database will be created. Click on Test Database Connection to verify the connection to the database server. Click on Next.

14. On the Configure the database page, ensure that New database is selected and the default name is Orchestrator for the database. Click on Next.
15. On the Configure Orchestrator users group page, click on Browse… , and specify the Active Directory group you created for the SCO administrators role (SCO_ADMINS in our example). Click on Next.
16. On the Configure the ports for the web services page, leave default options (81 and 82) or provide your custom options. Make sure you document the custom port if you change the default values. Click on Next.
17. On the Select the installation location page, accept the selected installation location or specify a custom location. Click on Next.
18. On the Microsoft Update page, select your preferred option. Click on Next.
19. On the Help improve Microsoft System Center Orchestrator page, select your preferred options. Click on Next.
20. Review the Installation summary page. Click on Install to start the installation.
21. On successful installation, you are presented with final configuration options as follows:
    • Launch Windows Update
    • Visit System Center Orchestrator Online
    • When Setup closes, start the Runbook Designer

This completes the installation steps.

Installing SCO in a single server deployment mode is very simple. The most important aspect is to plan and configure all the prerequisites before you start the actual installation.

The installation requires a number of options, which the wizard guides you throughout the process. The installation creates the Orchestration database and prepares it for use in your deployment. The account specified for the service account is granted the required permission in the database and on the local server.

The following screenshot shows the database permissions granted to the management server service account:

There is one additional configuration you must perform post installation on the Management Server.

Enabling network discovery is applicable to the Orchestrator database Runbook Designer role. Perform the following steps to enable network discovery:

1. In Control Panel, navigate to Network and Sharing | Change advanced sharing settings, and expand the domain profile and Turn on network discovery.
2. Click on Save changes.

Enabling network discovery enables the auto-population of fields, which requires the selection of a computer name when creating Runbooks.

The official online documentation is updated regularly and should be a point for reference at: https://docs.microsoft.com/en-us/system-center/orchestrator/learn-about-orchestrator.

SCO features and components can be installed on a single server or across multiple servers. All SCO components can be installed multiple times, except the Management Server. The Management Server and his SQL database can only exist a single time in an Orchestrator environment.

To understand the Orchestrator role, see the recipe, Understanding Orchestrator architecture, in this book.

If you would like to make your SCO environment highly available, prepare your server like you did it for the first Instance.

There are different ways for each feature to make them highly available. Runbooks Server, web service, the Orchestration console, and Runbook Designer can be installed multiple time in your environment. The Management Server feature is not that easy to make highly available. See next how to make each feature highly available.

Runbooks can be configured to run on a single Runbook Server or fallback to a different one, see recipe, Making your Runbook highly available, Chapter 4, Building Advanced Runbooks.

The Runbook Designer can be installed multiple times on a Server or client OS, as they are completely standalone and are used to connect to a Management Server.

The Orchestration console and web service can also be installed multiple times; you only need to take care about the web service URLs and make them highly available with DNS and SPN.

To make the Management Server highly available, you need to take care about the OS and the DB itself.

Here is a list about your options in this:

• Make the OS highly available, for example, as a VM on a cluster
• Take care of the SQL database also as a VM on a cluster

At the time this book has been written, it is not supported to run a System Center Orchestrator database on a SQL Always ON instance.

As you see, the Management Server is not that easy to be highly available, and it is a very important information. It's related to the SCO architecture, that all the information is stored in the database, so the DB is very important to to your complete SCO environment.

Check out the How to do it… section of the Planning the Orchestrator deployment recipe.

SCO features and components can be installed on a single server or across multiple servers. The multiserver deployment requires you to perform the installation in a specific order. The first server you must install is the Management Server, which requires a supported instance of Microsoft SQL Server. This recipe discusses the installation of the Runbook Server component. You need at least one Runbook Server in a multiserver deployment.

You must plan to review the Planning the Orchestrator deployment recipe before performing the steps in this recipe. There are a number of dependencies in the Planning the Orchestrator deployment recipe, which you must perform in order to successfully complete the tasks in this recipe.

The authors assume that you have access to all the installation media; and the user account performing the installation has administrative privileges on the server nominated for the SCO deployment. You must also install a Management Server before you can install the Runbook Server.

The example deployment in this recipe is based on the following configuration details:

• Management Server and database server called SVTGSCO01 is already installed
• The service account created in Active Directory: SCO_RBSSVCA

The following figure provides a visual summary and order of the tasks you need to perform to complete this recipe:

The deployment will be implemented in an Active Directory environment with the Windows Server 2016 operating system. Perform the following steps to deploy SCO Runbook Server in a multiserver deployment:

1. Install a supported Windows Server operating system, and join the server to the Active Directory domain in the scope of the SCO deployment.
2. Add the service accounts and SCO administrators group to the local administrator's group on the SCO Runbook Server.
3. On the SCO server, enable the .NET Framework 3.5 SP1 feature.
4. Insert or mount the SCO installation media on the server. Login with a user account with administrative rights.
5. Launch the installation using the SetupOrchestrator.exe file.

6. Turn on the splash screen under Standalone installations. Click on Runbook Server.
7. On the Product Registration page enter your Organization details and the Product Key. Click on Next.
8. Review the Please read this License Terms page and click accept to continue with the installation. Click on Next.
9. On the Configure the service account page, type the user account you created for the Runbook Server service account and password (in our scenario, SCO_RBSSVCA). Click on Test to verify the details. Click on Next.
10. On the Configure the database server page, type the server name, and if applicable, the instance of SQL where the Orchestration database is installed. Click on Next.
11. On the Configure the database page, ensure that Existing database is selected and the default name is Orchestrator , or your custom name for the database is selected. Click on Next.
12. On the Select the installation location page, accept the selected installation location or specify a custom location. Click on Next.
13. On the Microsoft Update page, select your preferred option. Click on Next.
14. On the Help improve Microsoft System Center Orchestrator page, select your preferred options. Click on Next.
15. Review the Installation summary page. Click on Install to start the installation.
16. On the successful installation, you are presented with final configuration options as follows:
    • Launch Windows Update
    • Visit System Center Orchestrator Online

This completes the installation steps for the SCO Management Server in the multiserver deployment.

The installation wizard guides you through the required settings. Once all the prerequisites are properly configured, the installation process installs the required program files for the Runbook Server feature.

The account specified for the service account is granted the required permission in the database. The following screenshot shows the database permissions granted to the Runbook Server service account:

The How it works… sections of the following recipes provide additional relevant information:

• Installing a single server deployment recipe
• Installing a Management Server in a multiserver deployment recipe