VMware vRealize Orchestrator Cookbook

Chapter 1. Installing and Configuring Orchestrator

In this chapter, we explore how to install and configure Orchestrator. We will be looking at the following recipes:

Deploying the Orchestrator appliance
Important Orchestrator settings
Configuring an external database
Configuring external authentication
Connecting to vCenter
Installing plugins
Updating Orchestrator
Moving from Windows to appliance
Orchestrator Client and 4K display scaling

Introduction

This chapter is dedicated to the configuration of Orchestrator and discusses how to set the tone for your Orchestrator deployment.

Until vRO 7, there were three different Orchestrator versions that one could use. The Windows-based installation (that was also automatically installed along with vCenter), the appliance, and the vRealize Automation integrated one. In vRO7, only the appliance and the vRealize Automation (vRA) integrated Orchestrator versions are left. All other versions have been discontinued.

If you still have a Windows version, you need to think about moving it to the appliance. Check out the recipe Moving from Windows to appliance in this chapter. You can currently still download and use the vRO 6.0.4 appliance or Windows version, however, you should consider updating.

Before the vRO appliance came along, the configuration of Orchestrator wasn't easy; therefore, not many people really used it. Now, the initial configuration is already done out of the box and people can start using Orchestrator directly without too much fuss. However, if one plans to use Orchestrator in a production environment, it is important to know how to configure it properly.

Licensing

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.

vRealize Orchestrator 7 changes

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:

HTTP 8280 now forwards to HTTPS 8281
HTTPS 8283 is now used for the Orchestrator Control Center

Orchestrator appliance basics

The vRO 7.1 appliance requires the following virtual resources:

CPU	2 vCPU with at least 2.0 GHz
Memory	6 GB
Disk Space	17 GB (1.5 GB thin)
Network	1 x NIC 1 x IP (DHCP possible)
vHardware	Version 7

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.

Maximal concurrent connected vCenters	20
Maximal concurrent connected ESXi hosts	1280
Maximal concurrent connected VM	35,000
Maximal concurrent running workflows	300

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:

Orchestrator and vRealize Automation (vRA)

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.

Deploying the Orchestrator appliance

We will now deploy the Orchestrator appliance based on Linux. If you are using the vRA integrated Orchestrator, see the introduction to Chapter 13, Working with vRealize Automation.

Getting ready

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.

How to do it...

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

Download

Navigate to http://vmware.com and select Downloads.
Click on Download Product next to VMware vSphere or vRealize Automation.
Look for VMware vRealize Orchestrator Appliance 7.1 and click on Go to Downloads.
Look for the OVA file and click on Download Now.

Deploy

Log into vCenter using the vSphere Web Client.
Right-click on the cluster or ESXi server and select Deploy OVF Template....
The Deploy OVF Template wizard starts. Select the OVA file you have downloaded and click Next.
Accept the EULA and click Next.
Select a name (or accept the default) as well as the vCenter folder for the Orchestrator appliance and click Next.
Select the cluster or ESXi server or a resource pool for the Orchestrator appliance and click Next.
Select the datastore you would like to deploy the Orchestrator appliance on and click Next.
Select a network for the Orchestrator appliance and click Next.
In the Customize template section, set a password for the root user.
Enable SSH if you wish. This can be done later too. See the recipe Tuning the appliance in the next chapter.
If you like, tick to join the Customer Experience Improvement program.
Set a Hostname for the Orchestrator appliance.
If you want to use a fixed IP, expand the Network Properties section, enter all IP related entries, and then click Next. If you want to use DHCP, just click on Next.
Select to power on the VM after deployment and click on Finish.
Wait until the VM has finished deploying and is powered on.
Open the console of the Orchestrator appliance and wait until the install process has completed and the VM console shows the following screenshot:

Log in to the Orchestrator Client

