check-circle-line exclamation-circle-line close-line

vRealize Orchestrator Appliance 8.2 | 06 October 2020 | Build 16995073

vRealize Orchestrator Update Repository 8.2 | 13 October 2020 | Build 17015463

Check frequently for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

What's New in vRealize Orchestrator 8.2

vRealize Orchestrator 8.2 is mostly maintenance and stabilizing release. You can now edit workflows and actions directly from the parent workflow that references them. For more information, see Edit Workflows and Actions from the Parent Workflow.

Offensive Language Notice

At VMware, we value inclusion. To foster this principle within our customer, partner, and internal community, we removed non-inclusive language from our documentation.

Feature Notice

The workflow token replay feature is now disabled by default. You can run token replays for each workflow run individually, or enable the feature for all workflow runs from the vRealize Orchestrator Control Center. For more information, see Using Workflow Token Replay in the vRealize Orchestrator Client.

Deploying the VMware vRealize Orchestrator 8.2 Appliance

The vRealize Orchestrator Appliance is a VMware PhotonOS-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.2

You can upgrade a standalone or clustered vRealize Orchestrator 8.0 or 8.0.1 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.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.

Root Password Expiry Extension

Important: For security reasons, the password expiry of the root account of the vRealize Orchestrator Appliance is set to 365 days. To increase the expiry time for an account, log in to the vRealize Orchestrator Appliance as root, and run the following command:

passwd -x number_of_days name_of_account

To make your vRealize Orchestrator Appliance root password last forever, run the following command:

passwd -x 99999 root

Plug-Ins Installed with vRealize Orchestrator 8.2

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

  • vRealize Orchestrator vCenter Server Plug-In 6.5.0
  • vRealize Orchestrator Mail Plug-In 7.0.3
  • vRealize Orchestrator SQL Plug-In 1.1.5
  • vRealize Orchestrator SSH Plug-In 7.2.0
  • vRealize Orchestrator SOAP Plug-In 2.0.2
  • vRealize Orchestrator HTTP-REST Plug-In 2.3.8
  • vRealize Orchestrator Plug-In for Microsoft Active Directory 3.0.11
  • vRealize Orchestrator AMQP Plug-In 1.0.4
  • vRealize Orchestrator SNMP Plug-In 1.0.3
  • vRealize Orchestrator PowerShell Plug-In 1.0.18
  • vRealize Orchestrator Multi-Node Plug-In 8.2.0
  • vRealize Orchestrator Dynamic Types 1.3.6
  • vRealize Orchestrator vCloud Suite API (vAPI) Plug-In  7.5.2

Internationalization Support

vRealize Orchestrator 8.2 provides multi-language support for the vRealize Orchestrator Control Center and the vRealize Orchestrator Client.

How to Provide Feedback

Your active feedback is appreciated. Provide your feedback by using one of the following methods:

Support Requests

File all issues that you find as Support Requests (SRs), even if you report them to VMware by other means.

For more information on VMware Support and instructions on how to file SRs, please visit the official VMware Support Offerings page.

Include log files in your SRs.

To generate your vRealize Orchestrator logs:

1. Log in to the vRealize Orchestrator Appliance command line as root.

2. Run the vracli log-bundle command.

