The Orchestrator installation process asks for a number of settings. In this video Dan covers single versus multiple server deployments as well as other installation details.
- This video we'll focus on Microsoft System Center 2016 Orchestrator and the installation planning process. So let's talk about what it is that we need to consider before we actually get to the instillation of our Orchestrator ecosystem. The first thing we'll do is talk about whether we would have a single versus multiple servers. Orchestrator supports running within a physical or a virtual machine environment, but the operating system needs to be at least Windows Server 2012 R2.
Server 2016 is also supported, but not in the Server Core format. Server Core is an option whereby we don't have the graphical user interface portion on the Windows Server. And that is actually required for System Center Orchestrator 2016. If we go with the single server it means that we're installing all of the System Center Orchestrator components on the same host, and that may or may not include the sequel server which hosts the Orchestrator database.
Now if we have multiple servers in our environment we're essentially spreading out the Orchestrator roles across multiple hosts. And we would do this in a larger environment to increase things like Runbook capacity so that we could run more concurrent Runbooks because we've got multiple servers, and also it lends itself to resiliency to failure since components are not all running on the same host at the same time. But we shouldn't install Orchestrator on a domain controller computer. Really we should never install anything additional on an active directory domain controller where possible.
The other thing that we should also bear in mind is that the Deployment Manager tool which gets installed with Orchestrator can also be used after initial instillation to deploy some new items like Runbook Designers or new Runbook Servers. There are a couple of Orchestrator 2016 Services that will result from our installation, and if we install all of the roles on the same server then they'll all be installed on the same host. And they can actually all also use the same service account.
So the first service is the Orchestrator Management Service. This talks to the System Center Orchestrator database, also Runbook Designers and the Deployment Manager tool. Then we've got the Orchestrator Runbook Server Monitor Service, and like the name implies, it's purpose is to monitor Runbook Server health. Then we've got the Orchestrator Runbook Service, which is part of each Runbook Server. Remember, we only have one management server in our Orchestrator environment, but we could have more than one Runbook Server.
And those Runbook Servers are going to have the Orchestrator Runbook Service installed. Then we've got the Orchestrator Remoting Service, which is used by the Deployment Manager tool to connect to other hosts to install things like Runbook Designers, Runbook Servers or even to deploy integration packs out to let's say Runbook Servers. So the Orchestrator Remoting then, uses the local system account when it is running. So let's talk about Service Accounts for a moment.
As pictured in this screen shot, during the installation we get prompted to specify the service account information that we want used. Now if we have all services running on one server then they can use the same service account, they don't have to. Now, depending on what activities within your Runbooks are running, so depending on what they're doing will determine if any additional permissions might be needed. But depending on the activity within the Runbook, you can also specify security credentials that would be used for that specific case.
The service account permissions that are required are granted automatically during installation of Orchestrator, but what they are is to allow logging on locally as service and also the Orchestrator admins role. This is a role that's actually stored within the Orchestrator database, but we don't have to worry about those two things, because again, they're done automatically during the installation. When we do the Orchestrator installation it's going to check to see whether we've got the dot net framework at least 3.5 Service Pack one installed.
And if not, we will be prompted to do that. IIS or the Microsoft Internet Information Services web server is also required. However, it will be installed if it's not already there. Also, it's going to result in an Orchestrator Users Group in Active Directory. Now this is after the installation completes. We'll be prompted during the installation about this. So what this group does, is it grants permissions to use things like the Runbook Designer where Runbook authors could create and manage Runbooks.
It also grants permission to use the Deployment Manager tool, that's more of an admin tool. Which would be used for things like the deployment of Runbook Designers, or Runbook Servers or deploying Integration Packs for additional capabilities. On the database side, when we think about the sequel server that will host the Orchestrator database, we get prompted with this information during installation as seen in the screenshot. Where we can specify the sequel server name we want to connect to, we can specify the port number, the default is port 1433.
We can determine whether we want to authenticate using Windows or sequel authentication. And also, we can test the connectivity with the test database connection button. Now as we keep continuing through this wizard, we will also be prompted to either create a new Orchestrator database where we can specify the name or we can use an existing one. The installation will also prompt us for web services ports. The web service by default uses port 81.
And the console, the Orchestration console uses port 82. So this means that we're going to end up with two different websites that will show up within Microsoft IIS where the web service is essentially used for the REST API exposure of Orchestrator items. And the Orchestration Console is for monitoring and doing some very basic Runbook management.
This course teaches administrators how to automate the monitoring and deployment of data center resources using Orchestrator 2016. Instructor Daniel Lachance begins with a discussion of Orchestrator components and interactions, and walks through the installation of an Orchestrator environment. Then he explores Runbook Designer, the tool for creating various automation solutions related to file management, user onboarding, and more. Follow along and learn how to create your own runbooks with this integral tool, and optimize and reduce your workload.
- Understanding the Orchestrator architecture: from database to console
- Planning an Orchestrator deployment
- Verifying the installation
- Exploring Runbook Designer
- Creating runbooks