VMware

VMware vCloud Automation Center® 5.2.2 (5.2.5 Build 104) Release Notes

vCloud Automation Center 5.2.2 | 12 JUNE 2014 | 5.2.5 Build 104

What's in the Release Notes

The release notes cover the following topics:

What's New

  • Bulk Import
  • You can import one or more virtual machines to a vCloud Automation Center deployment. The machines are imported intact with defining data such as reservation, storage path, blueprint, owner, and any custom properties. For more information on the Bulk Import feature, see vCloud Automation Center 5.2.2 Operating Guide.

  • XenDesktop 7.0 support
  • This release supports XenDesktop 7.0.

  • Windows Server 2012 R2 as a guest operating system and .NET 4.5.1 support for vCloud Automation Center installation
  • Support for Windows Server 2012 R2 as a guest operating system and .NET 4.5.1 for vCloud Automation Center installation is added for this release.

  • vCloud Director endpoint management enhancements
  • If you provision a vApp component by using vCloud Director endpoint, you can now add a new network or reconfigure an existing network from the Reservation.

  • vCloud Automation Center prevents Infrastructure Organizer from taking a host out of management that has a reservation defined
  • When a host is having a reservation defined, vCloud Automation Center does not allow enterprise administrators to edit enterprise groups for that particular host.

  • Storage cost is displayed in chargeback reports for vCloud Director vApps
  • vCloud Automation Center 5.2.2 release includes the custom Gugent that contains version.txt and a zipped EXE file

System Requirements and Installation

For information about supported host operating systems, databases, and Web servers, see the vCloud Automation Center Support Matrix.

For additional prerequisites and installation instructions, see vCloud Automation Center 5.2.2 Installation Guide.

Resolved Issues

