vRealize Orchestrator Appliance 8.5 | 19 August 2021 | Build 18474196
vRealize Orchestrator Update Repository 8.5 | 19 August 2021 | Build 18474196
Check frequently for additions and updates to these release notes.
What's in the Release NotesThe release notes cover the following topics:
- What's New in vRealize Orchestrator 8.5
- Deploying the VMware vRealize Orchestrator 8.5 Appliance
- Upgrading and Migrating to vRealize Orchestrator 8.5
- Plug-ins Installed with vRealize Orchestrator 8.5
- Earlier Releases of vRealize Orchestrator
- Resolved Issues
- Known Issues
What's New in vRealize Orchestrator 8.5
VMware vRealize Orchestrator plug-in for vRealize Automation 8.5 and vRealize Automation Cloud
The updated vRealize Automation plug-in supports scripting objects generation, such as cloud accounts, cloud zones, projects, and tags, and CRUD operations on these objects that you can use to build your own content. For each object, some sample content is provided out-of-the-box. Learn more.
Technical limitations in vRealize Orchestrator/vRealize Automation 8.5.0:
- The timeout period for REST operations is 2 minutes.
- Masked custom property values coming from vRealize Automation do not work as input in the Update Project workflow, where custom properties hold encrypted values. This is due to the different encryption logic implemented in vRealize Orchestrator. As a workaround, re-enter the encrypted value without the secret key.
- No pagination support for vSphere cloud account, NSX-T, NSX-V, Data Collector, Regions.
vSphere 7.x API support for the vCenter Server Plug-in for vRealize Orchestrator
The vCenter Server Plug-in for vRealize Orchestrator now supports the latest version of the vSphere 7.x API. For information on scripting objects available for the plug-in, navigate to the API Explorer in the vRealize Orchestrator Client.
Deploying the VMware vRealize Orchestrator 8.5 Appliance
The vRealize Orchestrator Appliance is a VMware Photon OS-based appliance distributed as an OVA file. It is prebuilt and preconfigured with an internal PostgreSQL database, and it can be deployed with vCenter Server 6.0 or later.
The vRealize Orchestrator Appliance is a fast, easy to use, and more affordable way to integrate the VMware cloud stack, including vRealize Automation and vCenter Server, with your IT processes and environment.
For instructions about deploying the vRealize Orchestrator Appliance, see Download and Deploy the vRealize Orchestrator Appliance.
For information about configuring the vRealize Orchestrator Appliance server, see Configuring a Standalone vRealize Orchestrator Server.
Upgrading and Migrating to vRealize Orchestrator 8.5
You can upgrade a standalone or clustered vRealize Orchestrator 8.x deployment to the latest product version by using a mounted ISO image.
For more information about upgrading the vRealize Orchestrator Appliance, see Upgrading vRealize Orchestrator.
You can migrate a standalone vRealize Orchestrator instance authenticated with vSphere or vRealize Automation to vRealize Orchestrator 8.5. Product versions of vRealize Orchestrator 7.x supported for migration include versions 7.3 to 7.6. The migration of clustered vRealize Orchestrator 7.x deployments is not supported.
For more information about migrating the vRealize Orchestrator Appliance, see Migrating vRealize Orchestrator.
Plug-Ins Installed with vRealize Orchestrator 8.5
The following plug-ins are installed by default with vRealize Orchestrator 8.5
- vRealize Orchestrator vCenter Server Plug-In 7.0.0
- vRealize Orchestrator Mail Plug-In 8.0.0
- vRealize Orchestrator SQL Plug-In 1.1.6
- vRealize Orchestrator SSH Plug-In 7.3.0
- vRealize Orchestrator SOAP Plug-In 2.0.4
- vRealize Orchestrator HTTP-REST Plug-In 2.4.0
- vRealize Orchestrator Plug-In for Microsoft Active Directory 3.0.11
- vRealize Orchestrator AMQP Plug-In 1.0.6
- vRealize Orchestrator SNMP Plug-In 1.0.3
- vRealize Orchestrator PowerShell Plug-In 1.0.19
- vRealize Orchestrator Multi-Node Plug-In 8.5.0
- vRealize Orchestrator Dynamic Types 1.3.6
- vRealize Orchestrator vCloud Suite API (vAPI) Plug-In 7.5.2
Earlier Releases of vRealize Orchestrator
Features and issues from earlier releases of vRealize Orchestrator are described in the release notes for each release. To review release notes for earlier releases of vRealize Orchestrator, click one of the following links:
- vRealize Orchestrator 8.4.2
- vRealize Orchestrator 8.4.1
- vRealize Orchestrator 8.4
- vRealize Orchestrator 8.3
- vRealize Orchestrator 8.2.1
- vRealize Orchestrator 8.2
- vRealize Orchestrator 8.1
- vRealize Orchestrator 8.0.1
- vRealize Orchestrator 8.0
- vRealize Orchestrator 7.6.0
- vRealize Orchestrator 7.5.0
- vRealize Orchestrator 7.4.0
- Unable to log in to the vRealize Orchestrator Control Center or the vRealize Orchestrator Appliance.
Using backslash ("\") characters in the root password of your deployment can cause issues when trying to log in to the vRealize Orchestrator Control Center or the vRealize Orchestrator Appliance over a SSH session.
- You cannot find the action dependencies of duplicate workflows.
When you duplicate a workflow and then search for dependencies, actions used in the workflow input form are not found.
- PowerCLI scripts fail with a "An item with the same key has already been added. Key: LinkedView" error.
This PowerCLI scripting issue is caused by a
VMHostPowerCLI object that cannot be parsed into a JSON format.
- Deletion of a workflow or action can take more than a minute to complete.
If your vRealize Orchestrator Client object library contains thousands of workflows or actions, deletion of a workflow or action can take more than a minute to complete.
- When you create a log bundle after migrating from vRealize Orchestrator 7.x to a vRealize Orchestrator 8.x, the migration logs are not included in the bundle.
The log bundle created after migration does not contain the migration log file. This issue is encountered in clustered vRealize Orchestrator environments.
- Workflow run fails on a workflow element with exception handling when the element is a workflow that has a nested element failing.
This issue can be triggered if your workflow schema contains the default error handling item and an embedded workflow item that includes nested workflows. When you run the parent workflow and a nested workflow fails, the parent workflow fails too regardless of the default error handling item.
- Slow deletion of folders that contain large quantities of workflows or actions.
When you delete a folder that contains large quantities of workflow or actions (over 2000 objects), the deletion process can take hours to complete.
- Metrics are lost during navigation through workflow run steps for completed workflow runs.
This issue is visible if the workflow profiler and token replay extensions are enabled. If your workflow run calls nested workflows, then no metrics are shown for the parent workflow.
- When there is a limit on the number of fetched items in a plug-in inventory, and you use the tree picker in input forms to show items, the tree picker does not show all the items.
The number limitation prevents the tree picker from showing all the items in the inventory tree. This issue can be encountered with the Active Directory plug-in and other plug-ins in your vRealize Orchestrator inventory.
- The migration of vRealize Orchestrator 8.4.2 environments stops responding on the job.batch/vro-migration created step. This occurs when the environment variable HOSTNAME does not match any of the node selector labels.
This issue occurs when the
HOSTNAMEenvironment variable of the vRealize Orchestrator Appliance does not match the
kubernetes.io/hostnamenode selector labels because the migration
nodeSelectoruses this variable to make sure that the migration pod will be deployed on the node where
vro-migratecommand is called from.
- Unable to properly save variables of the Regexp type in the Variables editor. Incorrect values are displayed in the editor.
This issue is caused by the
Regexptype variables being misinterpreted as special objects instead of strings.
- Older workflows can use the deprecated Path type which cannot be used in newer vRealize Orchestrator versions.
Using the deprecated
Pathtype can cause issues in certain scenarios. For example, you might have a nested workflow element that uses the
Pathtype as an input or output parameter. Attempting to bind these input or output parameters to other parameters or variables that use the
Pathtype fails because this type is deprecated and unavailable. The similar
pathtype variable can now be bound to inputs, outputs, or variables of the
Pathtype. The same also applies to
Array/Pathbindings. In such scenarios, the original input or output type does not change. For example, if an input parameter of the
Pathtype is bound to a variable of the
pathtype, the input parameter will still use the
- Unable to select an action as a default value for a Properties type input parameter.
An action that returns an
Array/Propertiescannot be selected as a default value for a
Propertiestype input parameter.
- Multiple workflows or actions are pushed to the assigned Git repository despite only one object being selected or versioned.
This issue occurs after you reset your Git repository to a previous change set and choose to keep the local changes. The local changes will go into the Git repository together regardless of which object is selected for the push operation.
The known issues are grouped as follows.Install/Migration/Upgrade issues
- Custom content is not available on the Git History page after migrating vRealize Orchestrator 7.5 to vRealize Orchestrator 8.x.
After migrating vRealize Orchestrator 7.5 to vRealize Orchestrator 8.x, when you configure your Git integration, custom content is not available on the Git History page.
Workaround: To see all migrated content as local changes in Git, manually edit and save custom content to convert it to an 8.x-compatible format before you make an initial push to the repository. After that, you can push all migrated content to your Git repository.
- After upgrading to vRealize Orchestrator or vRealize Automation 8.x, some resource elements in the vRealize Orchestrator Client might appear changed or reverted to an older version.
This issue occurs with resource elements that were previously updated in the vRealize Orchestrator Client by using a different source file. After upgrading your vRealize Orchestrator or vRealize Automation deployment, these resource elements can be replaced by an older version. This is an intermittent issue.
1. Log in to the vRealize Orchestrator Client.
2. Navigate to Assets>Resources.
3. Select the resource element affected by the issue.
4. Select the Version History tab and restore the element to the appropriate version.
5. Repeat for all affected resource elements.
- "Add a REST host" workflow fails when trying to add an HTTPS endpoint with a HTTP proxy using basic authentication.
This is intended behavior because of the security vulnerabilities, associated with this type of communication protocol: the possibility of accidentally exposing plain text sensitive data over HTTP.
Workaround: No workaround. This use case is not supported.
- Local changes are not available after duplicating and deleting a workflow.
You duplicate a workflow and then delete it. In the Git History page, there is no local change for the deleted workflow.
- Users can discard Git changes to content they do not have access to.
Users with workflow designer rights can discard Git changes to content that they do not have access to from the Git History page.
- Pushing commits to a protected Git branch fails.
If the configured Git branch is protected, the push operation fails consistently, but the message that appears indicates that the push is successful.
- In the vRealize Orchestrator Client, you see tags containing underscore characters in the name.
The vRealize Orchestrator Client does not support tag names with less than three characters or names containing white-space characters. All tags that are auto-generated from objects with shorter names are suffixed with underscore characters. All white-space characters will also be replaced with underscores. For example, a workflow located in
/Library/project A/app/DR/backupin the Orchestrator Legacy Client, when migrated, has the following auto-generated tags in the vRealize Orchestrator Client: "Library", "project_A", "app", "DR_".
Workaround: Follow the tagging conventions when creating new content in the vRealize Orchestrator Client.
- The vRealize Orchestrator container restarts when over 5000 actions are run for the purpose of catalog item population.
This issue was tested in an environment where 250 catalog items, each running over 20 vRealize Orchestrator actions, were run in parallel. This causes all available Tomcat threads to be exhausted, which in turn causes a vRealize Orchestrator container restart due to a health check probe fail.
- Running any action from a vRealize Orchestrator Client embedded in a vRealize Automation in an external vRealize Orchestrator deployment returns the following: Action execution with id: was not found.
This issue occurs when a user wants to run or debug an action in an external vRealize Orchestrator cluster while triggering it from an embedded vRealize Orchestrator Client. The external vRealize Orchestrator cluster must be added as an integration in vRealize Automation.
Workaround: Use the external vRealize Orchestrator Client to start or debug actions.
- Inconsistent coloration of variables bound in scriptable tasks.
Only the first match of a bound variable included in the code of a workflow scriptable task has coloration.
- Running the Run SSH command workflow in the Multi-node plug-in causes the workflow to fail.
Attaching a remote vRealize Orchestrator instance using the Multi-node plug-in, and running the Run SSH command workflow, which is synchronized from the remote repository, causes the workflow to fail.
Workaround: To make the workflow pass successfully, rename the local variable in the generated workflow for the Run SSH Command final scripting element. The following script is an example fix:
var r = remoteToken.getOutputParameters(); result = r.get("result"); errorText = r.get("errorText"); outputText = r.get("outputText");
- vRealize Orchestrator database size is very large because of the vmo_tokenreplay table.
The vmo_tokenreplay table is very large in size.
Workaround: Log in to Control Center as root. Under Extension Properties, select the token replay extension and disable the Record replay for all workflow runs property.
- Importing a package created in a newer vRealize Orchestrator version into an earlier version of vRealize Orchestrator can cause an error.
Compatibility issues between vRealize Orchestrator versions lead to the inability to import packages created in newer product versions into earlier vRealize Orchestrator deployments.
- You receive an error message when attempting to connect to TLS 1.0 or 1.1 services.
vRealize Orchestrator now uses the TLS 1.2 protocol. Any outgoing connections to external services that use the older TLS 1.0 or 1.1 versions of the protocol can fail with the following error message:
InternalError: The server selected protocol version TLS10/TLS11 is not accepted by client preferences [TLS12].
Workaround: See KB 84201.
- The vRealize Orchestrator Control Center password is reset to its initial value after service redeployment.
After the vRealize Orchestrator Appliance is deployed, you can change the Control Center password by running the
vracli vro update-cc-passwordcommand. However, after running the
/opt/scripts/deploy.shscript to redeploy the vRealize Orchestrator services, the Control Center password is reset to its initial value.
- During the installation of a plug-in in Control Center, an error message appears.
When you install a plug-in from the
Manage Plug-Inspage in Control Center, the error message
Plug-in 'name_of_the_plug-in' (plug-in_file_name) is not compatible with the current platform version. Supported platform versions are ''. Clicking on the 'Install' button will install it anywayappears. You can safely ignore this error and proceed with the installation of the plug-in.
The Orchestrator authentication configuration might become invalid, if the authentication provider certificate changes or regenerates.
When the SSL certificate of the vRealize Automation or vSphere instance that is configured as the authentication provider in Control Center is changed or regenerated, the Orchestrator authentication configuration becomes invalid and the Orchestrator server cannot start.
Workaround: Import the new authentication provider certificate:
- Log in to Control Center as root.
- Click Certificates.
- Click the Import on the Trusted Certificates tab.
- Load the SSL certificate from a URL or a file.
- Click Import.
- The SOAP plug-in cannot connect through an authenticated proxy server.
When you run the
Add a SOAP hostworkflow, use a proxy server that does not require authentication.
If you experience issues connecting to a SOAP or a REST host, or importing a certificate, you might have to explicitly enable certain versions of SSL or TLS.
For information about this issue, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html.
Workaround: For information about explicitly enabling SSLv3 and TLSv1 for outgoing HTTPS connections, see Enable TLSv1 for outgoing HTTPS connections in vRealize Orchestrator 6.0.4 and 7.0.x manually (KB 2144318).
- vCenter Server objects are not accessible in the vSphere Web Client (Flex)
Orchestrator cannot access vCenter Server objects in the vSphere Web Client (Flex), if the vCenter Server instance that you are attempting to access is registered in Orchestrator by IP address.
Workaround: Register the vCenter Server instance by host name.
- The SSH plug-in cannot connect to a Cisco Adaptive Security Appliance (ASA) firewall.
The SSH plug-in for vRealize Orchestrator 7.1 does not support connectivity to a Cisco Adaptive Security Appliance (ASA) firewall.
- Problems handling non-ASCII characters in certain contexts.
Using non-ASCII characters in input parameters results in incorrect behavior in the following situations:
- If you run the SCP put or SCP get workflows from the SSH folder on a file with a name that contains non-ASCII characters, the workflow runs, but name of the resulting file on the destination machine is unreadable.
- If you try to insert non-ASCII characters into attribute names, the characters do not appear. This issue occurs for workflow attributes and action attributes.
- The Storage VSAN workflows of the vCenter Server plug-in do not support adding Solid-State Drive (SSD) disks to an ESXi host.
Add disks to disk groupand
Remove disks from disk groupsworkflows do not support adding SSD disks as capacity disks to ESXi hosts.
Compiling a custom model-driven plug-in fails if you use an extension method that contains lambda expressions.
When you use model-driven to create plug-ins and you add extension methods to a certain extension, the plug-in does not compile if the extension method contains lambda expressions. The plug-in compilation fails with an error message, similar to the following:
Caused by: java.lang.ArrayIndexOutOfBoundsException: 52789.
Workaround: Do not use lambda expressions in the body of the extension methods.
- The RESTOperation ID does not initialize properly if the REST host instance is created by using a Swagger spec.
In the HTTP-REST plug-in, when the REST host instance is created by a Swagger spec, the RESTOperation ID does not initialize properly and the getOperation of the RESTHost object does not work.
The Convert disks to thin provisioning workflow does not handle virtual machines with snapshots correctly and does not convert the thick-provisioned disks.
On completion, the Convert disks to thin provisioning workflow reports that the thick-provisioned disks of virtual machines with snapshots are successfully converted to thin-provisioned, but they are not.
Workaround: Do not include virtual machines with snapshots in the workflow.
- Adding values to vCenter Server data object properties of the Array type is not possible.
For example, the following code does not work:
var spec = new VcVirtualMachineConfigSpec();
spec.deviceChange = ;
spec.deviceChange = new VcVirtualDeviceConfigSpec();
In the above code, Orchestrator converts the empty
VirtualDeviceConfigSpecbefore it calls
setDeviceChange(). When calling
spec.deviceChange = new VcVirtualDeviceConfigSpec(), Orchestrator calls
getDeviceChange()and the array remains a fixed, empty Java array. Calling s
pec.deviceChange.add()results in the same behavior.
Workaround: Declare the array as a local variable:
var spec = new VcVirtualMachineConfigSpec();
var deviceSpec = ;
deviceSpec = new VcVirtualDeviceConfigSpec();
spec.deviceChange = deviceSpec;
- Passing a VcSnapshotInfo object as an attribute of type Any between two workflow elements causes an exception during serialization
In the vCenter Server plug-in, passing a
VcSnapshotInfoobject or an array of
VcSnapshotInfoobjects as an attribute of type
Anybetween two workflow elements triggers a serialization that fails with a
Can not set long field com.codahale.metrics.error message.
Workaround: Change the workflow to omit passing a
VcSnapshotInfoobject or an array of
VcSnapshotInfoobjects between the workflow elements.