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.
Planning the Orchestrator deployment
Getting ready
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.
How to do it...
There are three planning categories. They are: people, processes, and the technology (SCO product):
- 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
- 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.
- Plan for the following technology requirements areas for SCO:
- SCO deployment type:
|
Deployment type
|
Description
|
|
Single servers |
All the SCO roles are installed on one physical or virtual machine. This scenario is typically implemented in test environments but is fully supported in production. This, however, becomes a single point of failure for highly automated environments. |
|
Multiserver |
The SCO roles are separated and installed on one or more machines. |
-
- Minimum hardware requirements for each SCO component:
|
Component
|
Requirements
|
|
Management Servers |
|
|
Orchestration databases |
|
|
Runbook Servers |
|
|
Orchestrator console/web services |
|
|
Orchestrator Runbook Designers |
|
- Services accounts and delegation groups:
|
Account/group
|
Type
|
Notes
|
|
Orchestrator management services |
Service accounts |
Create an Active Directory user account for this service. This is the main management server service account, and it is granted the "log on as a service" right during the installation. |
|
Orchestrator Runbook monitor services |
Service accounts |
Typically, this is the same account as the Orchestrator management service. |
|
Orchestrator Runbook services |
Service accounts |
This is the same user account as the Management and Runbook Server monitor service in a single deployment, but it can be different for multiserver deployments; Active Directory domain account is recommended. |
|
Runbook authors (SCO_ADMINS) |
Groups |
Create an Active Directory group. This group will have the equivalent access of full administration to the SCO deployment. |
|
Runbook operators (SCO_CON_USERS) |
Groups |
Create an Active Directory group. This group will have the equivalent access of a Runbook operator to the SCO deployment. |
|
Installation user |
User |
The user with full administrative rights on the SCO servers is required to perform the installation and configuration of the SCO deployment. |
- Network communication ports:
|
Source
|
Targeted computer
|
Default port
|
Configurable
|
|
Runbook Designers |
Management Servers |
135, 1024-65535 |
Yes, after the SCO Installation. |
|
Management Servers, Runbook Servers, and web services |
Orchestration databases |
1433 |
Yes; it is specified during the installation on the SCO supported version of Microsoft SQL Server. This is the case where the SQL Server instance is not using the default port. |
|
Client browsers |
Orchestrator web services |
81 |
Yes, during the SCO installation. |
|
Client browsers |
Orchestration consoles |
82 |
Yes, during the SCO installation. |
How it works...
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's more...
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.