Open a browser and browse to the IP of the Orchestrator appliance (for example, http://192.168.220.12).
Depending on your environment, you might need to accept the SSL certificate. You are now on the Orchestrator home page with several useful links to all important Orchestrator topics:
To open up the Orchestrator Client, click on Start Orchestrator Client.
Enter vcoadmin as user and vcoadmin as the password.

You are now logged into the Orchestrator Client.

Log into Control Center

Some of the next recipes need us to log into Control Center, here is how to do that:

On the Orchestrator Home page click on Orchestrator Control Center.
Enter the user root and the password you assigned during deployment.

How it works...

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

SUSE Linux Enterprise Server (SLES) 11 Patch level 3
VMware-Postgres 9.4.5.0
ApacheDS LDAP 2.4.42

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.

There's more...

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:

Use Windows Explorer to navigate to the downloaded .ova file.
Double-click on the OVA file. VMware workstation opens up.
Select a name and a path for the new VM and click on Import.
Accept the EULA and wait until the VM is deployed.
You might need to select a different network (for example, Host-Only) depending on your lab environment.
Power on the VM and wait until the install pauses at the line indicated in this screenshot:
Enter and confirm a new password for the root account.
The installation will now continue. Wait until it has finished.

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.

Important Orchestrator settings

The following is a small collection of things that one should do or at least know how to do. It includes licensing, certificates, and virtual hardware.

Getting ready

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

How to do it...

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

Starting, stopping, and restarting the Orchestrator service

These are operations that have to be done quite often, so it's best to know how to do them:

Open Control Center and click on Startup Options.
You can see the current status of the Orchestrator service.
Click on one of the action buttons.
After choosing an action, wait until the status has changed.

Licensing

You can either enter a license key manually or connect to the vCenter Server or vRealize Automation to acquire the license.

Tip

If you are planning to use vSphere or vRealize Automation as an external authentication, you can skip this step as the licensing will be configured automatically.

If you change the database, you will need to redo the licensing:

Open Control Center and click on Licensing.
If you have an authentication provider configured (vSphere or VRA) then you can select vSphere License.
If you used SSO or LDAP, you need to use Manual License. With vRO7 you will need to enter a vSphere 6 vCenter or vRealize Automation 7 License number.
Click on Save.

Package Signing Certificate

The Packaging Signing Certificate signs all packages or exports. One is automatically generated with the Orchestrator's VMs Hostname. We will now show how to create a custom one:

Open Control Center and click on Certificates.
Click on Packaging Signing Certificate and then on Generate.
Enter either personal information or information of the VM.
Click on Generate.
Restart the Orchestrator service.

Trusted SSL certificates

If your database or LDAP is secured with SSL, which by the way isn't such a bad idea, you will need to import the certificate into Orchestrator first. To do this, follow these steps:

Open Control Center and click on Certificates.
In the Trusted Certificates section click on Import.
In Import from URL, enter https://Central.mylab.local.
Click on Import.

For almost all VMware infrastructure the import of their certificate is integrated into the workflows and doesn't need to be done by hand anymore.

Force plugins reinstall

If you have changed the database, you will need to do this step in order for you to use all the workflows that come with the plugins.

Open Control Center and stop the Orchestrator service.
Return to the main Control Center page and click on Troubleshooting.
At the end of the screen click on Force plug-ins reinstall.
Wait until you see the green Operation started successfully.
Start the Orchestrator service again.

When Orchestrator restarts, it installs all new plugins that exist, but as the plugins haven't changed in the versions before this, updating the database leads to this little problem.

How it works...

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).

Configuring an external database

In this recipe, we will attach Orchestrator to an external database. The internal Orchestrator PostgreSQL is production-ready, however for certain designs, such as Orchestrator Cluster and large deployments we still require one.

Getting ready

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

Oracle 11g all editions - 64 bit
Oracle 12g/c all editions - 64 bit
SQL Server 2008 R1/R2 all editions - 64 bit
SQL Server 2012 R1/R2 all editions - 64 bit
PostgreSQL

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.

Tip

When you replace the database, you will have to reconfigure the following items: Licensing and Packaging Signing Certificate.

How to do it...

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:

Database type	Oracle	SQL Server	PostgreSQL
Login	required	required	required
SSL	optional	optional	optional
Hostname	required	required	required
Port	1521 or custom	1433 or custom	5432 or custom
Database name	-	required	required
Instance	required	optional	-
Domain	-	optional	-
Use NTLMv2	-	optional	-

To configure a database, follow these steps:

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