Result: The log bundle is generated in the root folder of the vRealize Orchestrator Appliance.

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

  • Unable to load more than 20 object cards from Card View.

    If you configure your display to use a 2K resolution and above, or a custom resolution that is more than 1080 pixels in height, the Card View cannot load more than 20 cards.

     

  • Duplicated folders appear in Tree View in an embedded vRealize Orchestrator Client after upgrading a High Availability (HA) vRealize Automation 8.0.1 environment.

    After upgrading to vRealize Automation 8.1, multiple folders with identical names appear in the Tree View of the embedded vRealize Orchestrator Client. One of the folders is used while the other folders might be empty. A similar issue can also occur with fresh HA vRealize Automation 8.1 deployments.

  • Running a workflow with a legacy presentation validation fails when the ognl uses the "__current" variable.

    Workflows created in the Orchestrator Legacy Client that use the "__current" variable in their OGNL custom validation script fail to start from the vRealize Orchestrator Client when the field value is an SDK object.

     

  • Pull and push operations take a long time to finish.

    In some cases, pull and push operations from the vRealize Orchestrator Client to the integrated Git server continue for 2 minutes.

     

  • Properties and Array/Properties types cannot have default external source values.

    Using external values for Properties and Array/Properties types in the workflow input form does not show the correct actions. Even if you are able to set the correct action, the input form is populated with invalid values during validation.

     

  • Breakpoints are enabled in visual diff view in Version History.

    You can place element and scriptable task breakpoints in the visual diff view.

     

  • Missing Duplicate button in Tree View.

    When you select folders or individual objects in Tree View, the Duplicate button is missing.

     

  • Built-in actions cannot be duplicated.

    If you edit actions that come with the standard vRealize Orchestrator library, you must first duplicate the relevant action. You are not able to duplicate the action because the Duplicate button is missing from the action card.

  • The Version History page displays inaccurate data for the current version. After performing a push operation, the last change made to the content disappears. 

    This error can occur when multiple object editors are open at the same time and one or more users are making changes. For example, you might make changes to a vRealize Orchestrator workflow and a vRealize Orchestrator action in separate tabs in your browser. After you make several changes to both the workflow and the action, you save your changes to the workflow. When you push the updated workflow to the integrated Git repository, the action changes you saved are lost.

  • You are logged out of the vRealize Orchestrator Client even though there is activity in the browser window.

    Your session times out and you are logged out when there is a prolonged period of inactivity in the browser. By default, that period is set to 25 minutes. If you have multiple browser tabs or browser windows opened to the same application, the inactivity time out is counted separately for each tab or window. Therefore, you are logged out of your session even though you are active in one of the tabs. 

  •  Actions that are part of the Input Form of a workflow are missing from the package that contains the workflow.

     Actions that are part of the Input Form of a workflow are missing from the package that contains the workflow.

Known Issues

The known issues are grouped as follows.

Configuration Issues
  • The vRealize Orchestrator Control Center container fails to start and cannot be opened in the browser.

    This issue is caused by an error in the in /data/vco/usr/lib/vco/configuration/log/catalina.log file.

    Workaround:

    1. Restart the vco-app pod that got stuck by running the following command.
      kubectl -n prelude delete pod vco-app[id]
    2.  After a few seconds, the pod is destroyed and a new pod is deployed.
      * vco-app-[id_new_deployment]         3/3    Running       30          4d6h
