VMware vRealize Orchestrator Cookbook.: Over 90 recipes to satisfy all your automation needs and leverage vRealize Orchestrator 7.1 for your projects, Second Edition

One of the questions that I constantly hear from customers is about licensing of Orchestrator.

Orchestrator is licensed with vCenter or with vRealize Automation, if you own one of them, you own Orchestrator.

With vSphere, you need at least a vSphere Standard license to use Orchestrator. For vRO7, this means you either need vSphere 6 or vRA 7 license numbers. Although Orchestrator is available with the Essentials or Essentials Plus licensing, it operates in Player mode only. This limits your usage to executing existing workflows and prevents you from editing or creating them.

If you want to test Orchestrator you just need to get a vSphere trial license, which you can acquire over the VMware webpage.

There are huge differences between vRO versions 5.x, 6.x, and 7.x. The first and foremost is that in vRO7 the Configurator has been fully replaced by the new Control Center. The Control Center is an easy tool to use that does all the work of the Configurator and more. Trust me you are going to love it.

The other important thing is that LDAP as an authentication source for Orchestrator is now scheduled to be removed. It's still working with vRO7, but if you are currently using LDAP you need to start thinking about a change.

Speaking of authentication, vRO7 fully supports the vSphere Platform Services Controller architecture and the new vIDM that has been introduced with vSphere 6 and vRealize Automation 7.

The other important changes are in the network section:

The vRO 7.1 appliance requires the following virtual resources:

The only change from the previous Orchestrator versions is that the memory has increased from 3 GB to 4 GB. Please note that this is the base appliance configuration, we will see how to change and improve the performance in the recipe Tuning the appliance that is in Chapter 2, Optimizing Orchestrator Configuration.

The same is true for the following table of Orchestrator limits. These limits are not hard limits and can be changed, we will discuss this in the recipe Control Center titbits in Chapter 2, Optimizing Orchestrator Configuration.

Last but not least, we have to discuss network security in detail and all the ports that need to be opened for Orchestrator to function. We will expand the list of ports when we start working with plugins, but these are the ones most commonly used:

The vRealize Automation (formerly vCloud Automation Center or vCAC) appliance is shipped with a preinstalled and preconfigured vRO. Orchestrator installed on vRA is already configured and works the way the normal Orchestrator appliance does.

The vRA integrated vRO is normally only used for small environments or test environments. If you are deploying vRA for a production, large, or even worldwide role, you should consider using a vRO cluster and/or a distributed Orchestrator design. We will discuss distributed design in more detail in Chapter 3, Distributed Design. We also discuss the vRA integrated appliance in more detail in Working with the vRA integrated Orchestrator in Chapter 13, Working with vRealize Automation.

We can deploy the Orchestrator appliance on either a vSphere environment or on a VMware workstation (or Fusion if you are a MAC user).

Have a quick look at the requirements in the introduction of this chapter.

In this recipe, we will learn how to download and deploy Orchestrator. We will configure it in a later recipe.

The Orchestrator appliance is a preconfigured Orchestrator installation that uses the following software:

Everything is ready to run; however, no integration with vCenter or any external service is configured. The Orchestrator appliance comes with a 90-day evaluation license installed.

If you want to deploy the Orchestrator appliance on VMware Workstation, the process of deploying the Orchestrator appliance differs from the one described in this recipe. Follow these steps instead:

The appliance will start with a DHCP address from the workstation. To set a static IP, you will have to access the admin interface of the appliance.

See the recipe Tuning the appliance in Chapter 2, Optimizing Orchestrator Configuration.

We just need a working Orchestrator as well as access to the Control Center.

There are several things you should do or at least know how to do.

The settings we have just applied are important and need to be done in order to make Orchestrator production-ready.

The package signing, as well as the licensing, needs to be done only once, except if you intend to change the database.

Importing an SSL certificate is an action that we will encounter more often. Every time we want to establish a secure connection (SSL) between Orchestrator and another server, we first have to import this server's SSL certificate. However, most workflows in the current version of Orchestrator include an automatic import (most of the time).

Have a look at the recipe Backup and recovery in Chapter 2, Optimizing Orchestrator Configuration, to learn how to export and import the configuration.