Open Control Center.
Click on Configure Database.
Select SQL Server for Microsoft SQL server.
Fill in the required information. You only need to fill in the domain if you are using Windows authentication.
Click on Save Changes.
You are now asked to Update database.
After updating, the screen returns to the following one. You have configured the external database. You may need to configure the licensing and Package Signing Certificate as they were stored in an internal PostgreSQL database. Additionally, you may need to force the re-installation of plugins:

How it works...

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.

Sizing

Sizing is hard to predict. Each Workflow run consumes around 4 KB, and most objects (for example, vCenter Server object) require around 50 KB each. VMware recommends 1 GB for a production database. The good thing is that Orchestrator regularly runs clean-up jobs to reduce the database content. Also have a look at the recipe User preferences in Chapter 7, Interacting with Orchestrator, where we discuss certain properties that influence how much information is kept in the database.

Database roles

For the initial setup (and for updates), you should give the dedicated Orchestrator user the db_owner rights of the Orchestrator database.

For normal usage scenarios the Orchestrator user only requires db_dataread and db_datawrite rights.

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).

There's more...

Here are some things you might find useful.

Microsoft SQL

Giving the database the settings, ALLOW_SNAPSHOT_ISOLATION and READ_COMMITTED_SNAPSHOT, will reduce the possibility of deadlocks and is also a prerequisite for Orchestrator clusters. This can be done by running the following script on the SQL cluster:

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

Oracle

The database should have NLS_CHARACTER_SET = AL32UTF8 set before you start allowing Orchestrator to build its tables.

To avoid an ORA-01450 error, it is important that you have the database block size configured in correspondence with your database index.

Internal PostgreSQL

To access the local DB (for example, for backups), you need the following information:

Database name	`vmware`
User	`vmware`
Password	`vmware`

The PostgreSQL install is protected to only allow local access to it. You'll find the installation in /var/lib/pgsql.

Configuring external authentication

To use Orchestrator to its fullest possibilities we should configure it with an external authentication.

Getting ready

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.

How to do it...

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

vSphere (PSC) and vRealize Automation (vRA)

For both vSphere 6 and vRA7, the entry forms look alike and follow the same pattern. However, there are some really important considerations to take into account for both. Please see the How it works... section of this recipe.

To set either vSphere (PSC) or vRealize Automation (vIDM), follow these steps:

Open the Control Center and click on Configure Authentication Provider.
Choose vSphere or vRealize Automation.
Enter the host name of your vSphere PSC or vRA.
After clicking on Connect, you may need to accept the SSL certificate.
You are now asked to enter the User name and Password of an SSO administrator.
Clicking on Configure licenses will automatically configure Orchestrator licensing with the vCenter license.
Enter the default tenant of your SSO and click on Register:
After the registration, you are asked for the admin group. Enter the name of your admin group (or the first letters, such as vro) and click on Search.
Select your admin group from the drop-down menu, such as mylab.local\vroAdmins. In vRA, there is a preconfigured group called vsphere.local\vcoAdminis.
Click on Save Changes and restart the Orchestrator service.

SSO (legacy)

If you are using vRO7 with vSphere 5.5 (minimum update 2) you need to use the SSO configuration:

Open the Control Center and click on Configure Authentication Provider.
Choose SSO (legacy).
Enter the following for Admin URL: https://vcenter.mylab.local:7444/sso-adminserver/sdk/vsphere.local.
Enter the following for STS URL: https://vcenter.mylab.local:7444/sts/STSService/vsphere.local.
Click on Save Changes.
You will now need to accept the SSL certificate of your SSO server (not shown in the following picture).
After you have accepted the certificate you will be asked to enter an SSO admin account and its password, followed by the Default tenant, which is vsphere.local for all 5.5 systems.
Click on Register.
If everything is fine you will now be asked to restart the Orchestrator service. However, we can ignore that for the moment:
Now you need to choose admin group. Enter the name of your admin group (or the first letters, such as vro) and click on Search.
Select your admin group from the drop-down menu, such as mylab.local\vroAdmins. SSO 5.5 has a preconfigured Orchestrator group called [email protected].
Click on Save Changes and restart the Orchestrator service again.

LDAP

