App Volumes Configuration

This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Workspace ONE and Horizon solutions. This chapter provides information about common configuration and deployment tasks for VMware App Volumes.

This includes detailed instructions for configuring VMware App Volumes across multiple sites, implementing redundancy both within and across sites. As is described in the Multi-site Design section of App Volumes Architecture, the recommended deployment option for App Volumes across multiple sites is to use separate databases.

Configuration of the Non-Attachable Datastore and Storage Group

This design uses an NFS datastore to replicate packages between sites. Though NFS is not a requirement, it provides low-cost storage replication that works with both VMware vSphere® VMFS and VMware vSAN implementations of VMware vSphere®.

To use this setup, perform the procedures described in the sections that follow.

Configure a Non-Attachable NFS Datastore for Site 1 and Site 2

Note: The screenshots in this section were taken from Site 1. The process was repeated for Site 2.

To configure a non-attachable datastore for replication purposes:

  1. Use the App Volumes Manager console to configure a machine manager for the VMware vCenter Server®.

App Volumes–managed storage locations are available based on the vCenter Server selected in the App Volumes machine manager configuration. For example, the following screenshot shows a machine manager configured for the vCenter Server whose host name is

  1. Mount the NFS datastore to the hosts in the selected vCenter Server, to make them available as App Volumes managed storage locations.

For example, in the following screenshot, the NFS datastore AppVolumes-Unattached is added to vSphere hosts in the cluster.

  1. After the NFS datastore has been added to the vSphere hosts, click Rescan to make it available as a managed storage location.

  1. Select the datastore, and click Make As Not Attachable. This option allows packages to replicate to and from this datastore, but prevents packages on this datastore from being mounted for use.

Create a Storage Group

Next, you create a storage group that includes one or more attachable datastores, and the non-attachable datastore, as shown in the following screenshot.

Figure 1: Creating a Storage Group

Replicate Packages from Site 1 to Site 2

After storage groups have been created on Site 1 and Site 2, you can import packages for assignment at the secondary site, and you can replicate the packages to the datastores that are members of the storage group. The following screenshot shows the Import and Replicate buttons you can use.

A screenshot of a social media post

Description automatically generated

Figure 2: Import and Replicate Packages

Replicate Application Packages and Reconstruct Relationships and Entitlements

App Volumes 4 introduced the constructs of applications, packages, markers, and other components comprising simplified application management (SAM), to streamline the process of managing the application lifecycle. Although storage groups can be used to automate the replication of packages, storage groups cannot replicate application-to-package relationship data or the new SAM attributes.

The following example is meant to illustrate the issue.

In the primary site, an App Volumes application is created for Notepad++. Three packages are created, each containing a program for a different version of the app. The packages and their programs are added to the application. As is shown in the following screenshot, the CURRENT marker is set, and the Description field is populated.

A screenshot of a social media post

Description automatically generated

Figure 3: Notepad++ Application That Includes Three Packages and Uses a CURRENT Marker

When the three packages are replicated to the secondary site and imported, App Volumes Manager creates a new application object for each of the packages, as shown in the following image.

Figure 4: Application Created by Replication

Note that the application name is created to match the package name, the Description field is blank, and the CURRENT marker is not set.

After replicating packages to the secondary site, you will need to first reestablish the application-to-package relationships and then re-apply the application and package attributes. There are two methods to replicate entitlements and other attributes from the source server to the target server: manually or using a VMware Fling.

Manual Replication

This section outlines the high-level tasks needed to replicate relationships and attributes. All actions should be carried out on an App Volumes Manager server in the secondary site unless otherwise specified.

For applications that contain multiple packages, start by fixing the application-to-package relationship. Create an application with a name that matches the application name in the primary site. Use each package’s Move button to move the packages to the new application with the proper name.

Figure 5: Notepad++ Package That Needs to Be Moved to an Application with the Correct Name

Moving the last package from an application will result in a prompt to delete the empty application object.

Figure 6: Delete the Replicated Application After Moving Its Package to an Application with the Correct Name

Once the application-to-package relationships match that of the primary site, re-apply the following attributes to the application and packages so that they match those of the primary site.

For applications, re-apply the following attributes:

  • Owner
  • Description
  • Assignments (entitlements)

For packages, re-apply the CURRENT marker.

Replication Using the App Volumes Entitlement Sync Fling

The App Volumes Entitlement Sync tool has been updated to accommodate App Volumes 4 simplified application management components.

Application package entitlement sync works by enumerating the packages at each site. This includes gathering data such as the associated application, and package marker, owner, and description.

An initial compare operation is performed and will report if application and package relationships are inconsistent between sites. When inconsistencies are found, you can use the Fix Apps option, which performs the following tasks:

  1. Creates applications at the secondary site that match those at the primary site
  2. Moves the imported packages to the new applications
  3. Deletes any remaining, empty application objects

