Horizon DaaS Platform 7.0 Release Notes

VMware Horizon Horizon DaaS Platform | 2 MAR 2017

Release notes last updated on 06 DEC 2017

Check for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

IMPORTANT: Snapshot Required Prior to Upgrade

Before you begin the upgrade procedure, you must take a snapshot of all service provider appliances. This is required to protect system data in case you encounter issues during upgrade. See the upgrade section of the Horizon DaaS platform 7.0 Service Provider Administration guide for more information.

Note for Users with Session-Based Pools

If you are upgrading from Horizon DaaS Platform 6.1.6 to 7.0.0 and have session-based pools (i.e. assignments) in your configuration, you may have to perform a migration process to complete the upgrade process. See KB #2150366 for more information.

Support for VLAN, VXLAN, and DVS Network Modes

Horizon DaaS Platform supports configurations using any one of the following network modes: VLAN (all appliances on VLAN type network), VXLAN (all appliances on VXLAN type network), or DVS (all appliances on DVS type network).

Product Documentation Now Online

New Documentation Page on VMware.com

There is now a documentation page on VMware.com, which serves as a portal to user documentation for all supported versions of the product. The URL of this page is https://www.vmware.com/support/pubs/horizon-daas-platform-pubs.html. Documentation will no longer be posted on the product Download site.

User Access to Online Help

The Horizon DaaS Platform 7.0 Documentation Center, which is launched when users click the help icon in the Administration Console user interface, is located here: https://pubs.vmware.com/horizon-daas-platform-70/index.jsp.

If users will be using Horizon DaaS Platform behind a firewall, you must make sure that they are able to access the URL above in order to view the documentation.


Prerequisites for upgrading to Horizon DaaS Platform 7.0 are as follows:

  • All appliances and domain controllers must be synchronized to an accurate time source using the NTP protocol. Ideally a common NTP time source should be used.

  • All appliances must be able to perform forward and reverse DNS lookups for each domain controller’s fully qualified hostname that is contactable from the appliance public network.

Note: Horizon DaaS Platform 7.0 uses GSSAPI by default. To disable it, set the fabric.ad.disable.gssapi policy to “true” in the Service Center.

New Features

Tenant Administration Features

Administration Console Replacing Enterprise Center

The Administration Console has now replaced the Enterprise Center as the tenant administration user interface. The console provides a streamlined experience and makes your DaaS system faster and easier to use for image management, desktop and application setup, user entitlement, and system status monitoring.

The console is divided into four parts:

  • Monitor – View user and system activities.

  • Assignments – Configure pools of RDSH applications, dedicated and floating VDI desktops, and RDSH session desktops. Assignments are a bundling of desktop model, pool type, image or applications, and user entitlements.

  • Inventory – View desktop model allocation and available capacity, manage images (previously known as gold patterns), and view RDSH application catalog.

  • Settings – Update account information such as domain registration, active directory, two-factor authentications, and general settings.

Note: There is no imported desktop pool in the Administration Console, so the option to create gold patterns (now called images) from imported desktops is no longer available.

Custom Applications

Customers who wish to use remote applications invoked via an executable path on an RDSH Server VM can now define and associate these remote application settings with an RDSH image in the Application catalog. This Custom Application definition can be used for invoking centrally managed virtualized applications such as Thinapps, as well as registering remote applications that have been installed on RDSH VMs after pool provisioning. There are now two application types:

  • Remote applications are those imported from an RDSH image that you published after adding applications to the image. This is the previously existing functionality.

  • Custom applications are added by specifying their names and paths on the image, using new functionality on the Applications page. This is not recommended, but can be used in some situations such as Thin App launches.

To facilitate custom applications, the following items have been added to the Applications page in the Administration Console (Inventory > Applications).

  • Three new buttons in the upper left of the page: New, Edit, and Delete.

    Note: The Edit and Delete functions are only for Custom applications.

  • The Type column in the application list, which identifies the type of each application (Remote or Custom) and allows you to sort by application type.