We will need a database; the following databases are supported with vRO7:

You will need to create an empty database for Orchestrator, and you should also create a dedicated user account for Orchestrator to access the database.

If your database requires SSL, you will need to import the SSL certificate first; for this, see the How it works... section of this recipe.

In this example, we have added an MS-SQL database to Orchestrator. The other databases are not that much different.

The following information is needed for each type of database:

To configure a database, follow these steps:

My MS-SQL database is stored on the VM called Central.mylab.local.

The Orchestrator database contains the entire configuration, workflows, workflow runs, events, runtime information, actions, and a lot more.

If you want to use your existing co-operation, backup, and restore procedures of your database or a database cluster for more security, an external database is a good idea.

Orchestrator comes with an embedded PostgreSQL database, which is rated for production for small and medium deployments by VMware and can be easily backed up using the Control Center or a cron script on the Linux console of the appliance. However, we still require a shared database for clustering; see the recipe Building an Orchestrator cluster in Chapter 3, Distributed Design.

Using the vCenter Server database for Orchestrator is not really a pretty solution. IT best practices dictate the usage of dedicated resources for production environments.

Exporting and importing a database

If you are using the internal PostgreSQL or an external PostgreSQL database, you can use the Control Center to export as well as import the database content.

The export can include information on the last workflow runs as well as the logs.

See also the recipe Backup and recovery in Chapter 2, Optimizing Orchestrator Configuration.

Purging the Database

This sounds much harsher than it is. Purging means getting rid of stuff you may not need anymore and making the database a bit smaller.

Purging the database from time to time isn't such a bad idea, however, you can't be sure whether or not you will throw away stuff you might need. For example, workflow runs and logs can take up a lot of space after some time, but they may also be important. (for example, SOX compliance).

Here are some things you might find useful.

ALTER DATABASE [vRO DB Name] SET ALLOW_SNAPSHOT_ISOLATION ON; GO; ALTER DATABASE [vRO DB Name] SET READ_COMMITTED_SNAPSHOT ON; GO; 

The recipe Backup and recovery in Chapter 2, Optimizing Orchestrator Configuration.

We need an up and running Orchestrator and access to the Control Center (root account). Also see, the recipe Deploying the Orchestrator appliance in this chapter.

You should have an AD/LDAP group for your Orchestrator Administrators with at least one user in it. I will use the AD group vroAdmins with its member vroAdmin and my domain is called mylab.local. My PSC/SSO is on vcenter.mylab.local.

If you are using AD/LDAP, then you need only to know the LDAP path to your vroAdmin user and group.

If you are using SSO or vSphere(PSC), you should either have configured SSO to use AD or created a local SSO group and user.

We are splitting the recipe into multiple parts, one for each authentication method.

Configuring Orchestrator to work with an external authentication enables AD users to log in to the Orchestrator Client. The alternative would be to either have only one user using it or adding users to the embedded LDAP. However, for a production Orchestrator, the embedded LDAP solution is not viable.

PSC/vIDM/SSO is a highly integrated part of vSphere, it can proxy multiple AD and/or LDAP domains and lets you integrate Orchestrator directly into vCenter as well as other corner pieces of VMware software offerings.

If you are using vSphere or vRealize Automation authentication, you have the additional benefit of having Orchestrator automatically licensed. If you are using LDAP or SSO you have to assign a license to Orchestrator.

When using SSO or vSphere, Orchestrator will register in SSO as a Solution User with the prefix vCO.

Test login

With the test login, you can test if you can log on to Orchestrator using the Control Center:

If you get a reply in yellow saying Warning: The user does not have administrative rights in vRealize Orchestrator. Login to the Orchestrator client depends on the user view permissions, it means that the user has been found by Orchestrator but he is not a member of the Orchestrator admin group. See also, the recipe User management in Chapter 7, Interacting with Orchestrator.

Changing the Authentication Provider is quite easy. If you choose LDAP and now want to change it to something else, just select the new provider.

If you chose vSphere SSO or vRealize Automation you need to first unregister the existing Authentication Provider. To do this, follow these steps:

Recipes in Chapter 11, Additional Plugins, depict which authentication is the most preferable for the plugins discussed there.