This chapter will target the goal of having a proper Microsoft System Center Orchestrator 2012 R2 (SCORCH or Orchestrator) architecture in place. We're going to cover the Orchestrator components, their capability to be scalable, and their requirement to better address the question of the design to be chosen. By the end of this chapter, you will be able to identify what requirements you should keep in mind and assess before drawing or implementing Orchestrator.
Microsoft System Center Orchestrator 2012 R2 is a workflow automation product that interconnects with multiple technologies. With Orchestrator, you can target the following points in your datacenter:
Automation of repeated tasks (either system or manually triggered)
Interaction between products
The expected result of the automation of repeated tasks is for the administrative workload to be reduced, thereby improving the quality and performance of the IT staff and also improving on the datacenter dynamics.
In this opening chapter, we will address the following points:
Planning the Orchestrator architecture and deployment
Deploying a single-server solution
Deploying a multiple server solution
To better understand Orchestrator, we need to know the basics of it. We can start off with the fact that it has seven components. The automated workflow is called a Runbook. The seven components are as follows:
Management Server: This component coordinates the communication in the Orchestrator architecture between all the other components and it cannot be redundant as there can be only one Management Server per Orchestrator deployment.
Orchestrator Database: As the name suggests, this is composed of a database that will be stored in a Microsoft SQL Server, and it will keep all the Runbooks in it, the status of those Runbooks, and keep the security delegation in place.
Runbook Server: This is the component responsible for executing the Runbooks instances. When a Runbook is invoked, a copy of it is transmitted from the database into the Runbook Server, and then it's executed. The first Runbook Server to get installed gets the primary role.
Runbook Designer: This component is the interface between you and the Orchestrator engine for creating the Runbooks. It has a subcomponent called Runbook Tester for you to use in order to validate the Runbooks you create.
Orchestrator Console: This is a console that runs on Silverlight that uses the Orchestrator Web Service to communicate with Orchestrator.
Orchestrator Web Service: This is the interface that allows applications to connect with Orchestrator and allows them to perform tasks through it, such as starting and stopping Runbooks, or viewing the status.
Orchestrator Deployment Manager: The Deployment Manager is a tool used to deploy Integration Packs (IPs), Runbook servers, and Runbook Designers. This is a subcomponent of the Management Server.
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:
RAM: 1 GB (recommended 2 GB)
Disk: 200 MB (available disk space)
CPU: Dual-core Intel CPU, 2.1 Ghz (or above)
OS: Windows Server 2008 R2 (with IIS, .NET 3.5 SP1, .NET 4.5, and Silverlight) or above
SQL Server: Microsoft SQL Server 2008 R2 or above (with Collation:
SQL_Latin1_General_CP1_CI_ASand Database Engine Service only)
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:
Management server:
RAM: 1 GB (recommended 2 GB)
Disk: 200 MB (available disk space)
CPU: Dual-core Intel CPU, 2.1 Ghz or above
OS: Windows Server 2008 R2 (.NET 3.5 SP1) or above
Orchestrator database:
SQL Server: Microsoft SQL Server 2008 R2 or above
Collation:
SQL_Latin1_General_CP1_CI_ASSQL Roles: Database Engine
Location: Local or Remote (cluster supported)
Runbook server:
RAM: 1 GB (recommended 2 GB)
Disk: 200 MB (available disk space)
CPU: Dual-core Intel CPU, 2.1 Ghz or above
OS: Windows Server 2008 R2 (.NET 3.5 SP1) or above
Runbook designer:
RAM: 1 GB (recommended 2 GB)
Disk: 200 MB (available disk space)
CPU: Dual-core Intel CPU, 2.1 Ghz or above
OS: Windows Server 2008 R2, Windows 7 SP1 or above
Orchestration console / Web service server:
RAM: 1 GB (recommended 2 GB)
Disk: 200 MB (available disk space)
CPU: Dual-core Intel CPU, 2.1 Ghz or above
OS: Windows Server 2008 R2 (.NET 3.5 SP1, .NET 4.5, IIS, Silverlight) or above
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:
|
User/Group |
Name |
Type |
Comments |
|---|---|---|---|
|
User |
DOMAIN |
Service account |
This is the main management server's service account and it will be granted a logon as a service during the installation. It is also used for the Monitor service. |
|
User |
DOMAIN |
Service account |
This is the account used for accessing resources that are specified on the Runbooks. This account might require access to remote computers. |
|
Group |
DOMAIN |
Group |
Users Security Global Group for allowing default access to Orchestrator |
|
Group |
DOMAIN |
Group |
Operators Security Group to allow access as the Runbook operator on Orchestrator |
|
Group |
DOMAIN |
Group |
This is the Full Administration Security Group for Orchestrator |
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:
|
Source |
Target |
Default Port (TCP) |
Notes |
|---|---|---|---|
|
Runbook Designer |
Management Server |
135, 1024-65535 |
The Runbook Designer communicates with the management server over DCOM; by default, the DCOM uses port 135 to initiate the connection and then moves to a dynamic port between 1024 and 65535. |
|
Management Server / Runbook Server / Web Service |
Orchestration Database |
1433 |
This takes care of the Microsoft SQL Server connectivity. |
|
Client Browser |
Orchestrator REST-based web service |
81 |
These are ports used for connecting to the Orchestration console. |
|
Orchestration console |
82 |
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:
Create Active Directory accounts:
Service accounts
AD groups
Install an operating system:
Windows Server (2008 R2 or above)
Add it to the domain
Add service accounts to the administrator's local group
Add the Orchestrator administrators group to the administrator's local group
Configure OS roles and features:
IIS
.NET 3.5 SP1
.NET 4.5
Silverlight
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
As discussed in the previous section, we can use a single-server to host all the components of Orchestrator if we're targeting a small environment and/or we have the objective of having an Orchestrator for the development and quality assessment of our Runbooks before getting them into production. If you jumped straight into this part, we strongly suggest you read the Planning the Orchestrator architecture section before proceeding.
As of the time of writing, Windows Server 2012 R2 has been out for quite a while and it's the OS selected to host our Orchestrator. So, once you have chosen the OS and deployed it, and after having joined to the domain and having done the basic configurations, we can move on with deploying the prerequisites:
Verify that you have permissions on the SQL Server selected to host the database, that the collation is the one specified in the previous section, and finally that Windows Authentication is the authentication mechanism selected. If you choose to install the SQL Server locally, don't forget to get the Database Engine Services options and the share features by navigating to Management Tools | Basic.
Add the Orchestrator Administrators group and the Management Service account to the local Administrators group of the server.
Enable the Web Server (IIS) role, accept the features added, and proceed with the installation. The default settings of this role will suffice as the Orchestrator will configure it accordingly for you. If the Orchestrator installation doesn't detect this role on the server, it will install it for you.
Install the .NET 3.5 SP1 feature. Don't forget to indicate the alternative source for the installation to occur.
(Only if you're installing on Windows Server 2008 R2): Install the .NET 4.5 feature. If you forget to activate the ASP.NET and HTTP Activation features, the installer will take care of activating them for you.
Install Silverlight. If you start the console without installing it, you'll be required to install it.
Launch the installation using the
SetupOrchestrator.exe. Select Install on the System Center 2012 R2 Orchestrator Setup section of the wizard.
On the Product registration page, enter your organization's details and product key, and then click on Next.
Take your time to read the license terms, and if you accept them, continue the installation by clicking on Next.
On Select features to install, by default you'll have all of them selected. As we're installing a single-server, this is the desired selection, so just press Next.
As seen in step 4 of this installation, we didn't include the ASP.NET features on IIS, so Orchestrator will install them for us (press Next) and then it will confirm that everything's OK.
At the Configure the service account step, we'll use the Management Service
scorchmssvcaccount. The explanation on this screen can be a bit misleading, but this is the management service that we're talking about. In a multi-server deployment, this will be different. We'll get there…
Now, at Configure the database server, we'll use our server/instance (if any instance), and the port, and we'll verify the connectivity. If everything's OK, we'll move on with Next.
Verify the database settings at the Configure the database page and specify the database name if you want something different. The default is Orchestrator. Proceed with Next.
Now it's time to configure Orchestrators users group, but although the title of the page can be deceiving, this is not the normal users group, but rather the Administrators group. Click on Browse and select the proper group that you've defined (Scorch_Admins in this example). Click on Next when ready.
At the Configure the ports for the web services page, usually the default ports
81and82are OK, but if these ports are not compliant with your environment or you wish to make the service available at some other port, this is the time to do it. If you do change the ports, don't forget to keep them in mind for the rest of this book as we'll use the default ones for every sample and configuration. Push Next.Time to select the installation location. Usually, the default is OK, but, once again, you can specify another location that is more suitable for your needs. Push Next.
On the Help improve Microsoft System Center Orchestrator, select the options you prefer and click on Next.
Review Installation summary, and if everything's OK, click on Install to start the installation.
Once the installation finishes, you'll be given the status of the installation along with a few options to consider before finishing the setup:
Launch Windows Update.
Visit System Center Orchestrator Online.
When the setup closes, start Runbook Designer.
All these steps can be automated with Powershell. The following is a sample of the command line to execute in order to install it in an unattended way with the Orchestrator in a single-server:
D:\Setup\Setup.exe /DbServer:SQLSERVER\INSTANCE /DbNameNew:Orchestrator /WebServicePort:81 /WebConsolePort:82 /OrchestratorRemote /UseMicrosoftUpdate:1 /SendCEIPReports:0 /EnableErrorReporting:never /Components:all /ServiceUserName:DOMAIN\scorchmssvc /ServicePassword:IWontTellYou /OrchestratorUsersGroup:(Group's SID) /Key:XXXXX-XXXXX-XXXX-XXXX-XXXXX /Silent
As we're setting up only one server, we're only going to use the Management Service account for the Management Service and for the Runbook Service. In this type of deployment, only one account is required. The Runbook Server service account will be used for any additional Runbook Servers that we may like to deploy in the future, and it's best practice to separate the two services into separate accounts to avoid a single point of failure in the future.
If you choose to go with the command-line installation, don't forget to retrieve the Scorch_Admins group SID. If you don't want to specify the group, it will use the default one locally called OrchestratorUsersGroup. If you would like to install Orchestrator into another directory, you can use the InstallDir() function and specify the directory.
In any case, you need to verify the installation logs. They will be under C:\Users\<USER>\AppData\Local\Microsoft System Center 2012\Orchestrator\Logs.
With this complete, you will have a fully functional Orchestrator 2012 R2 deployment.
As mentioned previously in the Planning the Orchestrator architecture section, we can use a multi-server deployment to separately host the components of Orchestrator if we're targeting a highly available environment or if we have a huge demand for Runbooks running at the same time. If you jumped straight into this part, we strongly suggest you read the Planning the Orchestrator architecture section before proceeding.
On the multi-server solution, we have to start by deploying the Management Server along with the database. This is the main focus point of our Orchestrator architecture, so we have to start with it.
Verify that you have permissions on the SQL Server selected to host the database and that the collation is the one specified on the previous section, and, finally, that Windows Authentication is the authentication mechanism selected. If you chose to install the SQL Server locally, don't forget to get the Database Engine Services options, with the share features by navigating to Management Tools | Basic.
Add the Orchestrator Administrators group and the Management Service account to the local Administrators group of the server as explained above for the single-server instance.
Install the .NET 3.5 SP1 feature. Don't forget to indicate the alternative source for the installation to occur.
(Only if you're installing on Windows Server 2008 R2): Install the .NET 4.5 feature. You don't need to activate the ASP.NET as this is the Management Server, so it won't need it.
Launch the install using
SetupOrchestrator.exe. Select Install on the System Center 2012 R2 Orchestrator Setup section of the wizard.On the Product registration page, enter your organization's details and product key, and then click on Next.
Take your time to read the license terms, and if you accept them, continue the installation by clicking on Next.
On Select features to install, by default you'll have all of them selected. We're going to remove all of them except the required one—Management Server - and then proceed. Click on Next.
At the Configure the service account step, we'll use the Management Service (
scorchmssvc) account, test, and proceed with Next.Now, at Configure the database server, we'll use our server/instance (if any instance) and the port, and we'll verify the connectivity. If everything's OK, we'll move on with Next.
Verify the database settings at the Configure the database page and specify the database name if you want something different. The default is Orchestrator. Proceed with Next.
In Configure Orchestrator users group, select the group defined earlier for the Orchestrators
Adminsfunction, in this caseTEST\Scorch_Admins. After this is set, press Next.Select the installation location that's most convenient for you and proceed with Next.
On the Microsoft Update screen, select the On (recommended) option and proceed with Next. It's very important to keep your Orchestrator up to date.
On Help improve Microsoft System Center Orchestrator, select the option you prefer and proceed with Next.
On Installation Summary, verify your options and proceed with Install if they're OK.
Once finished, you'll see a Setup completed successfully page with two options:
Launch Windows Update
Visit System Center Orchestrator Online
You'll then have finished your installation. We strongly suggest that you run the Windows Update option and update everything there is to update.
If you wish to install the Management Server component in an unattended way, don't forget to retrieve the Scorch_Admins group SID. If you don't want to specify the group, it will use the default one locally called OrchestratorUsersGroup. If you would like to install Orchestrator into another directory, you can use the InstallDir function and specify the directory.
In any case, you need to verify the installation logs. They will be under C:\Users\<USER>\AppData\Local\Microsoft System Center 2012\Orchestrator\Logs. You can do the unattended installation by executing the following commands:
Import-Module ServerManager Add-WindowsFeature NET-Framework-Core -source D:\Sources\sxs D:\Setup\Setup.exe /DbServer:SQLSERVER\INSTANCE /DbNameNew:Orchestrator /OrchestratorRemote /UseMicrosoftUpdate:1 /SendCEIPReports:0 /EnableErrorReporting:never /Components:ManagementServer /ServiceUserName:DOMAIN\scorchmssvc /ServicePassword:IWontTellYou /OrchestratorUsersGroup:(Group's SID) /Key:XXXXX-XXXXX-XXXX-XXXX-XXXXX /Silent
Once you have deployed the Management Server, you can proceed with the next logical step on the installation, that is, the Runbook Server. The Orchestrator architecture needs at least one Runbook Server in order to function.
For the installation of the Runbook Server, these are the steps to take:
Have the Management Server installed and the Runbook Server Service account at hand (
scorchrbsvc).Add the Orchestrator Administrators group, the Management Service account, and the Runbooks Service account to the local Administrators group of the server.
Install the .NET 3.5 SP1 feature. Don't forget to indicate the alternative source for the installation to occur.
(Only if you're installing on Windows Server 2008 R2): Install the .NET 4.5 feature. You don't need to activate the ASP.NET as this is the Runbook Server, so it won't need it.
Launch the installation using the
SetupOrchestrator.exe. Select Runbook Server under the Standalone installations in the System Center 2012 R2 Orchestrator Setup section of the wizard.On the Product registration page, enter your organization's details and product key, and then click on Next.
Take your time to read the license terms, and if you accept them, continue the installation by clicking on Next.
Click on Configure the service account that was created for the Runbook Server service, in this case,
scorchrbsvc. Proceed after testing by clicking on Next.On the Configure the database server page, type the same server and instance (if applicable) that you used on the Management Server configuration. Click on Next.
On Configure the database, select the existing database (usually selected by default). Push Next to continue.
Click on Select the installation location and proceed with Next.
Regarding the Microsoft Update page, select your preference and click on Next.
On Help improve Microsoft System Center Orchestrator, select your preferences and proceed with Next.
Review the Installation Summary, and if everything's OK, click Install to start the process.
As mentioned previously, we recommend you take the time to get all the latest updates and then carry on with the installation of the other components.
If you prefer to run an unattended installation, you can do so by executing the following commands:
Import-Module ServerManager Add-WindowsFeature NET-Framework-Core –source D:\Sources\sxs D:\Setup\Setup.exe /DbServer:SQLSERVER\INSTANCE /DbNameExisting:Orchestrator /UseMicrosoftUpdate:1 /SendCEIPReports:0 /EnableErrorReporting:never /Components:RunbookServer /ServiceUserName:DOMAIN\scorchmssvc /ServicePassword:IWontTellYou /Key:XXXXX-XXXXX-XXXX-XXXX-XXXXX /Silent
After deploying both the Management Server and Runbook Server, you can deploy the console and w service getting the Orchestrator architecture finalized, given that the Runbook Designer will get installed on a Windows 7/8 client. There's no specific order to the installation of the components, except that the Management Server has to be always the first component to get installed.
To install the Console and Web Service, you'll need to execute the following steps:
Have the Management Server installed and the Management Server Service account at hand (
scorchmssvc).Add the Orchestrator Administrators group, the Management Service account, and the Runbooks Service account to the local Administrators group of the server.
Install the .NET 3.5 SP1 feature. Don't forget to indicate the alternative source for the installation to occur.
(Only if you're installing on Windows Server 2008 R2): Install the .NET 4.5 feature and activate the ASP.NET and HTTP Activation features. If you forget to activate this feature or don't want to activate it for now, Orchestrator will install it for you during the setup.
Install the Web Server (IIS) with the default settings.
Install Silverlight. If you don't install it now, when you get to the Console, it will request that you install Silverlight.
Launch the installation using
SetupOrchestrator.exe. Select Orchestrator Console and Web Service under Standalone installations on the System Center 2012 R2 Orchestrator Setup section of the wizard.On the Product registration page, enter your organization's details and product key, and then click on Next.
Take your time to read the license terms, and if you accept them, continue the installation by clicking on Next.
Click on Configure the service account that was created for the Management Server service. In this case,
scorchmssvc. Proceed after testing by clicking on Next.On the Configure the database server page, type the same server and instance (if applicable) that you used on the Management Server configuration. Click on Next.
On Configure the database, select the existing database (usually selected by default). Push Next to continue.
At the Configure the ports for the web services page, usually the default ports
81and82are OK, but if these ports are not compliant with your environment or you wish to make the service available at some other port, this is the time to do it. If you do change the ports, don't forget to keep them in mind for the rest of this book as we'll use the default ones for every sample and configuration. Push Next.Click on Select the installation location and proceed by clicking on Next.
On Help improve Microsoft System Center Orchestrator, select your preferences and proceed with Next.
Review the Installation summary, and if everything's OK, click on Install to start the process.
If you want to install the Console and Web Service in an unattended way, you can do so by using the following commands:
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 D:\Setup\Setup.exe /DbServer:SQLSERVER\INSTANCE /DbNameExisting:Orchestrator /WebServicePort:81 /WebConsolePort:82 /OrchestratorRemote /SendCEIPReports:0 /EnableErrorReporting:never /Components:WebComponents /ServiceUserName:DOMAIN\scorchmssvc /ServicePassword:IWontTellYou /Key:XXXXX-XXXXX-XXXX-XXXX-XXXXX /Silent
That's it for the Orchestrator architecture to be complete on the server side. Now all that's missing is the Runbook Designer that we will install on our Windows 8.1 (or 7) workstation on the multi-server solution.
To achieve a successful installation on the Runbook Designer, you'll need to get .NET 3.5 SP1 and Silverlight installed. The Runbook Designer can be installed independently whether or not you have a Management Server and the proper database setup already, but it will be rather useless without it.
Before proceeding with this installation, please complete either a single-server or a multi-server implementation:
On the machine selected to install the Runbook Designer, enable the feature .NET 3.5 SP1 (if not already enabled).
Install Silverlight. If you don't install it now, you'll be prompted to install it if you have access to the console.
Launch the installation using the
SetupOrchestrator.exe. Select Runbook Designer under the Standalone installations on the System Center 2012 R2 Orchestrator Setup section of the wizard.On the Product registration page, enter your organization's details and product key, and then click on Next.
Take your time to read the license terms, and if you accept them, continue the installation by clicking on Next.
Click on Select the installation location and proceed with Next.
On Help improve Microsoft System Center Orchestrator, select your preferences and proceed with Next.
Review Installation Summary, and if everything's OK, click on Install to start the process.
Once the installation completes, you'll be given the status of the installation along with a few options to consider before finishing the setup:
Launch Windows update.
Visit System Center Orchestrator Online.
When Setup closes, start the Runbook Designers.
As with all the other components of Orchestrator, you can also run the Runbook Designer installation in an unattended fashion. For that, you'll need to execute the following commands:
Import-Module ServerManager Add-WindowsFeature NET-Framework-Core –source D:\Sources\sxs D:\Setup\Setup.exe /SendCEIPReports:0/EnableErrorReporting:never /Components:RunbookDesigner /Key:XXXXX-XXXXX-XXXX-XXXX-XXXXX /Silent
When you start the Runbook Designer for the first time from a remote location (a workstation or server that's not the Management Server), you'll be presented with an error message saying Could not find Orchestrator Management Service on 'WORKSTATION'.
Confirm with OK, and then click on Actions. Select Connect... and insert the Management Server name into the box.
In the Connection window, insert the name of the Management Server that you'll be connecting to. This is a one-time setup for your user.
Once connected, you'll see Runbook Designer completely available.
Before you can use the Orchestrator Console option in Runbook Designer, you'll have to define it. To do so, go to Options | Orchestrator Console and insert the proper URL.
In our example here (with the multi-server implementation), the URL is http://PACKTSCORCHW:82.
After that, press Finish and you'll have everything configured as it should be.
So far, we've seen how to plan and deploy our Orchestrator architecture and the requirements and prerequisites for deploying successfully each component of Orchestrator in a single-server environment or multi-server environment.
All the actions completed on this chapter are essential for the successful usage of Orchestrator in your environment, so we recommend you plan your Orchestrator architecture thoroughly.
Welcome to Orchestrator! The journey has just begun...