Add a Custom Application
  1. Click the New button at the top of the Applications page.

    The first New Application dialog appears.

  2. Click Custom.

    Note: The other option is click Image to open the Images page, where you can install applications on an existing RDSH image and then publish it.

    The second New Application dialog appears.

  3. Enter information as described below (optional fields marked with *).
    NameUnique name for the new application.
    Application PathLocation of the application executable on the VM (for example, Z:\Customapps\app.exe) or UNC-specified path (for example, \\fileserver.accounting.com\vol1\software\app.exe).
    RDSH Images to use withImage(s) with which you want to use the application. Click in box and select from drop-down list. The list includes Windows Server 2008/2012 gold patterns, which are used for applications assignments.
    * Icon File.png file (32 x 32 pixels) to use as application’s icon. Click Choose File to browse for file.
    * VersionVersion number of application.
    * PublisherPublisher of application.
  4. Click Save.
Edit a Custom Application
  1. Select an application on the Applications page and click the Edit button at the top of the page.

    The Edit Application dialog appears.

  2. Edit information as described below (optional fields marked with *).
    NameUnique name for the new application.
    Application PathLocation of the application executable on the VM (for example, Z:\Customapps\app.exe) or UNC-specified path (for example, \\fileserver.accounting.com\vol1\software\app.exe).
    RDSH Images to use withImage(s) with which you want to use the application. Click in box and select from drop-down list. The list includes Windows Server 2008/2012 gold patterns, which are used for applications assignments.
    * Icon File.png file (32 x 32 pixels) to use as application’s icon. Click Choose File to browse for file.
    * VersionVersion number of application.
    * PublisherPublisher of application.
  3. Click Save.
Delete a Custom Application
  1. Select an application on the Applications page and click the Delete button at the top of the page.

    The confirmation dialog appears.

  2. Click OK to confirm delete.

View Agent Direct Connect No Longer Needed

Beginning in this release, Horizon DaaS Platform no longer requires use of the View Agent Direct Connect (VADC) component. When performing AD searches in the old Enterprise Center tenant administration interface, you were required to enter the beginning of the DN. For example, searching "CN=Admin" would find the Builtin Administrators group. In the Administration Console, you must search by entering the name only. In this example, entering “Admin” instead of “CN=Admin”.

VMware Identity Manager Integration

Identity Manager, VMware's Identity as a Service (IDaaS) offering, can now be integrated with Horizon Cloud. The supported versions are Identity Manager On-Premise 2.8 and 2.8.1.

To set up Identity Manager:

  1. Install and configure Identity Manager as described in the Identity Manager documentation. See Installing and Configuring VMware Identity Manager.

  2. Enable Horizon Air in the VMware Identity Manager Administration Console:

    1. In the VMware Identity Manager Administration Console, click the Catalog tab.

    2. Select Application Catalog > Manage Desktop Applications > Horizon Air Application. You are redirected to the Horizon Air Resources page.

    3. If Horizon Air Application menu item is not enabled yet in vIDM Hosted Service, access the connector link /desktoneresources/ directly in the browser. For example: https://sva-fcjindal.hs.trcint.com:8443/hc/t/SVA-FCJINDAL/3001/admin/desktoneresources/

    4. Select Enable Horizon Air Desktops and Applications to configure Horizon Air for VMware Identity Manager and set up the sync schedule.

    For descriptions of the fields and an example of configuration, see Enable Horizon Air Desktops and Apps in VMware Identity Manager.

  3. If the tenant does not have a valid CA signed certificate installed, upload the tenant certificate in the vIDM Connector so that the sync can execute successfuly:

    1. Log in to the connector appliance admin page, https://vIDMconnectorhostname:8443/cfg/ssl, as the admin user.

    2. Select Install Certificate.

    3. Select the Terminate SSL on a Load Balancer tab.

    4. Download the tenant certificate:

      1. Open tenant host URL in Firefox browser.

      2. Click on lock icon.

      3. Export the certificate.

    5. Paste the contents of the tenant certificate in the Root CA Certificate textbox under Tenant SSL on a Load Balancer.

  4. Create the federation artifact in Identity Manager. See Create Federation Artifact for Horizon Air.

  5. Set up the federation artifact, following the procedure described here: Configure SAML Authentication in the Horizon Air Tenant.