Once the application-to-package relationships are consistent, you can then sync entitlements from Site 1 applications to their matching Site 2 applications. Download the App Volumes Entitlement Sync tool from the VMware Flings site.

Configuration of Separate App Volumes Database Instances per Site

This design uses separate App Volumes database instances for each site. With this option, you can use SQL Always On availability groups within each site to achieve local high availability of the database. To make user-based entitlements for packages available between sites, you can manually replicate entitlements or use the App Volumes Entitlements Sync tool, which is available as a VMware Fling.

To use this setup, perform the procedures in the following order:

  1. Create a Windows Server Failover Cluster in Each Site
  2. Install SQL Server 2016 Stand-Alone in All VMs
  3. Create the App Volumes Databases and Enable Availability Groups for the Clusters
  4. Create Always On Availability Groups for App Volumes Databases
  5. Configure Cluster Quorum Settings
  6. Install App Volumes to Use a Highly Available Database

Create a Windows Server Failover Cluster in Each Site

A failover cluster is a group of VMs that have the same software installed on them and work together as one instance to provide high availability for a service, such as a Microsoft SQL Server database. If a VM, or cluster node, in the cluster fails, another node in the cluster begins to provide the service.

Note: For information about setting up the NSX Advanced load balancer (AVI Networks) for use with App Volumes, see Configure Avi Vantage for VMware Horizon. If you are using another type of load balancer, verify that you have set up this load balancer according to the vendor’s instructions.

To create a Windows Server Failover Clustering (WSFC) cluster:

  1. On two ESXi hosts in Site 1, create and configure the two VMs that will be used as a clustered instance of Microsoft SQL Server, and then do the same in Site 2.
    1. For this reference architecture, we used the Windows Server 2019 Standard operating system in the VMs that run SQL Server.
    2. In this example, we named the VMs as follows: At Site 1, we created VMs named s1-sql4 and s1-sql5 on separate ESXi hosts. At Site 2, we created VMs named s2-sql4 and s2-sql5.
    3. Set up each VM in the same way, with a total of five 20-GB hard disks: one disk for the Windows OS and five disks for the various types of SQL Server data.

Inside the OS, the disks are mapped to drive letters as follows.

  1. In preparation for creating the failover cluster, choose a cluster name and obtain a corresponding static IP address for the cluster in Site 1 and in Site 2.

For example, in this reference architecture, for the cluster names, we use s1-sqlclust-2 and s2-sqlclust-2.

  1. To set up failover clustering on the SQL Server VMs, user Server Manager on each of the four VMs (two in Site 1 and two in Site 2), and use the Windows Server Add Roles and Features Wizard to add the Failover Clustering feature.

In the wizard, select to add the following features:

  • .NET Framework 3.5 features
  • Failover Clustering, including adding the Failover Clustering tools

For detailed instructions, see the Microsoft blog post Installing the Failover Cluster Feature and Tools in Windows Server 2012. One of the tools installed is the Failover Cluster Manager, which you will use for many of the steps that follow.

  1. Use the Failover Cluster Manager to create a WSFC cluster that includes two SQL Server VMs in Site 1, and then do the same in Site 2.

For detailed instructions, see Create a Failover Cluster. The failover cluster for Site 1 includes the VMs s1-sql4 and s1-sql5. The cluster for Site 2 includes the VMs s2-sql4 and s2-sql5.

Install SQL Server Stand-Alone in All VMs

You install SQL Server Stand-Alone on each VM, rather than creating a SQL Server failover cluster. For App Volumes, you use stand-alone installations and then create Always On availability groups to achieve failover within a site.

To install SQL Server:

  1. In Site 1, on the first SQL Server VM, complete the SQL Server installation wizard, using the following guidelines:
    1. Installation page – Select New SQL Server stand-alone installation.
    2. Feature Selection page – Select Database Engine Services and Management Tools - Basic.
    3. Instance Configuration page – Select Default instance. The instance ID is MSSQLSERVER.
    4. Server Configuration page – The startup type is Automatic for the SQL Server Agent and SQL Server Database Engine.
    5. Database Engine Configuration page – On the Server Configuration tab, select Mixed Mode (SQL Server authentication and Windows authentication), and enter credentials for a user account that will be part of the SQL Server administrators.
      On the Data Directories tab, for each item, select the disk that you created for that type of file during VM creation. Use the following screenshot as a guide.

For more information about the setup wizard, see Install SQL Server from the Installation Wizard (Setup).

  1. Repeat Step 1 to install SQL Server on the other VM in Site 1 and on the VMs in Site 2.
  2. Create a shared folder on the first SQL Server VM in each site; for this example, the VMs are s1-sql4 and s2-sql4).
    1. Create a folder named Replication on the SQL_Binaries (E:) drive. You created this drive during Step 1 of Create a Windows Server Failover Cluster in Each Site.

  1. Give the SQL service account full permissions on the folder.

