The architecture of Orchestrator is, at its base, quite simple and light. At the very beginning you'll find yourself in need of a multiple server Orchestrator deployment for performance and High Availability, and in the end, apart from the High Availability, you won't feel the need for a big Orchestrator infrastructure.

At this point, we'll address a single-server architecture with the database in a separate SQL cluster. For this, the requirements are as follows:

As you can see, the requirements for the Orchestrator architecture following a single-server deployment are not really that demanding. However, let's observe the requirements per component for a multi-server deployment:

Usually, the multi-server deployments are in fact connected to the High Availability questions, but keep with mind that the Management Server is a single component that can't be deployed in High Availability, even though the Runbook Servers are able to execute the Runbooks without that component.

On the Active Directory (AD) side, you'll need to also fulfill some requirements:

The next screenshot shows these accounts and groups in Active Directory, and in the end you should have something quite similar in your environment. The users and groups don't need to be named exactly the same as the examples we give here; they can be adapted to your standards, but keep these in mind for your reference for the rest of this book.

On the network side, we'll need the following exceptions on the firewall:

All the ports above can be configured to better suit your environment.

Now, in terms of the scalability of the Orchestrator, we can have redundancy in the Orchestrator Web Service / Console, Runbook Servers, and Orchestrator Database. However, we won't be able to have more than one Management Server.

You might consider having the components divided between servers due to service availability, but there's also the Runbooks workload expected and the number of simultaneous Runbooks that you'll have running to consider, as well as their importance.

Our advice would be to have one single-server deployed for the Runbooks development and preparation, and then for production, a redundant deployment of Runbook Server, Orchestrator Web Service / Console Server, and the Orchestrator Database under a SQL cluster. This way, you'll cover any need of simultaneously executing some Runbooks and High Availability.

Good! Now that we've defined all the requirements, and since all are in place, we'll do a sanity check so we can see if we're ready to go forward.

So, to move on to the next point, on installing the Orchestrator architecture you've decided to go with, you'll need to achieve the following steps:

Don't forget that some of the OS roles and features are only required for some of the Orchestrator components. Check the list to see which component needs which piece of software.

Also, it's not on this list, but we're assuming you have a SQL cluster or a single-server in place to accommodate your Orchestrator database. Don't forget the permissions on that SQL server for the account running the Management Server.

The OS roles and features prerequisites can all be installed using PowerShell in order to achieve a faster single-server deployment. In order to do so, you can execute the following command:

Import-Module ServerManager
Add-WindowsFeature NET-Framework-Core,NET-Framework-45-ASPNET,NET-WCF-Services45,NET-WCF-HTTP-Activation45,NET-WCF-TCP-PortSharing45,Web-Server,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Performance,Web-Stat-Compression,Web-Security,Web-Filtering,Web-Digest-Auth,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext,Web-Net-Ext45,Web-Asp-Net,Web-Asp-Net45,Web-CGI,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Mgmt-Tools,Web-Mgmt-Console –source D:\Sources\sxs