To download the VMware Identity Manager log files:

  1. Get the authorization for accessing the API’s with the URL:

    https://<IP of appliance>/dt-rest/v100/system/login?user=<username>&domain=<tenant name>&pw=<password>

  2. Call the API:

    https://<IP of appliance>/dt-rest/v100//reporting/manager/ downloadvidmreport?numberofvidmreports=4

    Note the following:

    • This API takes only one input, which is the most recent number files to download (4 in the example above). If the number is greater than number of available files to download, then all the available files should be returned.

    • Files are compressed (zipped) and passed on to the clients of this API.

    • The most recent file, to which logs are currently written, is also returned.

Blast Extreme Protocol Supported

Horizon DaaS Platform now supports the Blast Extreme protocol. Blast Extreme is a high performance display protocol that contains both WAN optimization and support for 3D graphics, resulting in a far superior end user experience when compared to RDP.

Note the following regarding the use of the Blast Extreme protocol:

  • Each virtual desktop must have the latest versions of the Horizon Agent and DaaS Agent installed.

  • End users must have the VMware Horizon Client installed on their end point device.

  • Blast Extreme is the default protocol for Native Clients in the pool settings.

Helpdesk Console (Beta Feature)

Notice Regarding Beta Features and Support


If you encounter questions or issues using the Helpdesk Console, you can send them to deployment@vmware.com. VMware is not committed to productization of any features or resolution of any issues of the Helpdesk Console.

The Helpdesk Console is an interface that you can use to:

  • Access VMs directly.

  • Perform health scans.

  • Get remote assistance.

  • View usage trends and user session activity.

  • Upload images.

  • View logging information.

For feature descriptions and instructions, see the Horizon DaaS Platform Tenant Administration guide.

Service Provider Features

Maintenance Page in Service Center Replacing dt-console

Functions previously performed in dt-console are now performed on the new Maintenance page in the Service Center, as described below.

Note: Rolling back Tenant appliances to a previous snapshot, previously done in dt-console, is not available on the new Maintenance page of the Service Center.

The three functions on the Maintenance page are: Failover Master, Slony Initialization, and Appliance Upgrade.

Failover Master

The updated procedure for failover master is shown below.

  1. In the Service Center, select appliances > maintenance.

  2. In the Fail Over section of the page, enter the following information.

    Organization idOrg ID of the appliance to which the failover will be done.
    Data Center nameName of the Data Center where the appliance is residing to which the failover will be done.
    DB instance nameName of database instance for failover.
    Element IDID of the Desktop Manager to list New Master IP for failover. This option is visible when DB instance name is 'edb'.
    New master IPeth0 IP of the appliance to which the failover will be done.
  3. Click the FailOverMaster button.

  4. Restart the service provider appliances.

Note: Failover function will not work in a staggered environment (i.e. Service Provider at Horizon DaaS Platform 7.0 and Tenant(s) at 6.1.x). This is also noted below under Known Issues and Workarounds.

Slony Initialization

The updated procedure for initializing or re-initializing slony for a Desktop Manager or Org is shown below.

  1. Stop dtService on all nodes:

    service dtService stop

  2. Stop slon daemons (kill daemons on target nodes):

    killall slon

  3. Run this command on the target db (FDB or EDB):

    drop schema _slony cascade;

    Note: Drop the schema only for the affected database pair.

  4. If you stopped dtService on the Primary service provider node for re-initialization of the FDB on the service provider appliances, then start the service again on the primary service provider node:

    service dtService start

  5. Start slon daemons as follows.

    • For the service provider org, start the daemon for the FDB:


    • For the tenant org, start the daemons for both the FDB and the EDB:



  6. In the Service Center, select appliances > maintenance.

  7. In the Slony Operations section of the page, enter the following information:

    • Organization id: Org ID of the appliance to which the init slony would be performed.

    • DB instance name: Name of database instance for init slony.

    • Element ID: ID of the Desktop Manager to list New Master IP for init slony operation. This option is visible when DB instance name is 'edb'.

  8. Click Init Slony.

Appliance Upgrade

The updated procedure for upgrading appliances for an organization is shown below.

  1. In the Service Center, select appliances > maintenance.

  2. In the Upgrade Operations section of the page, select the Organization ID and click Invoke Upgrade.

    All appliances for the organization are updated. Allow a minimum of 40-50 minutes for each data center to upgrade. Services on affected appliances are stopped and started automatically. Watch desktone.log for progress (located in the /var/log/desktone directory on the Primary Service Provider). While the upgrade is in progress, the status of “running” will be displayed on the table under the “Upgrade Operation” section. When it completes, the status of “successful” or “failed” is shown. You may need to refresh the page to get the latest status.

