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
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.
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:
HTTP
8280now forwards to HTTPS8281HTTPS
8283is now used for the Orchestrator Control Center
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:
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 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.
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.
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.
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:
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
vcoadminas user andvcoadminas the password.
You are now logged into the Orchestrator Client.
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.
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
.ovafile.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.
See the recipe Tuning the appliance in Chapter 2, Optimizing Orchestrator Configuration.
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.
There are several things you should do or at least know how to do.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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 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.
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.
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.
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.
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;
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.
The recipe Backup and recovery in Chapter 2, Optimizing Orchestrator Configuration.
To use Orchestrator to its fullest possibilities we should configure it with an external authentication.
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.
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.
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.localfor 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 calledvcoAdministrators@vsphere.local.Click on Save Changes and restart the Orchestrator service again.
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
Usersis 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.
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.
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.
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:
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.
Recipes in Chapter 11, Additional Plugins, depict which authentication is the most preferable for the plugins discussed there.
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.
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,srv_vro@mylab.local.
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.
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
srv_vro@mylab.localand 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.
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.
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.
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.
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.
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.
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.
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.
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:
Open the Orchestrator Control Center.
Click on Manage Plug-Ins.
Click on Browse and select the
.vmoappfile you downloaded, then click Install:
Accept EULA and click on Install.
Restart the Orchestrator service.
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.
With vRO7.1, you are now able to define a log level for each plugin. The log level ranges from DEFAULT to OFF:
To update a plugin, just download the new version and deploy it as shown in this recipe. The plugin will be updated.
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:
The introduction of Chapter 11, Additional Plugins gives information where you can find plugins and show how to use some of these.
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.
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.
Follow these steps if you wish to use the ISO file.
Open vmware.com in 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]:5480Navigate to Update | Settings.
Continue with Apply the Update.
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.
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.
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.
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
.zipUpdate 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;
manifestandpackage-pool. Make sure that the folders are browseable and that they are accessible. In IIS you might need to add the.sigand.sha265file type as atext/scriptletMIME 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.
The recipe Upgrading a Cluster in Chapter 3, Distributed Design.
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.
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.
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-cliinto 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\binCDto 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 anorchestrator-config-export-VC55-[date].zipfile.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.
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.
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.
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:
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_SQLEXPwith 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.
This recipe shows a hack to make the Orchestrator Client scale on 4K displays.
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....
Tip
Please be careful as this impacts your whole Java environment. This worked very well for me with Java 1.8.0_91-b14.
Download and install Resource Tuner.
Run Resource Tuner as administrator.
Open the file
javaws.exein your Java directory.Expand
manifestand then click on the first entry (the name can change due to localization).Look for the line
<dpiAware>true</dpiAware>.Exchange the
truefor afalseSave and exit.
Repeat the same for all the other
java*.exein the same directory as well asj2launcher.exe.
Start the
Client.jnlp(the file that downloads when you start the web application).
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:
