System Center Orchestrator 2016 is fairly easy to setup and deploy but so many organisations havent installed or configured it which is shocking given its part of the System Center Suite.
Ok, but what actually is it? Well, if you think about the most common IT challenge, the continued processing of manual repeatable tasks coupled with supporting organizational policies and change control then automation can significantly improve value and efficiency. Sounds awesome yes? It is. The second challenge is connecting multiple IT vendor products and systems, if this is done correctly then it gives organizations a single logical product (SCORCH) to interconnect and coordinate the activities between the typical multi-vendor technology investments. In order to deliver these capabilities, SCORCH is the toolbox.
So in a nutshell it connects things together as we will see in this series of posts.
Terminology
Terminology
This may be new to you so before we start we will go through some terminology: (The items highlighted in red are infrastructure ie. Servers, Installed Components)
Term | Definition |
Activity | A single task in a runbook that performs a specific function |
Check In | To save the changes in a runbook to the database. |
Check Out | To allow edits to a runbook |
Counter | A global integer variable that is used in a runbook. |
Data Bus | A mechanism in Orchestrator that passes information from one activity in a runbook to another activity. |
Deployment Manager | Tool used to deploy Orchestrator components (eg Runbook Servers, Designer) and integration Packs |
Instance | A unique occurrence of a runbook that is running on a runbook server. |
Integration Pack | A collection of custom activities that is specific to a product or a technology. |
Job | A request to run a runbook. |
Junction | A runbook activity that synchronizes multiple branches of a runbook. |
Management Server | The communication layer between the Runbook Designer and the deployment manager to the database. |
Monitor | An activity that continuously runs and that initiates a runbook when the monitor matches the criteria that you specify. |
Orchestration Console | A Silverlight based console that you can use to start, stop, and view information about runbooks. (Port 82) |
Orchestration Database | The SQL Server database where configuration information, runbooks, and logs are stored. |
Orchestrator Integration Toolkit | A set of software tools that you can use to create custom integration packs. |
Orchestrator Web Service | REST-based service that enables custom applications to connect o Orchestrator. Console uses this web service to interact with Orchestrator (Port 81) |
Published Data | The data that is published to the databus from each activity in a runbook. |
Runbook | The sequence of activities that orchestrate actions on computers and networks. |
Runbook Designer | The tool that is used by designers to create, modify, and deploy runbooks. |
Runbook Server | The server that runs the service that manages runbooks and communicates with the orchestration database. |
Runbook Tester | The tool that is used to test and validate the execution of Runbooks |
Schedule | The global settings that you can use to define a set of date and time criteria for a runbook. |
Smart Link | The connection between two activities in a runbook. |
Standard Activity | The set of activities that is included with the standard installation of Orchestrator. |
Subscribe | To request data from the data bus. |
Variable | A global value that is used to define a frequently used setting, such as a directory path to common files or server names. |
Deployment Types
Single Server:
All Orchestrator roles are installed on one physical or virtual machine. This scenario is typically implemented in test/labs/dev environments but is fully supported in production. However, this is a single point of failure for highly automated environments. This is the deployment I will be going through in this series of articles.
Multi Server:
The Orchestrator roles are separated and installed on one or more machines for redundancy.
- Datastore (SQL)
- Central to Orchestrator functionality
- HA / SQL AlwaysOn recommended
- Runbook Server
- Deploy multiple Runbook Servers to provide redundancy
- Failover is automatic when multiple Runbook Servers are present
- Runbooks
- Perform exports periodically as a backup method
- Error handling and redundancy can be added at the object limit within Runbooks
- Other Components
- Designer, Licence manager, Deployment Manager and Operator Console are design time components and do not require redundancy
The following diagram shows the communication between the different server components:
All Server Roles Hardware:
- 2.1Ghz Dual Core CPU
- 2 Gb Memory (Minimum)
- 200Mb Disk Space
Operating Systems:
- Server 2012 R2 Standard / Datacenter
- Server 2016 Standard / Datacenter (With Desktop Experience)
Runbook Designer for Client Machines:
- Only Windows 10 is supported
SQL Server (64 Bit only):
- SQL 2012 SP2 Standard & Enterprise
- SQL 2014 Standard & Enterprise
- SQL 2014 SP1 Standard & Enterprise
- SQL 2014 SP2 Standard & Enterprise
- SQL 2016 Standard & Enterprise
For those of you interested how the Database need Sizing and the performance see this article https://technet.microsoft.com/en-us/library/jj218323.aspx
Service Accounts:
By default there are 2 service accounts:
Management Server Account
- Maintaining database, communicating with designers and deployment manager
- Permission to log onto the Mangement Server as a Service
- Member of admin role in Orchestrator database
- Can be a local or domain account
- Does not have to be an Administrator / Domain Admin account
Runbook Server Account
- Runs Runbook Server and communicates with the database
- Recommended to be a domain account
- By default, all activities run under this account, but can be configured differently on specific activities
- Permission to log on to the Runbook server as a service
- May require additional permissions depending on activities
In this series of posts I will use the following accounts:
- Srv-ORC – SCORCH Mgmt, Runbook, and Monitor Account
- “Orchestrator Users” – SCORCH users security global group
- Srv-SQL – SQL Service Account
Add the domain user accounts for yourself and your team to the “Orchestrator Users” group
Ports
The following ports are used for communication
Source | Target Server | Default Port | Configurable | Notes |
Runbook Designer | Management Server | 135, 1024-65535 | Yes | Runbook Designer communicates with management server over DCOM (Default Port 135) and dynamically allocates a port between 1024 and 65535 |
Management Server Runbook Server Web Service | Orchestration Database | 1433 | Yes | Specified during the SQL installation |
Client Browser | Orchestrator REST-based web service
Orchestration Console
| 81
82
| Yes
Yes
| Specified during Orchestrator Installation. Both ports must be accessible for the Orchestration console. |
Installation
Now we have a little background information we can now proceed with the installation.
Ensure you have setup a Server 2012 R2 or Server 2016 server and it is joined to the domain.
We require the following prerequistes:
- Microsoft Internet Information Services (IIS) – Orchestrator Setup enables IIS if it is not enabled.
- Microsoft .NET Framework 3.5 Service Pack 1 – Orchestrator Setup installs and enables (Note: NET 3.5 source files are removed from the WS2012 R2 / 2016 Operating Systems. Therefore you need to supply a source path to the installation media that you should mount inside the VM)
- Microsoft .NET Framework 4.5 (including WCF HTTP Activation)
Log on and open PowerShell and run the following script:
Install-WindowsFeature NET-Framework-Core, NET-Framework-45-Core, NET-WCF-HTTP-Activation45 -source d:\sources\sxs
Now Add the “Srv-ORC” and the “Orchestrator Users” to the Local Administrators group on the Orchestrator server.
This guide assumes you have installed SQL as required in your environment either a single server or AlwaysOn. However you should note it must setup with the SQL_Latin1_General_CP1_CI_AS collation.
Log on using a domain user account that is a member of the “Orchestrator Users” group and a local admin on the server.
Run SetupOrchestrator.exe from your installation media.
Click Install
Supply a name, org, and license key (if you have one) and click Next. If you don’t input a license key it will install Eval version.
Accept the license agreement and click Next.
On the Diagnostic and Usage data click Next.
Check all boxes on the getting started screen, for:
- Management Server
- Runbook Server
- Orchestration Console and Web Service
- Runbook Designer
On the Prerequisites screen, check the boxes to activate/remediate any necessary prerequisites (such as IIS and .NET), and click Next when all prerequisites are installed.
The warning below is due to this just being a lab environment
Input the service account “Srv-ORC” and input the password, domain, and click Test. Ensure this is a success and click Next.
Configure the database server. Type in the SQL server name (and instance if using a named instance) to which you have the “System Administrator” (SA) rights to in order to create the Orchestrator database and assign permissions to it. Test the database connection and click Next.
Specify a new database, Orchestrator. Click Next.
Browse AD and select your domain global group for “Orchestrator users”. Click Next.
Accept defaults for the SCORCH Web service ports of 81 and 82, Click Next.
Accept default location for install and Click Next.
Select the option you require to send error information back to Microsoft.
Select the appropriate options for Microsoft Update, Customer Experience and Error reporting. Click Next.
Click Install.
Setup will install all roles, create the Orchestrator database, and complete very quickly.
Uncheck the boxes and click close.
Now you need to update to Update Rollup 1 (as of the time of writing). https://support.microsoft.com/en-us/kb/3190603
Once the updates are complete open the Runbook Designer and that’s it! In the next article we will look at the installation of Integration Packs.
No comments:
Post a Comment