Image Sync Across Desktop Managers

If you have multiple Desktop Managers registered to a Tenant within the same Data Center, there is a new feature that allows you to:

  • Duplicate images across Desktop Managers without manually cloning and importing the images.

  • Sync changes to images across Desktop Managers without making the changes on all copies.

The image sync feature is disabled by default, and can be enabled/disabled for each Tenant by selecting the Sync Gold Patterns check box, either on the tenant registration page or on the General tab of the tenant edit page.

Crypto Agility in Horizon DaaS Appliances

To improve security, it is now possible to configure network listeners for cipher suites and TLS protocol versions on Horizon DaaS Appliances. For more information, see the Horizon DaaS Platform 7.0 Crypto Agility document.

Other Changes in This Release

Increased Memory for Service Provider Appliances

Beginning in version 7.0, the memory footprint for service provider appliances has increased to 4GB. All Service provider appliances will also have 2 vCPU starting in this release.

Deprecated REST APIs

The methods listed below, from the DtInfrastructureManagerImpl class, have been deprecated and will be deleted in the near future.

  • discoverHypervisorManager

  • discoverHypervisorManagerByAddress

  • getPatterns

  • createDesktopPool

  • getDesktopPools

  • getDesktopPoolOfUsers

  • getPatternsOfUsers

  • getDefaultMappingOfUsers

  • getVirtualMachines

  • getVirtualMachine

  • createOrUpdateDesktopModelQuota

  • createOrUpdateDesktopManagerDMQuota

  • getDesktopModelQuotas

  • convertToGoldPattern

  • reserveDesktopPattern

  • purgeRecyclePool

  • retrieveSessionQuotaForTenant

  • retrieveTemplateQuotaForTenant

  • refreshDynamicPool

Product Support Notices

Access Point Support

The minimum required version of Access Point is now 2.7.2. Versions 2.8 and 2.8.1 are also supported. Installation files for all supported versions of Access Point are available on the Horizon DaaS Platform download page on MyVMware.com. For more information, see the Access Point Setup section of the Horizon DaaS Platform 7.0 Service Provider Manual and the VMware Access Point Documentation.

DaaS Agent 7.0 Required

Once the tenant appliances are upgraded to Horizon DaaS Platform 7.0, the DaaS Agent 7.0 is required for the system to function.

DaaS Agent 7.0 Upgrade Recommendations

To take full advantage of the Agent Pairing feature, it is recommended that you follow the guidelines below.

  • For floating desktop assignments, upgrade the agent on the image, bootstrap it, and then re-publish the image. You can then Push Updates for the image so that all desktops have updated agents that are bootstrapped.

  • For dedicated desktop assignments, set the registry setting "pairWithLegacyCredentials" (under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware DaaS Agent) to 1 for all dedicated desktop VMs on which you are upgrading the DaaS agent. Then proceed with the agent upgrade as usual.

You can use the Agent Pairing setting to control the agents that communicate with DaaS desktop manager. For more information, see Edit General Settings in the Tenant Administration document.

Horizon 7 Agent Required

It is required that you install VMware Horizon 7 Agent on all virtual machines.

  • When installing the Horizon Agent, you must now de-select the option to install the View Composer component.

  • Horizon 7.0.2 Agent is now supported.

For more information, see Install Horizon Agent in the HTML Access (Blast) Setup section of the Horizon DaaS Platform 7.0 Service Provider Administration manual, and also the Horizon Agent standard and silent installation procedures online.

View Agent Direct Connect No Longer Required

As mentioned above, Horizon DaaS Platform no longer requires use of the View Agent Direct Connect (VADC) component.

Firmware Requirement for Tera2 Client

Firmware 5.1.1 or higher is required to connect to Horizon DaaS Platform using a Tera2 client.

TLS Support

Horizon DaaS Platform 7.0 provides support for TLS 1.1 and 1.2, and TLS 1.0 is no longer enabled by default for user access. Future versions of the Horizon client will not have TLS 1.0 enabled by default, but will require configuration changes that enable TLS 1.0 in order to work with prior versions of the DaaS Platform. The new protocol versions supported in this release, along with many other security related updates, bring significant security improvements such that this release is a highly recommended update.