Create the App Volumes Databases and Enable Availability Groups for the Clusters

This section provides detailed instructions for creating a highly available database but does not give recommendations regarding the sizing of the database for various sizes of deployments. For information about database sizing, see VMware App Volumes 2.x Database Best Practices.

To create the databases:

  1. On first SQL Server VM in each site, use Microsoft SQL Server Management Studio to create an App Volumes database.
    1. For this example, the VMs are s1-sql4 and s2-sql4.
    2. Log in to the Management Studio as the sysadmin or as a user account with sysadmin privileges.
    3. Connect to the SQL Server instance on the VM, right-click the Databases folder, and select New Database.
    4. Enter a database name and click OK.

For example, for Site 1, we named the database s1-appvolumes. For Site 2, we named the database s2-appvolumes.

  1. Open SQL Server Configuration Manager and enable Always On availability groups for the Windows Failover cluster in Site 1 and Site 2.

For instructions, see Enable or disable Always On availability group feature (SQL Server).

The cluster names are the names you created in Step 2 of Create a Windows Server Failover Cluster in Each Site.

  1. In each site, on the domain controller, open Active Directory Users and Groups, and create a new Computer object for the availability group.

For this example, for Site 1, the AD computer name for the group is s1-sqlclust2-ag1. For Site 2, the name is s2-sqlclust2-ag1.

Create Always On Availability Groups for App Volumes Databases

In this procedure, you create an Always On availability group, adding the SQL Server stand-alone instances from Site 1 as the primary replica and secondary replicas. You then do the same for Site 2, so that each site has its own Always On availability group to achieve automatic failover within each site (but not across sites).

To create the availability groups:

  1. On the first SQL Server VM in Site 1, open the Management Studio, right-click Always On High Availability in the left pane, and select New Availability Group Wizard.
  2. Complete the New Availability Group wizard, using the following guidelines:
    1. Specify Name page – Use the name of the AD computer object you just created. For this example, the name is s1-sqlclust2-ag1 for Site 1.
    2. Select Databases page – Select the check box for the local database, which is s1-appvolumes in this example.
    3. Specify Replicas > Replicas tab – The first SQL Server VM should already be listed. Click Add Replica to connect to and add the second SQL Server VM from this site.

Important: Select the Synchronous Commit and Automatic Failover check boxes. For the Readable Secondary setting, select No for the primary instance and Yes for the secondary instance.

  1. Select Data Synchronization page – Select Full, and specify the shared Replication folder that you created in Step3, Install SQL Server Stand-Alone in All VMs.

This share is used to synchronize the database on the secondary replica with that on the primary.

After you complete these pages, the Validation page, the Summary page, and the Results page take you through the process of creating the availability groups and listeners, and adding the replicas. On the Results page, you can see that the s1-appvolumes database is synchronized between both SQL servers.

When the process is complete, you can view the new availability groups using the Management Studio. The following screenshot shows the availability group with the primary replica on the s1-sql4 VM.

The following screenshot shows the availability group with the secondary replica on the s1-sql5 VM.

  1. Repeat Steps 1 and 2 for Site 2.


Configure Cluster Quorum Settings

At this point, you will configure cluster quorum settings to use a file share witness. Each element in a cluster can cast one “vote” to determine whether the cluster can run. Because you have two nodes in a cluster and you need an odd number of voting elements, create a file share quorum witness, which will cast the third vote. A file share witness is recommended when you need to consider multi-site disaster recovery with replicated storage.

To configure cluster quorum settings:

  1. On a file server in each site, use Server Manager to open and complete the New Share wizard and create an SMB share, using the following guidelines:
    1. Select Profile page – Select SMB Share – Quick.
    2. Share Location page – For the share location, select Select by volume, and select the drive.

  1. Permissions page – Click Customize permissions and give the WSFC cluster object full control over the file share.

When you finish this step, you have two files shares: one for Site 1 and one for Site 2. For more details about accessing and using this wizard, see 12 Steps to NTFS Shared Folders in Windows Server 2012.

  1. Configure the cluster quorum settings for each site:
    1. Open Failover Cluster Manager on the first VM in Site 1, right-click the cluster, and select More Actions > Configure Cluster Quorum Settings.
    2. Complete the Configure Cluster Quorum Wizard, using the following guidelines:
      1. Select Quorum Configuration Option page – Select Select the quorum witness.
      2. Select Quorum Witness page – Select Configure a file share witness.
      3. Configure File Share Witness page – Enter the path to the file share you created in Step 1.