Please note LDAP will be discontinued in further Orchestrator releases and should not be used anymore. Furthermore, using LDAP won't allow Orchestrator to use all its awesome features.

If you are using LDAP, you can choose from the In-process LDAP (ApacheDS), the built-in LDAP, Active Directory, or OpenLDAP.

Please note that LDAP entries are case sensitive. To configure Orchestrator with Active Directory, follow these steps:

Open the Control Center and click on Configure Authentication Provider.
Choose LDAP and then Active Directory.
Enter the domain name of your AD and set the port to 389.
As root, enter your domain in LDAP dc=mylab,dc=local.
Enter the username in LDAP and then the password. Be mindful that in AD, the folder Users is not an OU but a CN, cn=vroAdmin,cn=Users,dc=mylab,dc=local.
It is easiest to set the user and group lookup base to the root of your domain, for example, dc=mylab,dc=local. However, if your AD or LDAP is large, it might be better performance-wise to choose a different root.
Enter the Orchestrator admin group in LDAP, cn=vroAdmins,cn=Users,dc=mylab,dc=local.
Click on Save Changes.
If everything is fine you will be asked to restart the Orchestrator service.

How it works...

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.

vRealize Automation and vSphere Authentication

The entry masks look the same, however, they are not. vSphere uses SSO and vRA 7 uses vIDM and those are very different beasts indeed.

When you register Orchestrator with vRealize Automation or you use the vRA embedded Orchestrator you will not be able to use a per-user session with vCenter as the SSO token and the vIDM token are incompatible at this time. I have been informed that the ability to configure the vRA embedded Orchestrator version will not be able to use PSC configuration anymore. The best way to solve this is to use a secondary Orchestrator.

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.

Internal LDAP

The internal LDAP has the following preconfigured entries:

Username	Password	Group membership
`vcoadmin`	`vcoadmin`	`vcoadmins`
`vcouser`	`vcouser`	`vcousers`

The LDAP installation is protected to only allow local access to it. Using the internal LDAP is not recommended at all.

There's more...

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:

Open the Control Center and click on Configure Authentication Provider.
Click on Unregister and then enter the SSO admin's password and click Unregister.
Now you can select another Authentication mode.

Connecting to vCenter

In this recipe, we connect Orchestrator to vCenter. This will allow Orchestrator to access vCenter objects as well as vSphere Web Client users to access Orchestrator workflows. For an Orchestrator used with vRA, you need to use the endpoint configuration, see the How it works... section.

Getting ready

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

Tip

If you are planning to use a customer SSL certificate for your Orchestrator, then exchange the certificate before you continue here. See the recipe Configuring the Orchestrator service SSL certificate in Chapter 2, Optimizing Orchestrator Configuration.

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,[email protected].

Tip

Check out the VMware Product Interoperability Matrixes for the interaction with your vRO version and the vSphere Web Client. For example, vRO 7 will only work with vSphere Web Client 6, it will not work with 5.5.

How to do it...

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

Open the Orchestrator Client with an Orchestrator Administrator.
Start the workflow Library | vCenter | Configuration | Add a vCenter Server instance.
Enter your vCenter FQDN.
Select that you would like to orchestrate this instance as well and that you would like to accept SSL certificates even if they are self-signed.
Tip
Orchestrating a vCenter means that the content of the vCenter will show up in the Orchestrator Inventory and you can select and use it.
Click on Next.
Select No, meaning that you will use a technical user for the connection between Orchestrator and vCenter. This is also the recommended setting if you are using the vRA integrated Orchestrator.
Enter a vCenter server administrative user or a technical user you specified, such as [email protected] and the password of that user.
Click on Submit.
Wait until the workflow is successfully finished.
Start the workflow Library | vCenter | Configuration | Register vCenter Orchestrator as a vCenter Server Extension.
Select your vCenter from the Orchestrator Library.
If you have a load balancer or NAT between Orchestrator and vCenter, enter the external Orchestrator address here.
Click on Submit.
Now log in to the vSphere Web Client as a technical user.
Navigate to vRealize Orchestrator | vRO Home | Summary. Your Orchestrator should be registered there.

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

Well, there is that...