It is recommended that Horizon DaaS Platform users upgrade to the latest Horizon Client versions (versions 4.0.1 and higher are supported).

Guest OS Support

Operating SystemPatch/SP32/64 Bit VDI/RDSAdditional Variants/SpecsRemote AppsComments

Resolved Issues

The following issues have been resolved in Horizon DaaS Platform 7.0.

  • Version 7.0 addresses a security vulnerability in versions 6.1.x that occurred due to insufficient validation of data. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned CVE-2017-4897 to this issue.
  • When a user that is not part of a registered user group was added to an assignment in the Administration Console, the following limitations applied:

    • Such users could not make an RDP connection unless they had been explicitly added to the Remote Desktop Users group on the target desktop(s).

    • Mappings screen searches in Enterprise Center did not find users who were not part of any registered groups, whether or not they were assigned to any assignments or desktops.

    • This has been remedied so that these limitations no longer apply.

  • The following issues had occurred in the process of adding users to assignments:

    • After a user was removed from a pool, the user sometimes still had a desktop assigned and be able to log into the pool. The assigned desktop had to be removed manually by the administrator.

    • After a desktop was unassigned from the user, the user sometimes still was shown in the assignment in the user interface. However, the user was not able to log into the assignment anymore. The administrator had to either manually assign the user a new desktop or remove the user from the assignment.

    • The following associations could not be found using the search function:

      • When a user was manually assigned to a desktop, the relationship between the user and the assignment could not be discovered in a search.

      • If a user was added to an assignment then logged into the assignment, the relationship between the user and the assignment could not be found in a search.

    This has been remedied so that these issues no longer occur.

  • Authentication failed if a user’s password included any of the following special characters: < > ( )

    This has now been remedied so that these passwords will work as expected.

Known Issues

The following are known issues in this release.

Tenant Administration Issues

  • Adding an application with ampersand (&) in the shortcut name to an assignment makes all applications in that assignment unusable. The workaround for this is to replace the “&” with “and”.
  • When an individual user (i.e. not in a group) is added to an assignment, the user does not have access to the assignment as expected. The workaround is to add the user to a group and then add the group to the assignment. Alternatively, you can configure a GPO policy to add a user in RDP local group.

  • Login fails when username contains non-ASCII character on Desktop Portal login page when using Microsoft Edge browser.

  • Users have been unsuccessful connecting to Horizon DaaS using a Tera2 client. To resolve this issue, upgrade to Firmware 5.1.1 or higher.

  • If the Tenant database password includes an ampersand (&) character, installation will fail even though Tenant creation was successful.

  • If you have users that are entitled to multiple pools and app stacks, it is recommended that you as the administrator consistently set whether a user writable volume is enabled for a particular user and/or group.

  • On the Applications page, the Hide button is only enabled when the application selected in the list is a remote application (only one application can be selected at a time). On the Application > Hidden app page, the Hide button is also used to unhide remote application which are hidden.

  • On the Locations page, a file share may still show a status of Green (connected) even after the file share has been unmounted.

  • During image creation, if you restore the VM to a snapshot which was taken prior to bootstrapping of agent, then the agent may not be able communicate if it has been already boot-strapped before restoration of the VM's snapshot. To avoid this issue, do not restore a VM to a snapshot taken prior to the bootstrapping process, in case the agent has been already boot-strapped.

  • When you export a .csv file on the Desktop Mapping page, the content of the exported file may not match the language of the user interface.

  • When you export a .csv file on the Activities page, the exported file shows the user's protocol incorrectly as RDP instead of Blast.

  • Desktop VMs in a dedicated desktop assignment continue to launch even if the Agent Pairing mode is updated from 7.0 Upgrade Mode to 7.0 Mode. To avoid this issue, before setting agent pairing to 7.0 Mode, request that your Service Provider set element.allocator.staticVM.agentState.check to true, request all dedicated desktop assignment users to log off, and then update agent pairing mode to 7.0.

  • When you create a new assignment and set Blast as the default protocol, this is not reflected in the Horizon Client when you connect to the tenant.

  • For an App Assignment that has user groups assigned, only the number of groups (as opposed to the total number of users in the groups) appears in the Users column on the Assignment page.

  • In larger environments, the ARP cache overflows during certain operations (e.g. mass/sequential logoffs initiated from the admin console). This causes unexpected network interruptions. The workaround is to raise the garbage collection thresholds by editing the /etc/sysctl.conf file. This can be done at any time after the tenant/DM appliance has been successfully created, as reported by the Service Center (although if you do this after pools have been created, end users will be affected by the reboot).

    1. Create a working copy of the file.

      cp /etc/sysctl.conf /tmp/sysctl.conf

    2. Edit the file as superuser with an available text editor, for example:

      vi /tmp/sysctl.conf

    3. Add the following lines to the file.

      net.ipv4.neigh.default.gc_thresh1 = 4096

      net.ipv4.neigh.default.gc_thresh2 = 4096

      net.ipv4.neigh.default.gc_thresh3 = 4096

    4. Verify that your edit was successful, as in the example below.

      diff /etc/sysctl.conf /tmp/sysctl.conf


      > net.ipv4.neigh.default.gc_thresh1 = 4096

      > net.ipv4.neigh.default.gc_thresh2 = 4096

      > net.ipv4.neigh.default.gc_thresh3 = 4096

    5. Copy the edited version back in place of the original.

      cp /tmp/sysctl.conf /etc/sysctl.conf

    6. Reboot the appliance.

