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.

We need a running Orchestrator that needs to be registered with vSphere (SSO or vRA works as well).

You should consider having a technical user that is able to log into vCenter as a vCenter administrator as well as being a member of the Orchestrator admin group. Using a dedicated user will go in the right direction for automation, see the How it works... section. I will use my dedicated user,srv_vro@mylab.local.

To configure the vCenter connection we need to follow these steps:

For more information and usage, see the recipe Using Orchestrator through the vSphere Web Client in Chapter 7, Interacting with Orchestrator.

Since vCenter Server 5.1, vSphere Web Client is (or better, should be) the main method to access vCenter. Orchestrator completely integrates with vSphere Web Client, making it possible for Orchestrator workflows to be executed directly from vSphere Web Client.

To learn more about the Orchestrator user management, see the recipe User management in Chapter 7, Interacting with Orchestrator.

To configure the Orchestrator workflows in vSphere Web Client, see the recipe Using Orchestrator through the vSphere Web Client in Chapter 7, Interacting with Orchestrator.

We need an Orchestrator server installed and running, as well as access to the Orchestrator Control Center.

Please see the introduction to Chapter 11, Additional Plugins, for information on where to obtain plugins.

Please note that when you download a plugin, your download should contain a .vmoapp or .dar file. A ZIP file needs to be unpacked/unzipped first.

We will now install a new plugin. I will use the Autodeploy plugin:

Orchestrator becomes more exciting with additional plugins, such as plugins from VMware and other vendors. The current version of vRO (7.1) comes with quite a few plugins already installed, such as the following:

We will discuss how to use most of these plugins in Chapter 9, Essential Plugins and Chapter 10, Built-in Plugins.

Plugins make Orchestrator the great product that it is and create a variety of possibilities. If there isn't a plugin for a system, think outside the box. For instance, you can connect Orchestrator to Microsoft System Center Virtual Machine Manager (SCVMM) via SOAP, to Red Hat Satellite using REST, or to your Docker using SSH.

Last but not least, you can create your own plugins. There is an Orchestrator plugin SDK guide that is dedicated to the creation of plugins. See the developer documentation for Orchestrator.

Plugin log level

With vRO7.1, you are now able to define a log level for each plugin. The log level ranges from DEFAULT to OFF:

The introduction of Chapter 11, Additional Plugins gives information where you can find plugins and show how to use some of these.

We need an older version of Orchestrator as well as access to a VMWare webpage.

There are two methods for updating the appliance. First there is updating via an ISO file and second, directly accessing the update repository.

The update process of Orchestrator is pretty simple and straightforward. All versions have the default repository configured and with Internet access, you can use it directly.

Before you update, you should always read the release notes of the newest Orchestrator release to see if there are any problems you might encounter. The update from 5.5 or 6.x to 7 is pretty easy and just requires the newest 7 ISO.

In the Update | settings, there is also the ability to automatically check for updates as well as to automatically check and install updates. I personally wouldn't use the feature in any production setting; an update should always be a controlled process.

If your Orchestrator has no Internet connection but you would still like to use the repository feature and you have a web server (for example IIS), you can do the following:

The recipe Upgrading a Cluster in Chapter 3, Distributed Design.

We need an Orchestrator installed on Windows.

Download the same version of the Orchestrator appliance as you have installed in the Windows version. If needed, upgrade the Windows version to the latest possible one.

There are three ways; using the migration tool, repointing to an external database, or exporting/importing the packages.

Moving from the Windows version of Orchestrator to the appliance version isn't such a big thing. The worst-case scenario is using the packaging transfer. The only really important thing is to use the same version of the Windows Orchestrator as the appliance version. You can download a lot of old versions, including 5.5, from www.vmware.com . If you can't find the same version, upgrade your existing vCenter Orchestrator to one you can download.

After you have transferred the data to the appliance, you need to make sure that everything works correctly, and then you can upgrade to vRO7.

When you just run Orchestrator from your Windows vCenter installation and don't configure an external database, then Orchestrator uses the vCenter database and mixes the Orchestrator tables with the vCenter tables. In order to only export the Orchestrator ones, we will use the MS SQL Server Management Studio (free download from www.microsoft.com called Microsoft SQL Server RTM).

To transfer only the Orchestrator database tables from the vCenter MS-SQL to an external SQL, do the following:

Now you have the Orchestrator database extracted as an external database. You still need to configure a user and rights. Then proceed with the External database section in this recipe.

We need to download the program Resource Tuner ( http://www.restuner.com/ ). The trial version will work, however, consider buying it if it works for you.

You need to know the path to your Java installation, it should be something like this:

C:\Program Files (x86)\Java\jre1.x.xx\bin\.

Before you start....

In Windows 10 you can set the scaling of applications when you are using high definition monitors (4K displays).

What you are doing is telling Java that it is not DPI aware, meaning that it will use the Windows 10 default scaler, instead of an internal scaler.

For any other application, such as Snagit or Photoshop, I found that this solution works quite well:

http://www.danantonielli.com/adobe-app-scaling-on-high-dp .