Sometimes the vSphere Web Client - Orchestrator integration doesn't work out-of-the-box after you have set it up. Here are some things to do in that case:

Check the VMware Product Interoperability Matrixes for interaction with your vRO version and the vSphere Web Client.
Use the same versions of vRO and vCenter. For example, vRO7.0.1 (or newer) doesn't integrate into vCenter 6.0U2 (or earlier) due to an SSL problem, it works fine with vCenter 6.0U3 (and newer). This is due to a change in encryption.
Have some patience. It may take some 15 minutes until the Web Client gets it (in a slow lab). The Web Client will continue to show the following error message: Error occurred while processing request. Check vSphere Web Client logs for details.
Restart the vSphere Web Client.
Check your vCenter logs. When you register an extension, a plugin is downloaded. In Orchestrator's case, the URL is:https://[Orchestrator IP]:8281/vco/vsphere-web-client/vco-plugin.zip.
Make sure that the vCenter user has access rights on Orchestrator (see the recipes User management and Using Orchestrator through the vSphere Web Client in Chapter 7, Interacting with Orchestrator).
Unregister all Orchestrator extensions using the MOB and then try again. See kb.vmware.com/kb/1025360.
If you use a cluster, you need to use the external address. The register workflow registers the Orchestrator extension with its IP: https://[Loadbalancer_Address]:8281. Also see the recipe Load-balancing Orchestrator in Chapter 3, Distributed Design.

How it works...

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.

Access, rights, and logging

The access from Orchestrator to vCenter works with the technical user we used to make the connection.

When a workflow is started from Orchestrator, vCenter will log the user who started the workflow but the execution of the workflow will be logged with the technical user.

For a vSphere Web Client user to be able to start a workflow they need to have access to Orchestrator. Either they need to be a member of the Orchestrator admin group or they need non-administrative access.

Technical user

The idea of a technical user is to use a dedicated user that connects between Orchestrator and vCenter. This technical user would be a full vCenter admin. The alternative is to use a per-user base, which means that each user uses his/her vCenter rights to run workflows. The difference is that we either need to set rights and roles throughout vCenter for different users/groups or we create good workflows and security in Orchestrator.

vRA, Orchestrator, and vCenter

As we already discussed in the recipe Configuring external authentication in this chapter, the difference between vSphere and vRealize Automation authentication, namely SSO or vIDM. When you configure an Orchestrator, especially for vRA, you should not configure the vCenter plugin but use the endpoints, as we show in the recipe Adding Orchestrator, as an infrastructure endpoint in the final chapter.

Installing plugins

In this recipe, we will learn how to install plugins for Orchestrator. Configuration and programming-related topics are discussed in Chapter 9, Essential Plugins, Chapter 10, Built-in Plugins, and Chapter 11, Additional Plugins.

Getting ready

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.

How to do it...

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

Open the Orchestrator Control Center.
Click on Manage Plug-Ins.
Click on Browse and select the .vmoapp file you downloaded, then click Install:
Accept EULA and click on Install.
Restart the Orchestrator service.

How it works...

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:

AD 3.0.2 4209033

AMQP 1.0.4.3217705

Configurator 7.0.1.3533702

DynamicTypes 1.2.0.426821

Enums 7.0.1. .3767915

Library 7.0.1.3767915

Mail 7.0.1. 3767915

Net 7.0.1. 3767915

PowerShell 1.0.9.3895915

REST 2.0.1.4157277

SNMP 1.0.3.3767921

SOAP 2.0.0.4147531

SQL 1.1.4.4009493

SSH 7.0.1.3430925

VAPI 7.1.04262825

VC 6.5.0.4132889

VCO 7.1.0.4262825

Workflow documentation 7.1.3767915

XML 7.0.1.3767915

vCAC 7.1.0.4147052

vCACCafe 7.1.0.4176993

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:

Updating plugins

To update a plugin, just download the new version and deploy it as shown in this recipe. The plugin will be updated.

Disabling and uninstalling plugins

You can switch off plugins by de-selecting the Enable plug-in check box. Uninstalling plugins isn't that straightforward and should only be done if you have no other choice, there is a KB that shows how:

kb.vmware.com/kb/2064575 .

Updating Orchestrator