Migration/Upgrade issues
  • When migrating vRealize Orchestrator 7.4 to vRealize Orchestrator 8.2, the local changes to actions and resources on the Git history page are empty.

    When migrating vRealize Orchestrator 7.4 to vRealize Orchestrator 8.2, the local changes to actions and resources in the Git history page are empty. The content is not available.

    Workaround: Migrate your vRealize Orchestrator instance first from 7.4 to 8.1 HF1/HF2, and then upgrade to 8.2.

  • Plug-in content might be detected as local changes in Git when using the vRealize Orchestrator Git integration.

    After installing vRealize Automation or vRealize Orchestrator 8.1 Patch 3, workflows and actions from the vCenter Plug-in are detected as local changes in Git, such as Workflows/Library/vCenter/Virtual Machine management/Device Management/Add CD-ROM/workflow.xml.

    No workaround.

  • Kubernetes pods for vco-app- fail with a CrashLoopBackOff status after a vRealize Automation 8.1 patch deployment

    The vco-app-xxx log includes entries similar to the following:

    [ERROR] ERROR: duplicate key value violates unique constraint "uk_vmoreselt"
      Detail: Key (tenantid, categoryid, name)=(__SYSTEM, 8a7482a57310c83401733xxxxxxxxxxxxx, configuration.json) already exists.
      Where: SQL statement "UPDATE vmo_resourceelement
         SET categoryid = '8a7482a57310c83401733xxxxxxxxx'
        WHERE categoryid IN ( SELECT t.id FROM Tree t WHERE t.id != '8a7482a57310c83401733xxxxxxxxxxx' AND t.name = 'SecurityModel' AND t.level = '11' AND t.parentcategoryid = '8a7482a57310c83401733xxxxxxxxxx' AND t.tenantId = '_SYSTEM' ) and tenantid = '_SYSTEM'"

    Workaround:

    1. Log in to the Posgres DB of the vRealize Automation Appliance.
    2. Locate the vco-db password:   
      • Run the kubectl get secret db-credentials -n prelude -o yaml command.   
      • Locate the vco-db value and decrypt it (echo “vco-db value” | base64 --decode )
    3. To navigate to the Postgres pod console, run the kubectl exec -it postgres-0 /bin/bash -n prelude command. 
    4. To log in to ebs-db, run the psql -U vco-db -h localhost command.
    5. Clean up the database.
      • Check the entry with the following categoryid: SELECT name, categoryid FROM          vmo_resourceelement ORDER BY name   
      • Delete the entry with the following categoryid: DELETE FROM vmo_resourceelement WHERE categoryid ‘8a7482a57310c83401733xxxxxxxx’.    
  • When migrating vRealize Orchestrator 7.4 to version 8.1 patch 3 or version 8.2, system workflows are detected as local changes in Git History.

    The system workflows that are migrated from version 7.4 to version 8.1 patch 3 or version 8.2 are detected as local changes in Git History.

    No workaround.

  • After upgrade, the category "Waiting for input" shows zero workflow tokens.

    After upgrade, the number of tokens in a Waiting state that appear in the Workflow Runs and Waiting for input categories is different. 

    No workaround.

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

  • Workflow logs do not change when you select elements from the workflow schema.

    When you select elements from the workflows schema, the logs do not change. They appear only on the first selected element.

    Workaround: Enable token replay and select the element from the token Tree View.

  • Workflow validation errors persist for workflows even after resolving the errors.

    Validation errors do not disappear from the workflow schema after resolving the errors and saving the validated workflow.

    No workaround.

  • Receiving errors when running custom decision element scripts with the new runtimes.

    Runtimes other than JavaScript do not support custom decision element scripts. 

    Workaround: Do not add custom decision scripts to Python, Node.js, or PowerShell scripts.

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

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

  • Some content imported from vRealize Orchestrator 7.6 cannot be deleted in vRealize Orchestrator 8.0.

    Library workflows imported from vRealize Orchestrator 7.6 to vRealize Orchestrator 8.x cannot be deleted as a dependency of a custom content as those Library workflows are read-only. You might want to delete them as they existed in vRealize Orchestrator 7.6 and do not exist in vRealize Orchestrator 8.x but are imported with the package. Git errors can occur in relation to some of these workflows using characters that were valid in vRealize Orchestrator 7.6 but not vRealize Orchestrator 8.

    Workaround: Before exporting, delete the library workflows from the package. Alternatively, before importing, you can unselect library workflows from the import. If you did not use either of these workarounds, you can restore the last vRealize Orchestrator database backup before the import.

  • Local changes are not available after duplicating and deleting a workflow.

    You duplicate a workflow and then delete it. In Git history, there is no local change for the deleted workflow.

    No workaround.

  • Switching an active repository to inactive, and then back to active again, causes an error while trying to push local changes.

    Changing the state of the repository may cause an error on the next commit to repository. The error message can be the following: "Error: Push to remote failed with status: REJECTED_NONFASTFORWARD".

    Workaround: First pull, and then push local changes.

  • Resource element details cannot be updated.

    The vRealize Orchestrator Client does not support updating the following resource element properties: name, description, version (not visible in the UI), mime type.

    No workaround.

  • After upgrading to vRealize Orchestrator or vRealize Automation 8.2, some resource elements in the vRealize Orchestrator Client might appear changed or reverted to an older version.

    After upgrading to vRealize Orchestrator or vRealize Automation 8.2, some resource elements in the vRealize Orchestrator Client might appear changed or reverted to an older version. This problem 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.

    Workaround:

    1. Log in to the vRealize Orchestrator Client.

    2. Navigate to Assets>Resources.

    3. Select the resource element affected by the problem.

    4. Select the Version History tab, and restore the element to the appropriate version.

    5. Repeat for all affected resource elements.

Miscellaneous Issues
  • vRealize Orchestrator database size is very large because of the vmo_tokenreplay table.

    The vmo_tokenreplay table is very large in size.

    Workaround: Go to Control Center. Under Extension Properties, enter tokenreplay and disable the Record replay for all workflow runs property.

  • When importing packages that are larger in size than allowed, you see a message stating that the upload failed with a status code 500.

    By default, the maximum size for imported packages is 50 MB. If you try to import packages that are larger than 50 MB, you see a message that the upload failed.

    No workaround.

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

  • The vCenter Server plug-in does not support policies.
    The vCenter Server plug-in for vRealize Orchestrator does not support using policies to monitor for events that are issued by the managed vCenter Server instance.
  • 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.

    No workaround.

Previously known issues

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