Service Provider Issues

  • When some users attempt to upgrade the Primary Service Provider from Horizon DaaS Platform 6.1.x to 7.0, the runUpgrade.sh may be killed during execution. If this occurs, re-run the script.

  • After a tenant upgrade completes, you may see the following error while executing an action in the Service Center:

    org.springframework.remoting.RemoteAccessException: Could not access HTTP invoker remote service

    If you see this error, then you must restart the Service Provider appliances.

  • Rescheduling a failed restore attempt in a staggered environment (Service Provider org at version 7.0 and Tenant org at 6.1.6) may fail. The workaround for this is to create a new restore reservation.

  • On the Maintenance page in Service Center, the failover function will not work in a multiple datacenter staggered environment (i.e. Service Provider at Horizon DaaS Platform 7.0 and Tenant(s) at 6.1.x).

  • If you create a new data center after upgrading, the SP2 on the second data center may fail during install. To remedy this, perform the following steps before creating SP2:

    1. ssh to SP1 of DC2.

    2. Run the following:

      sudo -i

      ssh -o StrictHostKeyChecking=no root@ "cat ~/.ssh/authorized_keys" >>


    3. ssh to SP2 of DC1 to be root user.

    4. ssh to SP1 of DC2 to verify that ssh issue is fixed.

  • Appliance restore is not working for appliances in a secondary datacenter. There is no workaround for this, and it is expected to be fixed in a future release.

    Other issues can occur related to SSH and SCP access between the primary and secondary datacenters. To prevent these issues, run the following on DC1 SP1:

    scp /root/.ssh/authorized_keys :/root/.ssh/

  • Log Rotate enhancements are not applied to SP1 appliances when freshly installed (that is, during build-out of a new Datacenter). The log rotate changes are correctly applied to newly installed RM and TA appliances, and all upgraded appliances.

    Horizon DaaS Platform development will deliver a script (SP1_logrotate_update.sh) that can be run on a newly installed SP1 appliance to apply the necessary changes.

  • When you perform a multi-datacenter fresh install and the appliance DB password contains a colon (:), slony initialization for the primary SP in DC2 fails. To avoid this issue, change the appliance DB password to not include a colon (:) before proceeding with the fresh install.

  • Adding a User Account to an existing Compute Resource in the Service Center only allows the Username to be 24 characters. This is only an issue when adding an account to existing Compute Resources; it is not an issue when adding/discovering a New Host Manager. To work around this issue - add the new account with a truncated username, then update the resource_credentials table in the fdb with the full username : update resource_credentials set username = 'XXXXX' where resource_id = 'YYYYY';

  • Attempting to save a desktop model after editing fails. The workaround is to retry the save operation, which should result in a successful save.

  • After upgrading to Horizon DaaS Platform 7.0, you may see None as the value for Usage in the Service Center under service grid > resources > Compute Resources. The workaround for this is to update the value manually by selecting Edit Compute Resource.

  • When performing the second bootstrap during service provider installation, you may see an error indicating that the attribute 'read_config_version' is missing. The workaround for this is to re-clone the SP1 appliance from the template and start the installation again.