For detailed instructions, see Configure and manage quorum.

  1. Repeat this procedure to set up a file share quorum witness in Site 2.

You are now ready to install App Volumes and point to the availability group we created.

Install App Volumes to Use a Highly Available Database

This procedure focuses on the specific settings required for connecting App Volumes to a highly available database. For details about other aspects of App Volumes installation, including system requirements, see the VMware App Volumes Administration Guide.

To install App Volumes:

  1. In preparation for installing App Volumes and connecting to the availability group listener, use SQL Server Configuration Manager on each SQL Server VM to enable named pipes.

For instructions, see Enable or Disable a Server Network Protocol.

Important: Restart the SQL Server service so the new setting can take effect.

  1. In Site 1, on the first VM on which you want to install App Volumes, download the App Volumes Manager installer, start the installation wizard, and follow the prompts to the Database Server page.
  2. Complete the Database Server page, using the following guidelines:
    1. Choose local or remote database server to use – Select the SQL Server Always On availability group listener that you created in Create Always On Availability Groups for App Volumes Databases.
    2. Name of database catalog to use or create – Select the database that you created in Create the App Volumes Databases and Enable Availability Groups for the Clusters.

Important: If you see an error message such as the following one, it means you need to enable named pipes, as described in Step 1.

  1. On the Choose Network Ports page, verify that the HTTP port is set to 80 and the HTTPS port is set to 443.
  2. Follow the rest of the wizard prompts to complete the installation.
  3. Repeat Steps 1–5 on the second App Volumes VM in Site 1, but on the Database Server page, be sure to leave the Overwrite existing database (if any) check box deselected.
    Both App Volumes Managers in Site 1 must point to the same highly available database.
  4. Repeat this entire procedure in Site 2.

With App Volumes successfully installed, you can begin configuration. For detailed instructions see the VMware App Volumes Administration Guide.

The procedures in this appendix create a setup in which the App Volumes database can fail over automatically within each site. Site 1 and Site 2 have separate databases, but during a failover, users at Site 1 will be able to use replicated App Volumes packages in Site 2 as long as the user entitlements are also replicated. For configuration details, see the section, Replicate Application Packages and Reconstruct Relationships and Entitlements.

Additional Configuration Options for Writable Volumes

You can configure writable volumes so that end users can determine how much free disk space is available in their writable volume. You can expand the amount of disk space if necessary.

Allowing End Users to See the Size of Writable Volumes

Administrators can use the App Volumes Manager console to view the disk space remaining in writable volumes. Administrators can also allow end users to see how much disk space is available on their writable volume by looking at their system volume. To do this, administrators must create a new registry key during the App Volumes Agent configuration:

  1. Navigate to HKLM\System\CurrentControlSet\Services\svdriver.
  2. From this location, create a new registry key called Parameters if it does not already exist.
  3. Within the Parameters key, create a new key called ReportSystemFreeSpace with a DWORD value of 0 (zero).

Alternatively, run a command from an elevated CMD prompt to create the correct key and value:

reg add hklm\system\currentcontrolset\services\svdriver\parameters /v ReportSystemFreeSpace /t REG_DWORD /d 0

Figure 7: Screenshot of the Windows Registry with the Proper Path, Key, and Value

This change requires a reboot to take effect. Logging out or logging in does not apply the changes.

End-User Viewing of Writable Volume Space

When end users look at available disk space through Windows Explorer before you make the registry changes, they can see the free space and total space reported for the C: drive.

Figure 8: Actual Free Space on C:\

After you make the registry modifications and reboot the system, the C: drive reports the amount of free space on the user’s writable volume, which is 19.7 GB total in the following example.

Figure 9: Free Space on User Writable Volume

Notice the total space still reflects the C: drive value.

Configuring the registry so end users can view free space on their writable volumes is recommended any time you use writable volumes.

Expanding Writable Volumes

The default writable volumes template in App Volumes 4 is 10 GB. If a user’s writable volume has reached or is about to reach full capacity, it can be expanded. To expand the writable volume for each user from the App Volumes Manager console:

  1. Locate the user’s writable volume on the Volumes tab under the Writables sub-tab, and expand the information on the specific writable volume.
  2. Click the Expand Volume option and enter a larger value in 1-GB increments.
  3. Have the user log out and log back in. The additional size is added to the writable volume after the user logs out and back in. Also, the free-space usage is not reflected in the App Volumes Manager until the user logs out and back in.

What’s Next?

Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:

  • Overview chapters provide understanding of business drivers, use cases, and service definitions.
  • Architecture chapters explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes Dynamic Environment Manager, and Unified Access Gateway.
  • Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
  • Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more.



Filter Tags

Horizon App Volumes Document Reference Architecture Advanced Deploy Windows Delivery