This section describes issues resolved in vCloud Automation Center 5.2.2.

  • Upgrading vCloud Automation Center 5.2 or 5.2.1 to 5.2.2 shows wrong version in Windows Programs and Features
    Upgrading from vCloud Automation Center 5.2 or 5.2.1 to vCloud Automation Center 5.2.2 uses a patch process. As a result, the version number does not change for any of the vCloud Automation Center components displayed in Windows Programs and Features after the update is complete.

  • This issue has been fixed in this release.

  • File access error appears during the upgrade process
    During an upgrade from vCloud Automation Center 5.2 or 5.2.1 to vCloud Automation Center 5.2.2, the installer sometimes displays an error message about not being able to access a file.

  • This issue has been fixed in this release.

  • Timeout occurs in the repository log and Windows Event Viewer
    If you create virtual machines by using automated solution of vCloud Automation Center and then navigate to Enterprise Machines in the user interface, the machines are not created, but they appear in the database and in vCenter Server. Both the repository log and Windows Event Viewer shows timeouts after you select this view in the vCloud Automation Center console.

  • This issue has been fixed in this release.

  • Adding a component to an existing multi-machine gets stuck intermittently
    During the creation of multi-machine or after the creation of multi-machine if you add a new component machine, sometimes this component machine gets stuck in InitializingRequest state and the only way to unblock it is to dispose the machine.

  • This issue has been fixed in this release.

  • Snapshot operation fails if maximum value for storage reservation is left blank

    This issue has been fixed in this release.

  • Administration portal of vCloud Automation Center does not allow storage group selection on provisioning

    This issue has been fixed in this release.

  • Event queue operation fails and an error message is displayed
    The event queue operation fails and an error message QueueNotFound for queue WorkflowUpgradeComplete is displayed.

  • This issue has been fixed in this release.

  • Error occurs when you try to create a new blueprint from a copy of the same existing blueprint
    If you add build profile twice onto a blueprint and then try to copy the same from existing blueprint then the error occurs and Context is already tracking the relationship message is displayed.

  • This issue has been fixed in this release.

  • Adding components to a multi-machine service cannot be completed when multiple and different runtime property dictionaries are included on each component

    This issue has been fixed in this release.

  • Template limit is not working for non-administrator accounts
    When you log in as an administrator and if there is a limit on the number of deployments for a blueprint, you are notified that you are not allowed to deploy any more blueprints after the limit is reached. If you login as a standard user, the limit is noted but you are able to deploy beyond the listed limit.

  • This issue has been fixed in this release.

  • Sending of e-mails fails if a user is removed from the Active Directory and a machine is in the expired state
    When a user is removed from the Active Directory and a machine is in the expired state, sending of emails fail and an error message is displayed.

    [timeframe] since user was deleted -> 3/18/2014 11:54am (changed owner of machine) [3/16/2014 6:47:28 AM] [Debug]: Error quering current AD GC with filter [(&(objectclass=user)(samAccountName=sgarve))]: [System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational. at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) at DynamicOps.External.ActiveDirectory.ActiveDirectoryHelper.FindResults(String filter, Forest forest)]

  • This issue has been fixed in this release.

  • Customization to extend space on machines cause failure
    An issue with customization occurs where it tries to add a disk where the disk already exists.

  • This issue has been fixed in this release.

  • When a user does not exist on the initial global catalog, vCloud Automation Center searches for additional catalogs and the catalogs break when one catalog is non-responsive

    This issue has been fixed in this release.

  • Drop-down menu in self-provisioning portal never displays the first entry
    When you request a new machine through the Self Provisioning portal, this machine is on the Additional Settings page. The first entry in the list of drop-down menu does not populate with rest of the values.

  • This issue has been fixed in this release.

  • Provisioning of a new user in vCloud Director always fails for the first request
    When a new user requests their first machine in vCloud Director, the request always fails. After the first machine request all subsequent requests succeed. If you add the user to vCloud Director first, then the first machine request succeeds.

  • This issue has been fixed in this release.

  • Requesting or reconfiguring workflows fail when memory size is not multiple of four

    This issue has been fixed in this release.

    This section describes issues resolved in previously released hotfixes. All of the following resolved issues are included in this release.

    Hotfix 3

    • The OpenSSL version has been upgraded to 1.0.1g from 1.0.1c.

    Hotfix 2

    • SQL timeout error occurs in the repository log. A hotfix to patch the DLL file has been provided.

    Hotfix 1

    • Cannot create vApp with 2NIC / 2Network after the application vCloud Automation Center 5.2 Hotfix 4. After the application of vCloud Automation Center Hotfix 4, when you try provision catalog which have 2NIC / 2Network, an error message appears and the creation of vApp fails. A hotfix has been provided for this issue.

    Known Issues

    The following items are known issues in this release.

    The known issues are grouped as follows:

    Installation

    • Remote DEM worker service does not start after installation
      The default port for the vCloud Automation Center server is 443. If the vCloud Automation Center server is installed on a different port and the installation certificate for the DEM Worker does not specify the port where the vCloud Automation Center server is installed, the DEM worker does not start.

    • Workaround: Perform one of the following tasks:

      • Install the vCloud Automation Center server using the default port 443.
      • Install the vCloud Automation Center using a port that is different from the default, and install the certificate for the DEM Worker specifying that port.

    Upgrade

    • Windows Preinstallation Environment (WinPE) does not support upgrade from vCloud Automation Center 5.2 or 5.2.1 to vCloud Automation Center 5.2.2
      Workaround: You must uninstall WinPE before upgrading to vCloud Automation Center 5.2.2. You must reinstall WinPE after the upgrade process is complete. See the "Rebuild WinPE Images," topic related to Upgrading to vCAC 5.2.2 in the vCloud Automation Center Installation Guide.

    Server Configuration

    • AppServiceState fails with a message: Not enough storage is available to process this command
      Error conditions might occur when the .NET workflow execution engine in DEM workers attempts to load a workflow for execution.
      Workaround: Three configuration properties provide a way to fine tune DEM workers to respond efficiently to workflow problems. A DEM worker can be configured to detect when an error condition occurs and to automatically restart so that the work does not stop. A DEM worker can be configured to wait a specified time period for running workflows to finish. Workflows still running when the timeout period ends are cancelled. A DEM worker can also be configured to unclaim a workflow if it fails and return the failed workflow to the DEM orchestrator queue. For this functionality to work, the following properties need to be configured in the DEM worker configuration file located at vcac_install_dir\VMware\vCAC\Distributed Execution Manager\%WorkerInstance%\DynamicOps.DEM.exe.config.

    • Name Display Name Description Value Format
      DEM.FailureExceptions Failure Exceptions The exceptions specified to trigger a DEM stop <add key="FailureExceptions" value="[ExceptiontypeName1]:[MaxFailureCount1]:[ShouldUnclaim1][;ExceptiontypeNameN]:[MaxFailureCountN]: [ShouldUnclaimN]"/>

      Where:

      ExceptiontypeName1. The name of the exception type seen in an error message. Cut and paste the exception type name here, for example, System.Xaml.XamlObjectWriterException. You can specify multiple exception type names. Valid value: Name of the exception type as it appears in the error message.

      MaxFailureCount1. The maximum number of times the exception occurs before the DEM stops. For each exception type name, you can specify a MaxFailureCount number. Valid value: A positive integer.

      (Optional) ShouldUnclaim1. Indicates whether the DEM returns the failed workflow to the queue for the next available DEM to execute. For each exception type name, you can enter a value for ShouldUnclaim. Valid values TRUE for the failed workflow to return to the queue, or FALSE for the failed workflow not to return to the queue. Valid values: TRUE or FALSE. The default value is FALSE.

      Example:
      <add key="FailureExceptions" value="System.Xaml.XamlObjectWriterException:1" />
      DEM.ClosedownTimeoutSeconds Closedown Timeout Seconds The number of seconds after a specified exception occurs before the DEM stops <add key="ClosedownTimeoutSeconds" value="[TimeoutInSecondsBeforeDEMClosesDown]"/>

      Where:

      TimeoutInSecondsBeforeDEMClosesDown is the number of seconds after the specified exception occurs before the DEM stops. Specify a time interval long enough to ensure that all running workflows are completed before the DEM stops. Valid values: A positive integer. The default value: 0.

      Example:
      <add key="ClosedownTimeoutSeconds" value="30" />
      DEM.RestartOnFailure Restart on Failure Trigger a full restart of the DEM <add key="RestartOnFailure" value="[WhetherToRestartDEMonFailure]"/>

      Where:

      (Optional) WhetherToRestartDEMonFailure specifies whether the DEM stops or performs a full restart when one of the exceptions specified in the FailureExceptions occurs. To specify a full restart, the DEM service account must have administrative privileges on the machine hosting the DEM. Specify TRUE for the DEM to perform a full restart. Specify FALSE for the DEM to stop. Valid values: TRUE or FALSE. The default value is TRUE.

      Example:
      <add key="RestartOnFailure" value="FALSE"/>

    Virtual Machine Management

    • Unable to dispose of a virtual machine that has pending work items after upgrade to vCloud Automation Center 5.2.2
      Upgrading to vCloud Automation Center 5.2.2 does not make it possible to dispose of previously undisposed virtual machines. Contact Customer Support for information about disposing these undisposed virtual machines manually.

    • Expire operation does not power off a vApp or virtual machine
      When you manually expire a vApp or virtual machine that has an archive period defined in vCloud Automation Center, vCloud Automation Center fails to destroy the machine. vCloud Automation Center reports that the machine has powered off, even though the machine is on.
      Workaround: Power off the vApp or virtual machine manually in your hypervisor to prevent errors during deletion, and manually delete the vApp or virtual machine in vCloud Director.

    • Virtual machines or vApps that fail the import process no longer appear in the import wizard
      When importing virtual machines or vApps into vCloud Automation Center are unsuccessful, the machines that are not imported no longer appear in the import wizard. As a result, you cannot attempt to re-import the machines or vApps.
      Workaround: Perform an inventory data collection of vSphere and vCloud Director, and then re-import the machines.

    • Problem results when a vApp with multiple component virtual machines fails to import one or more component machines
      If a vApp with multiple component virtual machines is imported into vCloud Automation Center, but the import process fails for one or more component machines, each virtual machine that failed the import process cannot be imported into vCloud Automation Center.

    • Destroy operation is unsuccessful in deleting multi-machine provisioned using multi-machine service
      The destroy operation in the vCloud Automation Center console to delete a multi-machine sometimes might not delete the multi-machine completely.
      Workaround: If clicking Destroy in the vCloud Automation Center console does not remove the multi-machine completely, click Destroy again.

    • vApp creation fails as vCloud Automation Center does not check for case sensitivity of the network name in the Custom Property
      vCloud Automation Center does not check for case sensitivity of the network name that you provide in Custom Property. As a result, vApp creation fails on vCloud Director and an error message is displayed in vCloud Automation Center.

    • Attempts to delete a vApp whose component machine is in reconfigure state results in vApp getting stuck in disposing state
      If you attempt to delete a vApp whose component machine is in reconfigure state, an error message is displayed and the vApp remains in disposing state and does not get disposed.
      Workaround: After all component vApps complete the operations that they were performing, click Destroy again. This removes the vApp component virtual machines and the vApp.

    • Cannot add a component machine to a multi-machine when there are IP addresses available in different network profile, but no available IP addresses in the network profile from which the IP addresses are allocated to multi-machine
      When a multi-machine is provisioned with IP addresses from a network profile, you cannot add a component machine after the IP addresses in the network profile are exhausted. Attempts to add a new component machine are unsuccessful even if another network profile has unallocated IP addresses.
      Attempting to add a new component machine in this situation generates an error message stating that all of the IP addresses in the network profile have been exhausted.