Here we will describe the update process for the Orchestrator appliance as well as the best way to get from 5.x or 6.x to 7. As a Windows install isn't supported in 7 anymore, please see the recipe Moving from Windows to appliance in this chapter. If you are updating a cluster, please see the recipe Upgrading a cluster in Chapter 3, Distributed Design first.

Getting ready

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

How to do it...

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

Tip

Before you start updating

Make sure you have a backup or at least a snapshot of the Orchestrator VM. If you are using an external database, make a backup of the DB as well.

Using an ISO file

Follow these steps if you wish to use the ISO file.

Open vmware.comin your web browser and then click on Download and vSphere.
Look for VMware vRealize Orchestrator Appliance and click on Go to Downloads.
At the very end of the download, you should find the .iso Update Repository Archive. Click on Download now.
After the download has finished, go to your vCenter and mount the image to the Orchestrator appliance.
Browse to the Orchestrator backend:https://[Orchestrator]:5480
Navigate to Update | Settings.
Continue with Apply the Update.

Using the VMware repository

Follow these steps if you wish to use the VMware repository. Your Orchestrator needs a HTTPS connection to the VMware website ( vmware.com )

Open a web browser and browse to the Orchestrator backend:https://[Orchestrator]:5480.
Navigate to Update | Settings.
Continue with Apply the Update.

Applying the update

After we have the update source in place, we can finally update the appliance.

From where we left off, click on Check Updates.
You should now see the version you'd like to upgrade to if that's not the case check the source of the update (for example, ISO file or iNET connection).
Click on Install Updates:
Accept the EULA and acknowledge you would like to update with OK.
The update process will take some time. Wait until Orchestrator tells you: System reboot is required to complete the update.
Reboot the Orchestrator appliance.
After the reboot, access the Control Center and check that everything is fine.

How it works...

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.

Tip

If you are upgrading from 5.5 or 6 to 7 you might want to change the authentication to vsphere to make use of the vSphere 6 features.

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.

Tip

After an upgrade, you need to check your workflows. I have had several cases where a method, a standard library workflow, or a plugin wasn't working the same anymore. If you find something like that please report it to VMware so they can fix it in the next release.

There's more...

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:

Download the .zip Update Repository Archive from vmware.com.
Unpack the ZIP file. After unpacking, copy the contents of the following directory into the web server so that it can be accessed using http(s)\build\mts\release\bora-3571217\publish\exports\Update_Repo.
The web server should now contain two folders; manifest and package-pool. Make sure that the folders are browseable and that they are accessible. In IIS you might need to add the .sig and .sha265 file type as a text/scriptlet MIME type.
Open a web browser and browse to the Orchestrator backend: https://[Orchestrator]:5480.
Navigate to Update | Settings.
Select Use Specified Repository and enter your web server URL into Repository URL and, if needed, the subdirectory where the patch files are located.
Now just follow the recipe to update from the repository.

Moving from Windows to appliance

With vRO 7, the Windows install of Orchestrator doesn't exist anymore. This recipe discusses how to move an existing Windows Orchestrator installation to the appliance.

Getting ready

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.

How to do it...

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

Migration tool

There is a migration tool that comes with vRO7 that allows you to pack up your vRO5.5 or 6.x install and deploy it into a vRO7. The migration tool works on Windows and Linux. It collects the configuration, the plugins, as well as their configuration certificates, and licensing into a file. Follow these steps to use the migration tool:

Deploy a new vRO7 appliance.
Log in to your Windows Orchestrator OS.
Stop the VMware vCenter Orchestrator Service (Windows services).
Open a web browser and log into your new vRO7 - Control Center and then go to Export/Import Configuration.
Select Migrate Configuration and click on the here link. The link points to:https://[vRO7]:8283/vco-controlcenter/api/server/migration-tool.
Stop the vRO7 Orchestrator service.
Unzip the migration-tool.zip and copy the subfolder called migration-cli into the Orchestrator director, for example, C:\Program Files\VMware\Infrastructure\Orchestrator\migration-cli\bin\.
Open a command prompt.
If you have Java installed, make sure your path points to it. Try java -version. If that works, continue, if not, do the following:
Set the PATH environment variable to the Java install that comes with Orchestrator, set PATH=%PATH%;C:\Program Files\VMware\Infrastructure\Orchestrator\Uninstall_vCenter Orchestrator\uninstall-jre\bin
CD to the directory ..\Orchestrator\migration-cli\bin.
Execute the command; vro-migrate.bat export. There may be errors showing about SLF4J; you can ignore those.
In the main directory (..\Orchestrator) you should now find an orchestrator-config-export-VC55-[date].zip file.
Go back to the web browser and upload the ZIP file into Migration Configuration by clicking on Browse and selecting the file.
Click on Import. You can now see what can be imported. You can unselect the items you don't wish to migrate. Click Finish Migration.
Restart the Orchestrator service.
Check the settings.

