vRealize Orchestrator Appliance 8.4.2 | 24 June 2021 | Build 18188170

vRealize Orchestrator Update Repository 8.4.2 | 24 June 2021 | Build 18188170

Check frequently for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:


Upgrade failure after performing steps in KB 87120

Performing the instructions used to address the CVE-2021-44228 and CVE-2021-45046 log4j vulnerabilities described in KB 87120 can cause upgrade failures for vRealize Automation and vRealize Orchestrator 8.6.2 or earlier. For a workaround, see KB 87794.

What's New in vRealize Orchestrator 8.4.2

The vRealize Orchestrator 8.4.2 release focuses on maintenance and bug fixes.

New optional time zone parameter

An optional time zone parameter can now be added to the scheduleRecurrently method used by workflow objects. The time zone parameter can be either a string matching a Java TimeZone ID, or one of the properties of the newly created TimeZone object, which are autocompleted in the vRealize Orchestrator Script Editor. When a string that does not match a time zone id is provided or no time zone is provided, UTC is used as a default value.

Deploying the VMware vRealize Orchestrator 8.4.2 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.4.2

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

The following plug-ins are installed by default with vRealize Orchestrator 8.4.2.

  • vRealize Orchestrator vCenter Server Plug-In 6.5.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.4.2
  • 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:

Resolved Issues

  • HTTP-REST requests fail with a "Cannot execute the request" error.

    Requests to HTTP-REST hosts, which have the concurrent requests setting switched on and do not use Basic authentication, can encounter an error that causes the requests to fail.


  • Scheduled workflow runs are triggered at a different than the expected time with the time offset to UTC time.

    When you schedule workflow runs through scripting by using the *workflow.scheduleRecurrently()* function, scheduled workflows are always triggered in UTC time. There is a discrepancy between the vRealize Orchestrator Client UI and the function behavior because the UI adds the time zone of your browser to the recurrence pattern. However, the time zone is not included in the recurrence pattern when using the function and the calculations of the time to the trigger the workflow runs are done on the server side in UTC time.

  • You are unable to select an action as an external source in workflow input forms if that action returns an array of plug-in SDK types.

    In the Input Form tab, you are unable to select an action that returns an array of reference objects for a default value and value options in the multi value picker component.

  • Plug-in DAR files are missing from the secondary nodes after migration.

    After migration, the plug-in DAR files are missing from the secondary nodes of your clustered vRealize Orchestrator deployment.


Known Issues

The known issues are grouped as follows.

Install/Migration/Upgrade issues
  • 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.

    Workaround: The migration logs can be found in the /data/vco/usr/lib/vco directory on the secondary nodes of the clustered environment. If the logs are not there, they can be found in the /var/log/vmware/prelude directory on the node where the migration process is started.

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

  • 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 HOSTNAME environment variable of the vRealize Orchestrator Appliance does not match the kubernetes.io/hostname node selector labels because the migration nodeSelector uses this variable to make sure that the migration pod will be deployed on the node where vro-migrate command is called from.

    Workaround: Replace the line where the HOSTNAME environment variable is used by the nodeSelector with a script that will return the correct hostname of the node where you plan to call vro-migration command from.

    1. Search for kubernetes.io/hostname in the /usr/local/sbin/vro-migrate script.
    2. Edit the kubernetes.io/hostname value to be $(current_node) instead ${HOSTNAME} and save the changes.
      kubernetes.io/hostname: $(current_node)
Web client issues
  • 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 VMHost PowerCLI object that cannot be parsed into a JSON format.

    Workaround: Redirect the output of commands to either the stdout or out-null variable, as not to pollute the output stream with these objects, which will cause the script to fail.

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

    Workaround: To delete the workflow or action more quickly, use the force deletion option.

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

    No workaround.

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

    Workaround: No workaround. Wait for the process 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.

    No workaround.

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

    No workaround.​

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

    Workaround: Use the value picker in input forms.

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

    No workaround.

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

    No workaround.

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

    No workaround.

  • 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/backup in 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.

  • Older workflows can use the deprecated Path type which cannot be used in newer vRealize Orchestrator versions.

    Using the deprecated Path type can cause issues in certain scenarios. For example, you might have a nested workflow element that uses the Path type as an input or output parameter. Attempting to bind these input or output parameters to other parameters or variables that use the Path type fails because this type is deprecated and unavailable. The similar path type variable can now be bound to inputs, outputs, or variables of the Path type. The same also applies to Array/path and Array/Path bindings. In such scenarios, the original input or output type does not change. For example, if an input parameter of the Path type is bound to a variable of the path type, the input parameter will still use the Path type.

    Workaround: Use the string type for file paths wherever possible instead of Path or path types as they are deprecated.

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

    No workaround.

  • Unable to select an action as a default value for a Properties type input parameter.

    An action that returns an Array/Properties cannot be selected as a default value for a Properties type input parameter.

    Workaround: Change the return type of the action to a Properties type, select it as a default value and then change it back to Array/Properties.

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

    Workaround: Make sure to either push or discard the local changes in your Git repository before resetting the branch to an old change set.

  • Duplicated workflows created in Orchestrator Legacy Client might display a constant instead of an external action in their value options.

    When editing the input parameters of a workflow that is designed in the Orchestrator Legacy Client, and duplicated in the vRealize Orchestrator Client, the value options might be set as a constant instead of an external action.

    Workaround: Navigate to the Input Form tab and edit the input parameter presentation to include the required external action.

  • Workflow with a Properties input parameter type and widget multi value picker does not fill the widget correctly when using a default value action returning the Properties type.

    Using an action returning a Properties type as the default value of a multi value picker widget results in having empty keys in the value column.

    Workaround: Use an action that returns an Array/Properties type.

  • Unable to select an action as an external source in input forms because of a return type issue.

    In the vRealize Orchestrator Client Input Form tab, you are unable to select an action that has a return type of either Any or Array/Any for a default value or value option.


    1. Log in to the vRealize Orchestrator Client.
    2. Select your workflow and navigate to the Input Form tab.
    3. Set the action with the return type expected from the widget default value or value option and save the changes.
    4. Select the default value or value option action, save the workflow, and revert the action to previous version or change the return type back to the Any type.

Miscellaneous Issues
  • 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.

    No workaround.

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

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

    Workaround: Do not use backslash ("\") characters in the root password of your vRealize Orchestrator deployment.

Previously known issues

To view a list of previous known issues, click here.

check-circle-line exclamation-circle-line close-line
Scroll to top icon