External database

If you have an external database, things are pretty easy. For using the initial internal database, please see the additional steps in the There's more... section of this recipe.

Backup the external database.
Connect to the Windows Orchestrator Configurator.
Write down all the plugins you have installed as well as their version.
Shut down the Windows version and deploy the appliance, this way you can use the same IP and Hostname if you want.
Log into the appliance version's Configurator.
Stop the Orchestrator service
Install all plugins you had in the Windows version.
Attach the external database.
Make sure that all trusted SSL certificates are still there, such as vCenter and SSO.
Check if the authentication is still working. Use the test login.
Check your licensing.
Force a plugin reinstall (Troubleshooting | Reinstall the plug-ins when the server starts).
Start the Orchestrator service and try to log in.
Make a complete sanity check.

Package transfer

This is the method that will only pull your packages across. This the only easy method to use when you are transitioning between different databases, such as between MS SQL and PostgreSQL:

Connect to your Windows version
Create a package of all the workflows, actions, and other items you need.
Shut down Windows and deploy the appliance.
Configure the appliance with DB, authentication, and all the plugins you previously had.
Import the package.

How it works...

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.

There's more...

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:

Stop the VMware vCenter Orchestrator Service (Windows Services) on your Windows Orchestrator.
Start the SQL Server Management Studio on your external SQL server.
Connect to the vCenter DB. For SQL Express, use [vcenter]\VIM_SQLEXP with Windows Authentication.
Right-click on your vCenter Database (SQL Express: VIM_VCDB) and select Tasks | Export Data.
In the wizard, select your source, which should be the correct one already, and click Next.
Choose SQL Server Native Client 10.0 and enter the name of your new SQL server. Click on New to create a new database on that SQL server (or use an empty one you created already). Click Next.
Select Copy data from one or more tables or views and click Next.
Now select every database which starts with VMO_ and then click Next.
Select Run immediately and click Finish.

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.

jbo Feb 05, 2020

Very useful to validate vRO knowledges. downloadable resources is also very handy.

Amazon Verified review

Gary Dec 30, 2016

There are two things you need if you are just learning VMware vRealize Orchestrator:- This book- To get your company to send you to the VMware Cloud Automation with vRO & PowerCLI course; the online version is very good too!This book is massively less expensive than the course!It's also well written and gives your all of the basics you need to know to get vRO/vRA running in a test environment so you can learn.I highly recommend it.

Alan Feb 19, 2018

Thin on content and useless to an enterprise vRealize technician everything in this book is old news and easily available for free.

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

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Licensing

vRealize Orchestrator 7 changes

Orchestrator appliance basics

Orchestrator and vRealize Automation (vRA)

Download

Deploy

Log in to the Orchestrator Client

Log into Control Center

Starting, stopping, and restarting the Orchestrator service

Licensing

Package Signing Certificate

Trusted SSL certificates

Force plugins reinstall

Sizing

Database roles

Exporting and importing a database

Purging the Database

Microsoft SQL

Oracle

Internal PostgreSQL

vSphere (PSC) and vRealize Automation (vRA)

SSO (legacy)

LDAP

vRealize Automation and vSphere Authentication

Test login

Internal LDAP

Tip

Well, there is that...

Access, rights, and logging

Technical user

vRA, Orchestrator, and vCenter

Plugin log level

Updating plugins

Disabling and uninstalling plugins

Using an ISO file

Using the VMware repository

Applying the update

Migration tool

External database

Package transfer

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs