App Volumes Architecture

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

Introduction

The App Volumes real-time application delivery model separates IT-managed applications and application suites into administrator-defined application containers. App Volumes allows for the separation of applications from the OS image, simplifying application management with real-time application delivery, and one-to-many provisioning.

Figure 1: App Volumes real-time application delivery model

The primary use of App Volumes is the delivery of software programs, that are not part of the OS image, to Windows machines.

• App Volumes groups one or more programs into packages based on the requirements of each use case.
• A package is a virtual disk containing one or more programs that are captured together.
• Different package versions are added to applications.
• Applications are used to assign packages to directory service entities such as user, group, organizational unit (OU), or machine.

 

Figure 2: Applications, packages, and programs

The packages can be mounted each time the user logs in to a desktop, at machine startup, or on-demand, when the user launches a program that is part of the package, depending on delivery configuration.

• For VDI use cases, packages can be mounted at login or on-demand.
• With RDSH use cases, if packages are assigned to the machine account, the packages are mounted when the App Volumes service starts. Alternatively, packages can be assigned to users and delivered as Horizon Published Apps on Demand, in which case they are mounted on-demand.
• With physical endpoints, packages, in an MSI format, can be delivered using an endpoint management solution like Omnissa Workspace ONE UEM or Microsoft Intune.

App Volumes also provides user Writable Volumes, which can be used in specific use cases. Writable Volumes provide a mechanism to capture user profile data, user-installed applications that are not or cannot be delivered by packages, or both. This reduces the likelihood that persistent desktops would be required for a use case. User profile data and user-installed applications follow the user as they connect to different virtual desktops.

Table 1: Implementation strategy for App Volumes

Decision	App Volumes was deployed and integrated into the Horizon 8 on-premises environment. This design was created for an environment capable of scaling to 8,000 concurrent user connections.
Justification	This strategy allows the design, deployment, and integration to be validated and documented.

Note: If you are new to App Volumes, it is recommended to use the App Volumes Product Page to help you familiarize yourself with this product.

Architecture overview

In a virtual desktop environment, the App Volumes Agent installs in the Windows guest operating system of persistent or non-persistent VMs. The agent communicates with the App Volumes Manager instances to determine package and Writable Volumes entitlements. Packages and Writable Volumes virtual disks are attached to the guest operating system in the Windows machine, making applications and personalized settings available to end users.

App Volumes supports physical Windows endpoints from version 2412 onwards, and the Unmanaged App Volumes section provides more details.

Figure 3: App Volumes logical components

Components

The components and features of App Volumes are described in the following table:

Table 2: App Volumes components and concepts

Component		Description
	App Volumes Manager	Console for management of App Volumes, including configuration, creation of applications and packages, and assignment of packages and Writable Volumes Broker for App Volumes Agent for the assignment of packages and Writable Volumes
	App Volumes Agent	Runs on virtual desktops or RDSH servers File system and registry abstraction layer running on the target system Virtualizes file system writes as appropriate (when used with an optional Writable Volume)
	Application	Logical component containing one or more packages Used to assign AD entities to packages Supports marker and package assignment types
	Package	Read-only volume containing applications Virtual disk file that attaches to deliver apps to VDI or RDSH One or more packages may be assigned per user or machine
	Program	Represents a piece of software captured in a package One or more programs may be captured in a package
	Marker	Attribute of an application used to designate the current package Simplifies application lifecycle management tasks
	Writable volume	Read-write volume that persists changes written in the session, including user-installed applications and user profile One Writable Volume per user Only available with user or group assignments User Writable Volumes are not applicable to RDSH and physical endpoints
	Database	The App Volumes Manager requires a database that contains configuration information for applications, packages, markers, and user entitlements Multiple App Volumes Manager servers connect into and share the same database within a site, marking the boundary of operation A production database should be highly available
	Machine Manager	Machine Manager facilitates the mount/unmount instructions from the App Volumes Manager during the attach/detach of a package or writable volumes disk from storage If the storage is configured as the machine manager, the instructions for attach/detach are sent to the agent to directly fetch the disk from storage for mount/unmount operation within the target endpoint For virtual desktop environments on vSphere, the vCenter is configured as the machine manager for App Volumes Manager to provide instructions
	Storage & Storage Group	App Volumes Packages and Writable Volumes can be stored on storage systems supporting VMFS to store VMDK disks and SMB version 3 based storage to store VHD format disks Group of datastores are used to replicate packages and distribute Writable Volumes
	Directory Services	Identity source used to assign and entitle user or computer accounts to packages App Volumes supports Microsoft Active Directory App Volumes also supports Microsoft Entra ID as a Directory Service when deployed from the Azure Marketplace to integrate with Azure Virtual Desktop infrastructure
	Packaging VMs	Clean Windows VM with App Volumes Agent or with App Volumes Tools (for standalone app capture) Used to capture software programs to packages for distribution

Common design considerations

 This section introduces you to the App Volumes Management components required to successfully deploy App Volumes within your infrastructure, whether in an on-premises or a public cloud marketplace deployment.

The App Volumes software you download from the Customer Connect Portal comprises the App Volumes ISO installer and the license key. The installer has the App Volumes Manager, App Volumes Agent, and App Volumes Tools.

Let’s focus on the App Volumes Manager and its interaction with the following infrastructure components that consume their services: the directory services, database services, storage services, and a machine manager that manages your virtual desktop infrastructure.

The diagrams below are examples of App Volumes infrastructure built with machine manager configuration targeting the storage sub-system directly and machine manager configuration targeting the hypervisor manager in a vSphere environment connected to a storage platform. You can navigate the Understanding Machine Manager Types section to understand the machine manager interaction with the App Volumes Manager server.

Figure 4: Storage sub-system configured as the machine manager in the [VHD] In-guest mode

Figure 5: vCenter configured as the machine manager in a vSphere environment

Understand the infrastructure

The following section will give you an understanding of the communication pattern between the App Volumes Manager and App Volumes Agent, as well as understand Machine Managers and the configuration options within App Volumes Manager to tie into a Machine Manager type depending on the virtual desktop infrastructure deployed.

You will understand the App Volumes prerequisites starting with the App Volumes system requirements defined in the App Volumes install guide. Learn the infrastructure components like the database, directory services, network, and storage, followed by advanced configuration topics like load balancing, replication, storage groups, and multi-site and multi-instance management.

Understand machine manager types

One of three types of machine managers is used in the initial setup and configuration of the App Volumes Manager server. This can be a storage subsystem supporting SMB version 3 protocol or a virtual desktop environment using a Hypervisor management solution to attach and detach the App Volumes package.

 Machine manager types:

• [VHD] In-Guest Services:
  • Select ‘[VHD] In-Guest Services’ as the machine manager when manually deploying App Volumes Managers to support non-vSphere virtual desktop environments.
  • Auto-populated for Azure Marketplace deployments supporting Azure Virtual Desktops.
• vCenter or ESXi Host:
  • Selecting the vCenter as the machine manager when manually deploying App Volumes Managers to support a vSphere virtual desktop production environment.
  • Selecting the ESXi as the machine manager when manually deploying App Volumes Managers to support a vSphere non-production or PoC virtual desktop environment.

Exception:

• The selection of a machine manager is not applicable and does not apply to Cloud Hosted App Volumes from Horizon Cloud Service Next-Gen, as App Volumes is a managed service.

 Machine manager type: [VHD] in-guest services

This configuration adds an SMB protocol-supported storage solution to the App Volumes Manager as the machine manager. The App Volumes Packages and Writable Volumes disks are stored in the VHD format.

Figure 6: Machine manager type: [vhd] in-guest services

1.        App Volumes Agent calls the App Volumes Manager to validate if an App Volumes Package Assignment and/or Writable Volume is entitled to the target.
2.        App Volumes Manager confirms an entitlement is present.
3.        With the App Volumes Agent, the target machine accesses the storage and mounts the disk for consumption.

Machine manager type: vCenter

This configuration adds a vCenter to the App Volumes Manager as the machine manager. The App Volumes Packages and Writable Volumes disks are stored in the VMDK format to VMFS/NFS/VSAN storage connected to the vCenter and visible/accessible to the vSphere hosts managed by the vCenter.

Figure 7: Machine manager type: vCenter

1.        App Volumes Agent calls the App Volumes Manager to validate if an App Volumes Application Assignment and/or Writable Volume is entitled to the target.
2.        App Volumes Manager confirms an entitlement is present. Then, the App Volumes Manager instructs the vCenter to have the vSphere currently with the target virtual machine and to attach the App Volumes Package and/or Writable Volume VMDK disk onto the virtual machine from the storage.
3.        The vSphere host, having a line of sight to the App Volumes storage, mounts the VMDK to the target virtual machine.
4.        With the App Volumes Agent, the target machine accesses and consumes the mounted disk.

Now that we understand the App Volumes Manager and the App Volumes Agent communication and the two delivery types that can be configured to deliver application packages to target endpoints, we have explored the infrastructure components.

Database

The database is a mandatory infrastructure component required while deploying an App Volumes Manager server and is listed as a pre-requisite in the System Requirements section of the product documentation. An App Volumes database contains configuration information for applications, packages, markers, and user entitlements.

Currently App Volumes supported databases are listed under the System Requirements in the product documentation.

Below are two examples of deployment, the manual deployment using the App Volumes ISO installer and the option presented during the automated App Volumes workflow deployment from Azure/AWS Marketplace. You as the administrator are asked to select the location of the database, if you choose to install a local database, a SQL Express database is installed on the same App Volumes Manager server machine, and this option is best choosed for non-production environments. Choose to connect to an “existing SQL Server database” or “Remote SQL Server database” to a pre-provisioned highly available SQL infrastructure.

Figure 8: App Volumes database location selection from the App Volumes ISO installer during manual deployment

Figure 9: App Volumes database location selection presented during the automated workflow deployment

App Volumes Manager is not required for App Volumes package delivery to physical Windows endpoint instances, so there is no requirement for a database for such a use case. Explore more details under the Unmanaged App Volumes for Physical Endpoints section.

Directory services

App Volumes delivers packages and writable volumes to target endpoints based on an identity source from supported directory services. App Volumes directory support is in the System Requirements section of the product documentation.

• App Volumes supports Microsoft Active Directory for all its deployment platforms.
• App Volumes supports Microsoft Entra ID while integrating with Azure Virtual Desktops when deployed from Azure Marketplace. However, Entra ID cannot be used for application management on standalone desktops.
• App Volumnes supports AWS Managed Microsoft Active Directory for App Volumes deployment from AWS Marketplace.

Further support and design considerations details are documented under each App Volumes Platform in the directory services design considerations section.

Storage

App Volumes supports three packaging formats: VMDK, VHD, and MSI. With these three industry-standard formats, App Volumes can house its application packages to storage platforms that support VMDK and VHD storage file systems.

• For virtual desktop infrastructure supporting SMB version 3, App Volumes packages are stored in the VHD format.
  • Horizon and Citrix environments that utilize storage supporting SMB version 3
  • Cloud-based virtual desktop solutions from Microsoft Azure Virtual Desktop, Windows 365, and AWS AppStream 2.0 can leverage native cloud storage supporting SMB version 3
    • Common storage platforms allow the same App Volumes application package across multiple virtual desktop solutions using SMB version 3 storage infrastructure.
• If the virtual desktop infrastructure is on a vSphere platform, then the datastores support is for storing App Volumes packages in the VMDK format.
• App Volumes tools allows the package capture of new applications directly in VMDK, VHD, and MSI formats.
• App Volumes tools are also built-in with the capability to convert existing packages between formats, reducing the effort of packing and capturing directly to multiple formats or converting easily from VMDK, VHD, or MSI formats.

As you explore the App Volumes Platforms below, each platform has a dedicated section for you to understand the storage requirements listed in the storage design considerations section under each App Volumes Platform.

Network

A detailed discussion of network requirements for App Volumes is outside this guide's scope. However, your network infrastructure design should accommodate network traffic between the App Volumes management components and network bandwidth consumption between the target endpoint and the delivery of App Volumes Packages and Writable Volumes.

Network port requirements have been provided under each App Volumes Platform in their respective network design considerations section.

Security recommendations

To support a large production environment, there are some critical security configurations that administrators should put in place:

• Open only essential, required firewall ports on App Volumes Manager and SQL.
• Replace the default self-signed TLS certificate with a certificate for App Volumes Manager signed by a reliable certificate authority. See Using SSL Certificates with App Volumes Manager.
• Verify that App Volumes Manager can accept the vCenter Server certificate. App Volumes Manager communicates with vCenter Server over TLS/SSL. The App Volumes Manager server must trust the vCenter Server certificate.
• Note: It is possible to configure App Volumes Manager to accept an unverifiable (self-signed) certificate. Navigate to Configuration > Machine Managers in the management console. Each machine manager (vCenter Server) has a Certificate option that shows the current status of the certificate and allows an administrator to explicitly accept an unverifiable certificate.
• Consider using ThinApp to package applications, to take advantage of the security benefits of isolation modes, when required. Each ThinApp package can be isolated from the host system, and any changes, deletions, or additions made by the application to the file system or registry are recorded in the ThinApp sandbox instead of in the desktop operating system.
• For Writable Volumes, determine which end users require ongoing administrator privileges. Writable Volumes with user-installed applications require that each desktop user be assigned local computer administrator privileges to allow the installation and configuration of applications.
• Allow incidental application installation for a specific user or user group in use cases that could benefit from temporary, request-based elevated privileges. . Carefully consider the security risks associated with granting users these elevated privileges.
• Create and use an AD user service account specifically for App Volumes. This is good security hygiene and a forensics best practice. It is never a good idea to use a blanket or general-purpose AD user account for multiple purposes within AD.
• Consider creating an administrative role in vCenter Server to apply to the App Volumes service account.

Load balancing

Use a minimum of at least two App Volumes Managers in production and configure each App Volumes Agent to point to a load balancer. For high performance and availability, we recommend that a load balancer be located in front of the App Volumes Managers to balance connections between each server.

Although a load balancer is recommended for production environments, you can, configure the App Volumes agent to communicate with multiple App Volumes Manager servers as described in Scaling App Volumes Manager.

The main concern with App Volumes Managers is handling login storms. During the login process, user-based packages and Writable Volumes must be attached to the guest OS in the VMs. The greater the number of concurrent attachment operations, the more time it might take to get all users logged in.

For App Volumes 4, the exact number of users each App Volumes Manager can handle will vary, depending on the load and the specifics of each environment. See the knowledge base article App Volumes Sizing Limits and Recommendations (67354) for tested limits of users per App Volumes Manager server and login rates.

It is recommended that you test the load and then size the number of App Volumes Manager servers appropriately. To size this design, we assumed each App Volumes Manager was able to handle 2,000 users.

The following figure shows how virtual desktops and RDS Hosts (published applications) can point to a load balancer that distributes the load to two App Volumes Managers.

 
Figure 10: App Volumes managers load balancing

Table 4: Strategy for App Volumes scalability and availability

Decision	A load balancer was placed in front of the App Volumes Manager servers.
Justification	The load balancer properly distributes the load and keeps the services available in the event of an issue with one of the managers.

For more information and instruction, see the Load Balancing App Volume Manager section in the Configure Avi Load Balancer for App Volumes guide.

No additional configuration is required on the App Volumes Manager servers.

Other third-party load balancers can also be used, and you should refer to the guidance given by the load balancer vendor. Typical settings are given in the table below.

Table 5: Load balancing settings for App Volumes Managers

Component	Settings
Health Monitor	Type = HTTPS Send Interval = 30 seconds Receive Timeout = 10 seconds Client Request Data = GET /health_check HTTP/1.0 Or HEAD /health_check HTTP/1.0 Response Code = 2xx
Pool	Port = 443 Load Balancing Algorithm = Least Connections Persistence = Source IP Use SSL to backend servers
Application Profile	Type = HTTP HTTP Request Header = X-Forward-For
Virtual Service	Type = Layer 7 Ports = 80, 443 Enable SSL Valid SSL Certificate

Cloud-Hosted App Volumes within Horizon Cloud Service

Horizon Cloud Service as a solution load balances its services as the environment scales to multiple providers within a single Horizon Edge to deployments expanding to multiple  Horizon Edges across geographic locations, as documented in the Horizon Cloud Service Next-Gen scaling and availability section.

Automated deployment of App Volumes

A cloud-native or  third-party load balancer within AWS supporting HTTP Layer 7 load balancing with the above configuration will be required when deploying multiple instances of App Volumes Managers from the Azure Marketplace or AWS Marketplace.

App Volumes platforms

Omnissa App Volumes has evolved to support multiple virtual desktop platforms and has deployment models to support the platform requirement.

Figure 11: App Volumes supported platforms

App Volumes supports On-Prem virtual desktop infrastructure deployments using software binaries downloaded from the downloads section in the Omnissa Customer Connect Portal and following step-by-step installation and configuration instructions in the Omnissa App Volumes Installation Guide.

App Volumes application capture supports VMDK and VHD formats to support the underlying hypervisor and storage on which the On-Prem virtual desktop infrastructure is built.

For customers exploring Omnissa Cloud-based Desktop as a Service solution, App Volumes integrates as a managed service within the Omnissa Horizon Cloud Service Next-Gen product.

With the launch of version 2406, App Volumes supports classic Windows desktop environments, a significant enhancement to the App Volumes Apps Everywhere strategy. This new feature extends our efficient one-to-many provisioning model, previously available only for non-persistent desktops, to persistent virtual desktop environments. With the support of persistent desktop environments, App Volumes can now deliver application packages to cloud-based virtual desktop environments on Microsoft Azure Virtual Desktop and Windows 365 and Amazon WorkSpaces and AppStream 2.0.

With the launch of version 2412, App Volumes can capture applications in the industry standard MSI format, allowing the customer to convert existing App Volumes 4.x packages from VHD or VMDK to MSI. The customer can use endpoint management solutions like Omnissa WorkspaceONE UEM or enterprise software delivery tools like SCCM/Intune to deliver this MSI package to physical Windows endpoints.

Note: A physical Windows endpoint must have the App Volumes Agent version 2412 or newer installed to consume the App Volumes MSI package.

The scope of this reference architecture will be around the design components, implementation prerequisites, and standard infrastructure requirements across the implementations.

We will look at the three types of App Volumes implementations available listed below;

• Manual deployment of App Volumes
  • App Volumes deployed to Horizon 8
  • App Volumes deployed to Citrix Virtual Desktop and Apps
• Automated Marketplace workflow deployment of App Volumes 
  • Microsoft Azure Virtual Desktop
  • Microsoft Windows 365
  • Amazon AppStream 2.0
  • Amazon Workspaces Core
• Horizon Cloud Service Next-Gen managed App Volumes service 
• Unmanaged App Volumes for physical Windows endpoints

Deployment prerequisites

Now that we have looked at the different App Volumes platforms and deployment options available, we focus on the product documentation references to the prerequisites for the three App Volumes deployment options.

• Prerequisites for Deploying App Volumes to support an On-Premise virtual desktop environment
• Prerequisites for Deploying App Volumes Manager through Azure Marketplace
• Prerequisites for Deploying App Volumes for Amazon AppStream 2.0
• Prerequisites For Using App Volumes Applications on Horizon Cloud Service Next-Gen

Manual deployment of App Volumes in a Horizon 8 environment

One key concept in a Horizon 8 environment design is the use of pods and blocks, which gives us a repeatable and scalable approach. See the Pod and Block section of Horizon 8 Architecture for more information on pod and block design.

Consider the Horizon block design and scale when architecting App Volumes.

Table 6: Strategy for Deploying App Volumes in Horizon Pods

Decision	An App Volumes Manager instance was deployed in each pod in each site. The App Volumes machine manager was configured for communication with the vCenter Server in each resource block.
Justification	Standardizing on the pod and block approach simplifies the architecture and streamlines administration.

In a production Horizon environment, it is important to adhere to the following best practices:

• Sizing and scaling best practices, as documented in the Horizon Overview and Deployment Planning guide
• vSphere scalability best practices, as documented in Performance Best Practices for VMware vSphere 8.0
• vSphere architectural best practices, as documented in the vSphere Resource Management guide

High-level logical architecture of App Volumes

The following figure shows the high-level logical architecture of the App Volumes components, scaled out with multiple App Volumes Manager servers using a third-party load balancer:

Figure 12: App Volumes scaled logical architecture

Key design considerations

• Always use at least two App Volumes Manager servers, preferably configured behind a load balancer.
  Note: This setup requires a shared SQL Server.
• An App Volumes instance is bounded by the SQL database.
• Any kernel mode applications should reside in the base image and not in a package.
• Use storage groups (if you are not using VMware vSAN) to aggregate load and IOPS.
  Note: Packages are very read intensive.
• Storage groups may still be applicable to vSAN customers for replicating packages. See Multi-site Design for more information. 
• Place packages on storage that is optimized for read (100 percent read).
• Place Writable Volumes on storage optimized for random IOPS (50/50 read/write).
• Assign as few packages as possible per user or device. See the Knowledge Base article App Volumes Sizing Limits and Recommendations (67354) for the recommended number of packages per VM.
  Note: This knowledge base article was written for App Volumes 2.x AppStacks. Although most of the content is applicable to App Volumes 4, the maximum number of package attachments tested has increased.
• App Volumes 4 defaults to an optimized machine managers configuration. Use the default configuration and make changes only when necessary

Figure 13: Default machine managers configuration

Note: With previous versions of App Volumes, configuring the Mount ESXi option or, mount on host was recommended to reduce the load on vCenter Server and improve App Volumes performance. App Volumes 4 and later provides new optimizations in the communication with vCenter Server. Most implementations will no longer benefit from enabling the Mount ESXi option.

You can enable the Mount Local storage option in App Volumes to check local storage first and then check central storage. Packages are mounted faster if stored locally to the ESXi (vSphere) host. Place VMDKs on local storage and, as a safeguard, place duplicates of these VMDKs on central storage in case the vSphere host fails. Then the VMs can reboot on other hosts that have access to the centrally stored VMDKs.

If you choose to enable Mount ESXi or Mount Local, all vSphere hosts must have the same user credentials. Root-level access is not required. See Create a Custom vCenter Role for more information.

vSphere considerations

Host configurations have significant impact on performance at scale. Consider all ESXi best practices during each phase of scale-out. To support optimal performance of packages and Writable Volumes, give special consideration to the following host storage elements:

• Host storage policies
• Storage network configuration
• HBA or network adapter (NFS) configuration
• Multipath configuration
• Queue-depth configuration

For best results, follow the recommendations of the relevant storage partner when configuring hosts and clusters.

For more information, see the vSphere Security Configuration Guides.

Database design considerations

As of App Volumes 4 version 2412, manual deployment of App Volumes requires a database on an SQL server platform. The System Requirements section of the App Volumes Install Guide mentions the supported SQL server options. The database section outlines the guidelines for SQL database support. It explains the choice to deploy an SQL Server Express database on the App Volumes Manager server instead of connecting to a remote SQL server instance. App Volumes supports the following database features for high availability in the System Requirements section of the App Volumes Install Guide.

App Volumes 4 stores configuration settings, assignments, and metadata in a Microsoft SQL Server database. This database is critical to design and must be accessible to all App Volumes Manager servers.

The SQL database defines an App Volumes instance. Multiple App Volumes Manager servers may be connected to a single SQL database.

You can use the Microsoft SQL Server Express database option for non-production App Volumes environments, which is included in the App Volumes Manager installer. Do not use SQL Server Express for large-scale deployments or production implementations.

App Volumes works well with both SQL Server failover cluster instances (FCI) and SQL Server Always On availability groups. Consult with your SQL DBA or architect to decide which option better fits your environment.

For guidance on SQL database sizing for App Volumes, see App Volumes Database Best Practices.

Table 3: Implementation strategy for the SQL server database

Decision	A SQL database was placed on a highly available Microsoft SQL Server. This database server was installed on a Windows Server Failover Cluster, and an Always On availability group was used to provide high availability.
Justification	An Always On availability group achieves automatic failover. Both App Volumes Manager servers point to the availability group listener for the SQL Server.

Directory services design considerations

Applications are used to assign packages to Active Directory (AD) entities such as users, groups, organizational units (OU), or machines. Manual deployment of App Volumes using binaries downloaded from the Omnissa Customer Connect Portal supports Microsoft Active Directory as a directory service. After deploying the App Volumes Manager from the initial login to the Admin UI, a post-installation task is to integrate with a directory service.

• You will need an Active Directory service account with read-only permissions to target directory structure where the target desktops are registered and user accounts are provisioned.
• An Active Directory Group, which will serve as the App Volumes Administrator group.
• This AD group is also added to the local administrators group for the App Volumes Manager Servers, and the users associated with it will become administrators within the Admin UI and have administrative access to the App Volumes Manager Servers.
• Ensure the network connectivity requirements mentioned in the next section are in place for smooth connectivity between the App Volumes Manager and the infrastructure components.

Network design considerations

For App Volumes in an on-premises deployment, see Network Ports in Horizon 8 for a comprehensive list of port requirements.

Supporting knowledge base article: Network connectivity requirements for App Volumes

Storage design considerations

Successful implementation of App Volumes requires several carefully considered design decisions with regard to disk volume size, storage IOPS, and storage replication.

Package and Writable Volume template placement

When new Packages and Writable Volumes are deployed, predefined templates are used as the copy source. Administrators should place these templates on a centralized shared storage platform. As with all production shared storage objects, the template storage should be highly available, resilient, and recoverable. See Configuring Storage to get started.

Free-space considerations

Package sizing and Writable Volume sizing are critical for success in a production environment. Package volumes should be large enough to allow programs to be installed and should also allow for software updates. Packages should always have at least 20 percent free disk space available so administrators can easily update programs without having to resize the package volumes.

Writable Volumes should also be sufficiently sized to accommodate all users’ data. Storage platforms that allow for volume resizing are helpful if the total number of Writable Volume users is not known at the time of initial App Volumes deployment.

In a vSphere environment, packages and Writable Volumes are thin-provisioned, so storage space is not immediately consumed. Follow the vendors best practices when managing thin-provisioned storage environments. Free-space monitoring is essential in large production environments.

Writable Volumes delay creation option

Two policy options can complicate free-space management for Writable Volumes:

• The option to create Writable Volumes on the user’s next login means that storage processes and capacity allocation are impacted by user login behavior.
• The option to restrict Writable Volume access (and thus initial creation) to a certain desktop or group of desktops can also mean that user login behavior dictates when a Writable Volume template is copied.

In a large App Volumes environment, it is not usually a good practice to allow user behavior to dictate storage operations and capacity allocation. For this reason, it is recommended that you create Writable Volumes at the time of entitlement, rather than deferring creation.

Storage groups

App Volumes uses a construct called storage groups. A storage group is a collection of datastores that are used to serve packages or distribute Writable Volumes.

The two types of storage groups are:

• Package storage groups – Used for replication
• Writable Volume storage groups – Used for distribution

In App Volumes 4, the packages within a storage group can be replicated among its peers to ensure all packages are available. Having a common datastore presented to all hosts in all vCenter servers allows packages to be replicated across vCenter servers and datastores.

Two automation options for package storage groups are available:

• Automatic replication – Any package placed on any datastore in the storage group is replicated across all datastores in the group.
• Automatic import – After replication, the package is imported into App Volumes Manager and is available for assignment from all datastores in the storage group.

When using package storage groups, the App Volumes Manager manages the connection to the relevant package, based on location and number of attachments across all the datastores in the group.

Scaling App Volumes with storage groups

Once created, packages are read-only. As more and more users are entitled to and begin using a given package, the number of concurrent read operations increases. With enough users reading from a single package, performance can be negatively impacted. Performance can be improved by creating one or more copies of the package on additional datastores and spreading user access across them.

Packages can be automatically replicated to multiple datastores in a storage group. This replication creates multiple copies of packages. Access is spread across the datastores, ensuring good performance as App Volumes scales to serve more end users. See the Knowledge Base article App Volumes Sizing Limits and Recommendations (67354) for the recommended number of concurrent attachments per package.

See Configure Storage Groups in App Volumes Manager for more information.

Multi-site App Volumes implementations and storage groups

Storage groups can also be used to replicate packages from one site to another in multi-site App Volumes configurations. By using a non-attachable datastore available to hosts in each site, packages created at one site can be replicated to remote sites to serve local users.

A datastore configured as not attachable is ignored by the App Volumes Manager while mounting volumes, and the storage can be used solely for replication of packages. This means you can use a datastore on slow or inexpensive storage for replication, and use high-speed, low-latency storage for storing mountable volumes.

This not-attachable datastore can also be used as a staging area for package creation before deploying to production storage groups. This topic is covered in more detail in the Replication of packages section of Multi-site design.

Note: Marking a datastore as not-attachable or read-only is only applicable for vSphere environments. The check boxes to configure this would not be available in an App Volumes VHD configuration.

Writable Volumes and storage groups

Writable Volume storage groups are used to distribute volumes across datastores to ensure good performance as Writable Volumes are added. See the knowledge base article App Volumes Sizing Limits and Recommendations (67354) for the recommended number of Writable Volumes per datastore.

Table 7: Implementation strategy for storage groups

Decision	Storage groups were set up to replicate packages between datastores. An NFS datastore was used as a common datastore between the different vSphere clusters.
Justification	This strategy allows the packages to be automatically replicated between VMFS datastores, between vSAN datastores, and between vSphere clusters.

Horizon integration

Consider the following when integrating App Volumes and Horizon.

• Do not attempt to include the Horizon Agent in an App Volumes package. The Horizon Agent should be installed in the golden image VM.
• Do not use a Horizon VM (guest OS with Horizon Agent installed) as a clean packaging VM. You must uninstall the Horizon Agent if it is present. Dependences previously installed by the Horizon Agent, such as Microsoft side-by-side (SxS) shared libraries, are not reinstalled, and therefore are not captured by the App Volumes packaging process.
• See Installation order of End User Computing Agents for Horizon View, Dynamic Environment Manager, and App Volumes (2118048) for information on agent installation order.
• Horizon Published Apps on Demand requires Horizon 8 version 2212 or later, and App Volumes 4 version 2212 or later.

 Register App Volumes managers in Horizon Connection servers

In a production environment, the recommendation is to deploy multiple App Volumes Managers with a load balancer as described in Load Balancing. When registering an instance of App Volumes with the Horizon Connection Servers you should register the load balancer FQDN instead of individual App Volumes Managers.

This is because only one App Volumes Manager address can be associated with each RDSH farm, so using the load balancer address allows all the App Volumes Managers, which are in the load balancer pool, to respond to requests from the connection servers.

For more information on Apps on Demand, see Configure Horizon 8 for Published Applications on Demand Delivery.

Scalability and availability

As with all server workloads, it is strongly recommended that enterprises host App Volumes Manager servers as vSphere virtual machines. vSphere availability features such as cluster HA, VMware vSphere Replication, and VMware Site Recovery Manager can all complement App Volumes deployments and should be considered for a production deployment.

In production environments, avoid deploying only a single App Volumes Manager server. It is far better to deploy an enterprise-grade load balancer to manage multiple App Volumes Manager servers connected to a central, resilient SQL Server database instance.

As with all production workloads that run on vSphere, underlying host, cluster, network, and storage configurations should adhere to VMware best practices with regard to availability. See the vSphere Availability Guide for more information.

App Volumes managers

App Volumes Managers are the primary point of management and configuration, and they broker volumes to agents. For a production environment, deploy at least two App Volumes Manager servers. App Volumes Manager is stateless, all the data required by App Volumes is located in a SQL database. Deploying at least two App Volumes Manager servers ensures the availability of App Volumes services and distributes the user load.

For more information, see the knowledge base article App Volumes Sizing Limits and Recommendations (67354).

Although two App Volumes Managers might support the 8,000 concurrent users design, additional managers are necessary to accommodate periods of heavy concurrent usage, such as for logon storms.

Table 8: Strategy for scaling App Volumes

Decision	Four App Volumes Manager servers were deployed with a load balancer.
Justification	This strategy satisfies the requirements for load and provides redundancy.

Multiple vCenter server considerations

Configuring multiple vCenter Servers is a way to achieve scale for a large Horizon pod, for multiple data centers, or for multiple sites.

With machine managers, you can use different credentials for each vCenter Server, but vSphere host names and datastore names must be unique across all vCenter Server environments. After you have enabled multi-vCenter-Server support in your environment, it is not recommended to revert back to a single vCenter Server configuration.

Note: In a multiple-vCenter-Server environment, a package is tied to storage that is available to each vCenter Server. It is possible that a package visible in App Volumes Manager could be assigned to a VM that does not have access to the storage. To avoid this issue, use storage groups to replicate packages across vCenter Servers. For instructions, see Configure Storage Groups in App Volumes Manager.

Multiple AD domain considerations

App Volumes supports environments with multiple Active Directory domains, both with and without the need for trust types configured between them. See Configuring and Using Active Directory for more information.

An administrator can add multiple Active Directory domains through the Configuration > Active Directories tab in App Volumes Manager. An account with a minimum of read-only permissions for each domain is required. You must add each domain that will be accessed for App Volumes by any computer, group, or user object. In addition, non-domain-joined entities may be allowed by enabling this setting.

Figure 14: Enabling non-domain-joined entities

App Volumes with Azure Virtual Desktop & Windows 365

App Volumes has been available as a marketplace application since version 2312. App Volumes 4 version 2406 introduced persistent desktop support, enabling application delivery to Microsoft Windows 365 persistent desktop environments. This section will focus on the ‘major release’ capabilities of App Volumes version 2412.

From version 2412, App Volumes deployed from the marketplace support Azure Virtual Desktop with Microsoft Entra ID (formerly Azure AD). This capability extends the synchronization of application packages, markers, and entitlements between the App Volumes Admin UI and the Azure Virtual Desktop, allowing the AVD Administrator to assign App Volumes applications directly from the AVD Portal. Here is a detailed list of the Configuration Scenarios for Azure Marketplace Deployment of App Volumes.

Figure 15: App Volumes deployment from Azure Marketplace 

Considerations for deploying App Volumes from the Azure Marketplace

App Volumes is available to deploy from Azure Marketplace with flexible deployment options outlined in the Configuration Scenarios of Azure Marketplace Deployment of App Volumes Manager. It is advisable to identify the components in your infrastructure before deploying App Volumes.

• App Volumes supports Azure Virtual Desktop configured with (Microsoft Active Directory, Entra ID, or a Hybrid directory service).
• Support for App Volumes integration with Azure Virtual Desktop, using Azure Marketplace deployment automation, is supported from App Volumes version 2410 or newer.
  • The benefits of deploying App Volumes integrated with Entra ID are outlined in the Configuration Scenarios of Azure Marketplace Deployment of App Volumes Manager, allowing you to carry out App Volumes application entitlements directly from the Azure Virtual Desktop Portal.
  • App Volumes Application synchronization with Azure Virtual Desktop is possible when integrated with Entra ID.
  • Desktop and RemoteApp Application Group types are supported when App Volumes is integrated with Entra ID.

Azure considerations

Azure infrastructure considerations for deploying an App Volumes Manager are detailed in the Prerequisites for Deploying App Volumes Manager through Azure Marketplace and Resources Used in App Volumes Deployment on Azure environment.

• The customer environment is assumed to have an Azure Subscription, a configured Entra ID, and a deployed Azure Virtual Desktop infrastructure set up and available for App Volumes deployment and integration.
• Azure Virtual Desktop domain integration choice has already been made (Entra ID, Hybrid AD, or legacy Microsoft ADDS). Directory Services details have been collected to be input as part of the Marketplace workflow deployment.
• App Volumes deployment is enabled at an Azure tenant level and deployed into a designated subscription.
• Marketplace deployment provides the choice to use:
  • Existing Azure storage and file shares or provision new storage account and automated creation of new file shares.
  • An existing SQL Database if the deployment is for production usage; otherwise, the choice to provision an SQL instance as part of the workflow automation, whereby a SQL Express instance is installed and configured within the App Volumes Manager Virtual Machine. SQL Express instance should be considered only for proof-of-concept deployments.
  • Choose to integrate with Azure AVD during the marketplace deployment workflow or input the Azure subscription details after the App Volumes Manager deployment within the Admin UI Integration tab to complete the integration process.
• Azure access and permissions:
  • Sufficient privileges of the administrator deploying App Volumes Manager from the Azure Marketplace.
  • The resources that are automatically deployed as part of Azure Marketplace are as follows: Azure virtual machine, public IP address, Azure virtual network, Azure storage and file share, Azure private endpoint, and network security group. 
  • Ensure that you are aware of these resources. The rest of the components required are as follows: resource group, subnet, network interface, Azure virtual desktop host pool, and App Volumes agent. 
• Resource Group (RG) – the automation will require a target resource group. The resource group is created as part of the automation, or an existing empty resource group can be pre-provisioned and selected. The RG will house all the infrastructure components deployed by the automation. However, existing infrastructure will have already been sourced from their respective RGs.
• For an existing host pool, update the existing image with the App Volumes Agent and rebuild the host pool.
• Deploy an App Volumes Packaging VM with a configuration similar to the AVD Session host image/template to capture and package App Volumes Application Packages accurately.
  • Follow the guidelines to capture and package EXE, MSI, or MSIX-based applications.

Database design considerations

A local SQL Server Express Database is installed by default in the virtual machine where App Volumes Manager is installed. However, this option is not recommended for production environments.

• For production and large-scale deployments, ensure that you have an existing SQL database provisioned and choose to configure a Remote SQL server database when initiating workflow deployment from the Azure Marketplace.
• Supported databases listed under the System Requirements in the App Volumes install guide.

Directory services design considerations

App Volumes deployed from the Azure Marketplace integrated with Azure Virtual Desktop support Microsoft Active Directory Domain Services and Microsoft Entra ID (formerly Azure Active Directory).

• Currently, for App Volumes, Microsoft Entra ID can only be used as the domain when integrating App Volumes Manager with Azure Virtual Desktop.
• The Configuration Scenarios of Azure Marketplace Deployment of App Volumes Manager section of the App Volumes install guide provides a list of App Volumes capabilities that will be enabled when integrating with Azure Virtual Desktop with Entra ID / hybrid as well as limitations with an Azure Virtual Desktop with Microsoft Active Directory environment.

Network design considerations

When deploying App Volumes in the Azure Marketplace, the same virtual network is required so that other components in the Azure infrastructure, such as virtual machines (Active Directory and App Volumes Manager) and file shares, can communicate with each other. It is recommended that all virtual machines reside in the same region as the virtual network.

App Volumes deployed through Azure Marketplace for Azure Virtual Desktop, see the Deploy App Volumes Manager through Azure Marketplace.

Product Reference: Resources Used in App Volumes Deployment on Azure.

Storage design considerations

The Azure Marketplace workflow automation allows you to create new Azure file shares or use existing file shares.

• Choosing to use existing file shares, will require the administrator to add the file shares are part of the post installation tasks once the App Volumes Manager server is provisioned and logged into the Admin UI.
• If you have opted for the automatic provision of these resources then a Public IP address and Azure storage and file share are deployed only.

Follow the App Volumes Integration with Azure Virtual Desktop App Attach guide to understand the deployment workflow of the App Volumes management components, configuration of the Azure Virtual Desktops, and delivery of App Volumes packages. And the latest updates to App Volumes from the release notes.

App Volumes with Amazon WorkSpaces Core & AppStream 2.0

Omnissa App Volumes has been available as a marketplace application since version 2309 and supports AppStream 2.0. App Volumes 4 version 2406 introduced persistent desktop support, enabling application delivery to Amazon Workspaces Core persistent desktop environments. AWS CloudFormation service automation deploys an EC2 instance of the App Volume Manager server from the AWS Marketplace.

App Volumes manages and delivers applications to users of Amazon AppStream 2.0. The App Volumes product documentation details the preparation for App Volumes for Amazon AppStream 2.0 and the detailed Deployment Workflow of App Volumes for Amazon AppStream 2.0.

Figure 16: App Volumes deployment from AWS Marketplace

Considerations for deploying App Volumes from the AWS Marketplace

Deploying App Volumes from AWS Marketplace uses the AWS CloudFormation service. You can create a stack which deploys an Amazon EC2 instance in which App Volumes Manager is automatically installed and partially configured. Review the Preparing for App Volumes for Amazon AppStream 2.0 section of the product documentation to help you with the pre-requisites to deploy App Volumes from the AWS Marketplace for Amazon AppStream 2.0.

Once you have the pre-requisites in place you can look at the Workflow of App Volumes for Amazon AppStream 2.0 section to understand the deployment process and post deployment tasks needed to get App Volumes stood up within your AWS subscription.

Additional considerations during your deployment selection process will be to:

• If you have decided to relicense, then the App Volumes Manager server EC2 instance deploys with a trial license. If you wish to apply for a production license, download the App Volumes license file from the Omnissa Customer Connect portal and update the license file into the App Volumes admin UI as part of the post-install tasks or after exploring the product trial period.
• It is not recommended to change the default size of the EC2 virtual machine that will be deployed for the App Volumes Manager.
• Get your pre-requisites in place for a smooth deployment, Integrate with Microsoft Active Directory Services and use a pre-provisioned AD service account and AD group to be identified for the App Volumes Administration.
• App Volumes for Amazon AppStream 2.0 solution does not support Writable Volumes.
• When deploying App Volumes for Amazon AppStream 2.0, Amazon EC2 instance and Amazon EC2 Security Group are always deployed whereas Amazon FSx FileSystem and Elastic IP address are deployed only if you have opted for the AWS CloudFormation service to provision these resources.

• Download the App Volumes Agent from the Omnissa Customer Connect portal to be used during the Image build/update process of AppStream 2.0 Image using Image Builder.
• For Amazon Workspaces Core, the virtual desktop image built via Image Builder or another automated method must be updated by installing the App Volumes Agent and pointing back to the deployed App Volumes Manager. The application assignment is configured from the App Volumes admin UI.

AWS considerations

• To use Omnissa App Volumes in the AppStream 2.0 service, you must have the required permissions to access certain AWS services. The product documentation will provide everything needed for an App Volumes deployment for Amazon AppStream 2.0 from AWS Marketplace.
  • Ensure that you have an AWS account for administration with permission to access the AppStream 2.0 service.
  • It is essential to have permission to access Amazon IAM or the IAM Identity Center, which will be required to set up SAML.
  • AWS Managed Microsoft Active Directory (AD) should already be configured.
  • Ensure that a VPC is created as will be prompted to be selected while filling up the the CloudFormation deployment form prior to deployment.

Database design considerations

A local SQL server express database is installed by default in the virtual machine where App Volumes Manager is installed. However, this option is not recommended for production environment. For production environment, ensure that you have an existing SQL server database.

•  Choose to configure a Remote SQL database for production and large-scale deployments.
• The Active Directory, RDS (Relational Database Service), and file share must belong to the same subnet to communicate with each other.
• If you use a remote database installed on an Amazon EC2 instance, ensure you use a public IPv4 address as the database hostname.

Directory services design considerations

For App Volumes for Amazon AppStream 2.0 follow the documented permissions required for SAML and AWS Managed Microsoft Active Directory.

• Active Directory ID, Active Directory service account credentials, Active Directory NetBIOS name, and Active Directory DNS addresses will be required when configuring the file share if you choose the default option wherein the file share is provisioned by the AWS CloudFormation service.
• When configuring Active Directory in the App Volumes Manager admin UI, you must use the same Active Directory setup which is used during file share configuration.

For App Volumes for Workspaces Core will follow the Microsoft Active Directory domain pre-requisites and functional levels defined in the App Volumes Installation Guide documentation.

App Volumes Manager connects to Active Directory using a service account which only requires read access to the target Active Directory domain. Its recommended to have a dedicated service account for the App Volumes Manager connecting into the Active Directory with detailed requirements described in the product document.

An Active Directory group will need to be created or identified that will be added as an App Volumes Administrators Group in the App Volumes Admin UI during initial setup. This AD group will also need to have local administrative permissions to the App Volumes Managers being deployed within the environment.

Network design considerations

As the deployment is automated using AWS CloudFormation, ensure that the pre-requisites are provisioned so as to be made available for selection during the AWS Marketplace deployment selection process. Key network considerations is to ensure that the Active Directory, RDS (Relational Database Service), and file share must belong to the same subnet so that they can communicate with each other.

Review the Elastic IP address and security group requirements documented in the Resources used in the App Volumes deployment on Amazon AppStream 2.0.

Amazon AppStream 2.0, network requirements are documented under Resources used in App Volumes Deployment on Amazon AppStream 2.0.

Storage design considerations

You will be asked to provide the file share configuration during the AWS Marketplace deployment wizard. To configure a file share, you must either select “Deploy a new file share” or select “Yes, configure an existing file share,” which will need to be pre-provisioned. This is detailed in the Workflow of App Volumes for Amazon AppStream 2.0.

• App Volumes for Amazon AppStream 2.0 uses Amazon FSx for Windows. Ensure that you have permissions to use Amazon FSx for Windows. To use Amazon FSx for Windows, see the Getting Started section in the Amazon FSx for Windows File Server User Guide.
• Identify, validate, and/or update the storage section. App Volumes supports SMB version 3.0 storage infrastructure like the AWS FSx for Windows.
• App Volumes packages are stored in the VHD format along with the JSON file for the package.

More details can be found in the product documentation App Volumes for Amazon AppStream 2.0 and get the latest updates on new improvements to App Volumes from the release notes.

Cloud-hosted App Volumes

Omnissa Horizon Cloud Service delivers virtualized Windows desktops and apps to target endpoint devices. As the Horizon Cloud - next-gen cloud-based service provides and maintains all the critical management tools used in a Desktops-as-a-Service (DaaS), this includes App Volumes functionality baked into the cloud control plane to deliver App Volumes hosted applications to the Horizon Cloud Services hosted VDI and RDSH pools. Read about Omnissa Horizon Cloud Service-next-gen.

App Volumes with Horizon Cloud Service

Omnissa App Volumes streamlines application management by decoupling applications from the OS image, enabling real-time application delivery and one-to-many provisioning. This functionality integrates into Horizon Cloud Service. The cloud service includes App Volumes management components, while App Volumes agents and packages are hosted within the deployed Horizon Edge.

Components

The following is the list of App Volumes components hosted as a service and installed within the Horizon Cloud Service Windows virtual machines and Azure file objects.

Figure 17: App Volumes service

• App Volumes Manager – component is hosted as a service within Horizon Cloud Service, and the administrator can manage App Volumes assignments using the Horizon Control Plane.
• App Volumes Agent – can be enabled and installed during image creation.
• App Volumes Database – is maintained and managed within the Horizon Control Plane.
• Azure Storage for App Volumes – An Azure storage account will be required to store the App Volumes packages. Azure private endpoint solution can access storage accounts and file shares securely. Azure private endpoint can be configured from the Horizon Universal Console for a storage account when deploying a new Horizon Edge or an existing Horizon Edge. Read more on App Volumes storage requirements within Horizon Cloud Service.
• Applications – an App Volumes Application contains one or more packages, each representing a different version of the application and its programs. Users and groups are entitlements to an application.
• Packages - App Volumes groups one or more Programs into Packages based on the requirements of each use case. A package is a virtual disk containing one or more programs captured together.

Read more on App Volumes Applications and Packages.

Prerequisites

App Volumes is hosted as a service on Horizon Cloud Service- next-gen and managed from the Horizon Universal Console. Following the Requirements Checklist for Deploying a Microsoft Azure Edge, there are additional prerequisites for using App Volumes Applications and reviewing the Horizon Edge-related requirements.

Replication

If you have multiple Horizon Edge deployments, to replicate a captured or imported application package from one Horizon Edge to another, you must manually copy the packages from the file share of the source Horizon Edge to the file share of the destination Horizon Edge. The product documentation provides prerequisites and the procedure for manual replication.

Multi-site

As described in the Omnissa Horizon Cloud Service-next-gen reference architecture, App Volumes is a service hosted in the Horizon Control Plane. It provides application management of App Volumes packages to connected virtual endpoints created in each Horizon Edge.

Figure 18: App Volumes multi-site deployment

Horizon Edge deployments using cloud-native providers support App Volumes functionality. However, Horizon 8 pods do not use the App Volume functionality provided by the Horizon Cloud Service.  By default, applications are stored in the primary provider of Horizon Edge in storage. The Horizon Cloud Service-next-gen reference architecture discusses the multi-site design in detail.

If you have multiple Horizon Edge deployments in cloud-native providers, to replicate a captured or imported application package from one Horizon Edge to another, you must manually copy the packages from the file share of the source Horizon Edge to the file share of the destination Horizon Edge. For more information, see Manually Replicate App Volumes Application Packages Between Horizon Edge Deployments.

The Horizon Cloud Service-next-gen reference architecture provides details on the delivery of App Volumes Application Packages to virtual endpoints and the methods of entitlement.

For more information, see Using App Volumes.

Database design considerations

Horizon Cloud Service Next-Gen provides a is a modern cloud-first, multi-cloud Desktop as a Service (DaaS) and the App Volumes capabilities are provided as a managed service where the database that contains configuration information for applications, packages, Markers, and user entitlements are stored and is a service provider managed database within the Horizon Cloud Control Plane.

Directory services design considerations

The Horizon Cloud Service, a next-generation platform, separates user identity from machine identity. This distinction enables you to select various identity solutions for use with Horizon Cloud Service while maintaining the platform's security and functionality. More details on the supported user identity and machine identity can be found in the Horizon Cloud Service Next-Gen architecture documentation.

Table 9: Horizon Cloud Service Next-Gen identity support

User Identity Provider Chosen	Possible Machine Identity Providers
Microsoft Entra ID (Azure Active Directory)	Microsoft Entra ID (Azure Active Directory) Active Directory
Omnissa Access (Workspace ONE Access)	Active Directory

Network design considerations

Cloud-Hosted App Volumes is a managed service within Horizon Cloud Service – next-gen. The creation of the image includes enabling App Volumes and deploying the App Volumes Agent within the image and the pools created. The App Volumes Agent communicates with the Horizon Agent, which in turn connects to the Horizon Cloud control plane using the Message Queuing Telemetry Transport (MQTT) protocol. This communication process is detailed in the Network Ports section of Horizon Cloud Service – next-gen. For a comprehensive list of port requirements, refer to the product documentation. These requirements support App Volumes features for use with Horizon Cloud Service on Microsoft Azure.

Storage design considerations

App Volumes packages are stored in the VHD format and delivered from Microsoft Azure fileshares which are documented under the prerequisites section in the product documentation.

Unmanaged App Volumes for physical endpoints

Figure 19: Unmanaged delivery of App Volumes packages

With the release of version 2412, App Volumes now support three package formats. App Volumes package capture now supports VMDK, VHD, and MSI output formats for specific platform delivery.

The App Volumes Agent version 2412, and later, can now be installed on physical Windows endpoints without needing the App Volumes Manager. This functionality allows target physical Windows endpoints to receive App Volumes application packages from an enterprise delivery solution in the MSI format and launch the application using the App Volumes Agent.

Delivery to physical windows endpoints

The App Volumes agent is installed on Windows endpoints and enables application delivery to physical desktops, laptops, and cloud desktops (including Windows 365 Cloud PCs). App Volumes Tools captures and packages the App Volumes application to an MSI package, which can then be delivered using an Endpoint Management solution like Omnissa Workspace ONE UEM or Intune. The App Volumes Manager is not required.

To successfully deliver and launch App Volumes MSI packages to a physical Windows endpoint device, the target Windows endpoint must have the App Volumes Agent version 2412 or newer installed as a prerequisite. The screenshot below shows the configuration step during the deployment of the App Volumes Agent, which gives the administrator the option to choose “configure agent without App Volumes Manager” when deploying the agent to physical endpoints. The same can be deployed via an enterprise software delivery solution using the App Volumes Agent MSI or the silent installer string.

Figure 20: App Volumes Agent installation for physical Windows endpoints

App Volumes MSI package delivery methods

App Volumes tools can capture an application in three output formats: a VMDK, a VHD, and an MSI package. The following section outlines three methods of delivering an App Volumes MSI package or VHD package using the software delivery capabilities of an enterprise management solution for physical Windows endpoints.

• Capture and delivery of App Volumes MSI package to physical Windows endpoints
• Capture and delivery of App Volumes VHD package to physical Windows endpoints
• Convert existing App Volumes VHD or VMDK packaged application to MSI and deliver the package to physical Windows endpoint 

Capture and delivery of App Volumes MSI package to physical Windows endpoints

Figure 22: Capture and delivery of App Volumes MSI package to physical Windows endpoints

The above diagram shows a high-level workflow that is divided into three tasks, indicated by the circles numbered and outlined below:

Task 1 – Capture and package an enterprise application using App Volumes tools using the ‘appcapture.exe’ syntax provided in the Capture and App Volumes Application section of the App Volumes Administration Guide.

Task 2 – The output App Volumes MSI package is stored in a repository accessible by the enterprise management solution, and the software delivery parameters are configured to deliver the App Volumes MSI application silently to the target physical Windows endpoint.

Task 3 – This task brings in the logic that will need to be configured by the enterprise endpoint solution during the software delivery of the App Volumes MSI package to incorporate a decision workflow to:

1.         Check if the target physical Windows endpoint has the App Volumes Agent version 2412 installed before the App Volumes MSI application is delivered. If not present, install the App Volumes Agent for physical endpoints silently with the syntax: msiexec.exe /i “App Volumes Agent.msi” /qn DIRECT=1
2.        If the App Volumes Agent 2412 is validated to be on the target physical Windows endpoint, then deliver the App Volumes MSI application silently using the documented syntax: “application_package_name.msi” DELIVERYTYPE=OnDemand NOARP=0

Capture and delivery of App Volumes VHD package to physical Windows endpoints

Figure 23: Capture and delivery of App Volumes VHD package to physical Windows endpoints

The above diagram shows a high-level workflow that is divided into three tasks, indicated by the circles numbered and outlined below:

Task 1 – Capture and package an enterprise application to a VHD output file using App Volumes tools using the ‘appcapture.exe’ syntax provided in the Capture and App Volumes Application section of the App Volumes Administration Guide.

Task 2 – The output App Volumes VHD package is stored in a repository accessible by the enterprise management solution, and the application VHD disk is delivered by PowerShell parameters configured to deliver the App Volumes VHD application silently to the target physical Windows endpoint.

Task 3 – This section will bring in the logic that will need to be configured by the enterprise endpoint solution during the software delivery of the App Volumes VHD package to incorporate a decision workflow to:

1.         Check if the target physical Windows endpoint has the App Volumes Agent version 2412 installed before the App Volumes MSI application is delivered. If not present, install the App Volumes Agent for physical endpoints silently with the syntax: msiexec.exe /i “App Volumes Agent.msi” /qn DIRECT=1
2.        If the App Volumes Agent 2412 is validated to be on the target physical Windows endpoint, then deliver the App Volumes VHD disk as an application silently using the documented syntax: Install-AV-Package <path_of_the_vhd_package> {Classic|OnDemand}

Convert existing App Volumes (VHD or VMDK) packaged application to MSI and deliver the package to physical Windows endpoint

Figure 24: Convert App Volumes (VHD or VMDK) application to MSI for delivery to physical Windows endpoint 

The above diagram shows a high-level workflow that is divided into three tasks, indicated by the circles numbered and outlined below :

Task 1 – Use the App Volumes Tools ‘appcapture.exe’ convert syntax provided in the Capture and App Volumes Application section of the App Volumes Administration Guide to convert existing App Volumes applications from their VHD/VMDK format to an MSI format.

Task 2 – The output App Volumes MSI package is stored in a repository accessible by the enterprise management solution, and the software delivery parameters are configured to deliver the App Volumes MSI application silently to the target physical Windows endpoint.

Task 3 – This section will bring in the logic that will need to be configured by the enterprise endpoint solution during the software delivery of the App Volumes MSI package to incorporate a decision workflow to:

1.         Check if the target physical Windows endpoint has the App Volumes Agent version 2412 installed prior to delivery of the App Volumes MSI application. If not present, install the App Volumes Agent for physical endpoints silently with the syntax: msiexec.exe /i “App Volumes Agent.msi” /qn DIRECT=1
2.        If the App Volumes Agent 2412 is validated to be on the target physical Windows endpoint, then deliver the App Volumes MSI application silently using the documented syntax: “application_package_name.msi” DELIVERYTYPE=OnDemand NOARP=0

Key design considerations for Workspace ONE UEM

The Workspace ONE UEM administrator should consider the following before deploying an App Volumes packaged MSI application to a target Windows endpoint.

• The App Volumes Agent.msi package should be available in the Workspace ONE UEM repository to deploy to target Windows endpoints.
• The target Windows endpoint should have the App Volumes Agent installed.
• The App Volumes Agent installed on the physical Windows endpoint should be with the option “configure agent without App Volumes Manager” enabled.
• While delivering the App Volumes application in the MSI packaged format to the target Windows endpoint, the Administrator should set a Workspace ONE UEM condition to validate and confirm the presence of the App Volumes Agent version 2412 or newer before delivering any App Volumes MSI package. Otherwise, the software delivery tool should first deploy the App Volumes Agent silently before deploying any App Volumes packaged application.

Key design considerations for Intune

The Microsoft Intune administrator should consider the following before deploying an App Volumes packaged MSI application to a target Windows endpoint.

• The App Volumes Agent.msi package should be available in the Intune repository to deploy to target Windows endpoints.
• The target Windows endpoint should have the App Volumes Agent installed.
• The App Volumes Agent installed on the physical Windows endpoint should be with the option configure agent without App Volumes Manager enabled.

While delivering the App Volumes application in the MSI packaged format to the target Windows endpoint, the administrator should set an Intune condition to validate and confirm the presence of the App Volumes Agent version 2412 or newer before delivering any App Volumes MSI package. Otherwise, the software delivery tool should first deploy the App Volumes Agent silently before deploying any App Volumes packaged application.

Database design considerations

Unmanaged App Volumes for physical Windows endpoints will not require a database as no App Volumes Manager is deployed in the environment.

Directory services design considerations

There is no dependency on the App Volumes Agent requiring directory services as the agent is deployed as an unmanaged agent to target physical Windows endpoints, and delivery of App Volumes MSI packages will be carried out by the enterprise software delivery solution and not controlled by an App Volumes Manager server.

Network design considerations

Delivery of App Volumes packages to physical Windows endpoint management solutions manages endpoints and does not have communication between the App Volumes Agent and an App Volumes Manager, configured with the option configure agent without App Volumes Manager. The endpoint management solution manages network connectivity during the package distribution to the target physical Windows endpoint to deliver the App Volumes MSI packages. It is to be documented in the respective product documentation.

Storage design considerations

The enterprise software delivery solution will govern the storage requirements of the App Volumes MSI packages. As an example, WS1 UEM product documentation describes the Software Distribution of Win32 Applications use of File Storage a repository to store and distribute Win32 apps and the App Volumes package is an MSI file that can be used for distribution to target physical Windows endpoints.

Packages

This section provides guidance about creating, sizing, scaling, provisioning, configuring, and updating App Volumes Packages and Writable Volumes.

Package capture process

Figure 25: Application capture using App Volumes Agent vs. App Volumes tools

There are two methods to capture an application using App Volumes. You can trigger an application capture from the App Volumes Manager to a designated App Volumes packaging virtual machine that has the App Volumes Agent installed or capture an application on a standalone Windows endpoint installed with the App Volumes tools and then import the application package capture output into the App Volumes Manager.

Omnissa App Volumes Application Capture Suitability Assessment knowledgebase article can guide identifying and selecting suitable applications for App Volumes packaging.

App Volumes package capture using App Volumes Agent

1. App Volumes Manager initiates the application capture process by creating an Application and a package ready for capture, then targeting an available App Volumes packaging virtual machine installed with the App Volumes Agent. This will attach the template to the packaging virtual machine, ready to capture an application.
2. Log into the packaging virtual machine to capture the desired application, return to the App Volumes Manager, log in to the admin UI to validate the successful creation application, and import the package into the App Volumes identified storage.
3. Now, you can assign your application to target VDI and RDSH endpoints.
4. Review the complete guide to Application Packaging using the App Volumes Management console.

App Volumes package capture using App Volumes Tools

1. A standalone Windows virtual machine built using the App Volumes packaging virtual machine; instead of the App Volumes Agent, this capture machine is installed with the App Volumes Tools.
2. The administrator of this packaging virtual machine can use the command line tools provided within the App Volumes tools to initiate an application capture, and the resulting output App Volumes package can be in VMDK, VHD, or MSI formats.
3. The output is uploaded to the desired virtual desktop or physical infrastructure that will consume the delivery of the App Volumes application. If the target VDI or RDSH endpoints are vSphere hosted, then the App Volumes package output must be in the VMDK format and uploaded to vSphere-supported storage via the App Volumes Manager. And if the target VDI or RDSH endpoint hosting platform is non-vSphere, the App Volumes package output must be in the VHD format and uploaded to supported storage via the App Volumes Manager.
4. App Volumes applications delivered by enterprise software delivery tools to physical endpoints will require the MSI file format as the desired output from the App Volumes Tools capture process.
5. Review the complete guide to Application Packaging using the App Volumes Tools (CLI method).

Considerations choosing the method of application capture

If you have an App Volumes Infrastructure managed by App Volumes Administrators, who are responsible for creating and triggering the application capture process from the App Volumes Manager’s management console, then the target App Volumes packaging virtual machine will need to be prepared with the installation of the App Volumes Agent to receive the package template ready to capture applications. You will then follow the guide to Application Packaging using the App Volumes Management console.

App Volumes tools is used for standalone application capture. If you have a requirement to isolate the application capture from the App Volumes Infrastructure, then the App Volumes packaging virtual machine is set up with the App Volumes tools instead of the App Volumes Agent. The output from the application capture on the standalone packaging virtual machine is then imported into the App Volumes infrastructure from the App Volumes Manager.

App Volumes tools can generate App Volumes packages in the VMDK, VHD, and MSI formats.

App Volumes tools can convert App Volumes package VMDK, VHD, and MSI formats, as well as App-V packages to App Volumes supported formats.

App Volumes tools can create App Volumes packages using ThinApp and MSIX packages.

Package formats

With the release of version 2412, App Volumes now support three pPackage formats. App Volumes package capture now supports VMDK, VHD, and MSI output formats for specific platform delivery.

VMDK

The App Volumes VMDK-based package format delivers App Volumes Applications to vSphere based for VDI and RDSH endpoints.

VHD

The App Volumes VHD-based package format delivers App Volumes Applications to non-vSphere-based for VDI and RDSH endpoints.

MSI

The App Volumes MSI-based package format delivers App Volumes Applications to physical target endpoints. The App Volumes MSI package is delivered by enterprise software delivery products like Omnissa Workspace ONE UEM or third-party solutions like SCCM or Intune.

Application assignment and attach process - manager and agent communication

App Volumes works on a client-server-based architecture. The App Volumes software installer's core components are the App Volumes Agent and the App Volumes Manager server. The installer also contains a third component, the App Volumes Tools, a standalone component that will be discussed in more detail within this document when we look at the App Volumes infrastructure components that make up the deployment of App Volumes within your IT Infrastructure.

The App Volumes Agent initiates communication with the App Volumes Manager at machine power on (startup), user login, user logoff, and machine power off (shutdown). 

Figure 5: App Volumes Agent and Manager communication

App Volumes 4, version 2111 and later, brings an additional capability for user-initiated communication between the App Volumes Agent and the App Volumes Manager. First, “Published Apps On Demand” takes the App Volumes Agent through an extra call to the App Volumes Manager, communicating a user-initiated request for application assignment and launch. The package delivery method should be configured to “On-Demand” to leverage this delivery method. Refer to the administrative guide to learn more about package delivery models.

App Volumes 4, version 2111 and later, allow for a user-initiated capability of App Volumes, allowing a user to reach out to the App Volumes Manager via the Agent, trigger the entitled Package to be assigned and launch the Application using the App Volumes App Link.

Horizon Published Apps on Demand

App Volumes 4 in conjunction with Horizon 8 enables the capability to assign Horizon Published Apps on Demand. This combines the power of App Volumes along with Horizon Remote Desktop Services Host (RDSH) farms to simplify the delivery of published applications. Also, see RDSH Integration with Packages for more information on using App Volumes with Horizon Published Applications.

When a user requests a published application provided through Apps on Demand, App Volumes attaches the package containing the application, in real-time, to a suitable RDSH host in a Horizon Farm to deliver the application session to the user.

The operating system image used in the RDSH farm can be kept generic as applications do not need to be installed into the golden image but instead are attached only when needed. This allows the same RDSH farm to host sessions from many different applications without requiring dedicated farms for each set or type.

In addition to the logical components described in the Architecture Overview section earlier, a Horizon environment with Horizon Connection servers, running Horizon 8 version 2212 or later, is required.

Figure 26: Apps on Demand components

To enable Apps on Demand you need to perform the following steps.

1. Create an Automated Instant-Clone Farm
2. Register App Volumes Managers in Horizon Connection Servers
3. Associate App Volumes Manager with a Farm
4. Create Application Pools and entitle users

For more instructions, see Deliver Horizon Published Apps on Demand.

When a user requests an application delivered by Horizon Apps on Demand, Horizon and App Volumes work together to attach the application package to an RDSH server in real-time.

Figure 27: Apps on Demand logical flow

1. The user selects the published application from their Horizon entitlements.
2. The Horizon Connection Server communicates with an App Volumes Manager to request attachment of the application package to a suitable RDSH server.
3. The App Volumes Manager requests the vCenter Server to attach a virtual disk.
4. The virtual disk containing the application package is attached to the target RDSH virtual machine.
5. The protocol session for the application is established from the Horizon Client to the Horizon Agent running on the RDSH.

Additional packaging operations

See the section Understand packages and packaging for day 2 operations of App Volumes Configuration

Writable Volumes

Writable Volumes can be used to persist a variety of data as users roam between non-persistent desktop sessions. See Working with Writable Volumes for information on creating and managing writable volumes.

Writable Volumes are often complemented by Dynamic Environment Manager to provide a comprehensive profile management solution.

Writable Volume templates

Several Writable Volume templates are available to suit different use cases. See Configuring Storage for options.

The UIA (user-installed applications)-only template provides persistence for user-installed applications. After a Writable Volume with the UIA-only template is created and assigned to a user, that user can install and configure applications as they normally would. The installation is automatically redirected to the Writable Volume and persisted between desktop sessions.

Note: For this functionality to work properly, users require account permissions in Windows that allow application installation. You may also use Dynamic Environment Manager Privilege Elevation to complement UIA-only Writable Volumes. For more information, see, Configuring Privilege Elevation.

Note: Due to the complexities of file and registry conflicts, we recommend that you use either packages or Writable Volumes with a UIA-based template for a given VM. For example, if a user installs a patch or update to an application, even if a package or base is updated, the writable volume will still retain older files that will be available to the user.

Key differences between packages and Writable Volumes

There are some key differences and considerations for using Packages and Writable Volumes.

• Package VMDKs are mounted as read-only and can be shared among all desktop VMs within the data center.
• Writable Volumes are dedicated to individual users and are mounted as the user authenticates to the desktop. Writable Volumes are user-centric and roam with the user for non-persistent desktops.

Note: When files and registry entries exist in multiple places, the files and registry entries in Writable Volumes will always take precedence over files and registry keys in packages and in the base image.

Table 9: Implementation strategy for App Volumes Writable Volumes

Decision	Writable Volumes were created for and assigned to end users who required the ability to install their own applications. The UIA-only Writable Volume template was used.
Justification	Writable Volumes provide added flexibility for end users who are permitted to install software outside of the IT-delivered set of applications. The UIA-only template ensures application installation and configuration data is stored, while profile data is managed using other technologies. If a Writable Volume becomes corrupt, applications can be reinstalled without the risk of data loss.

Performance testing for Writable Volumes

Writable Volumes are read-write. Storage utilization patterns are largely influenced by user behavior with regard to desktop logins and logouts, user-installed applications, and changes to local user profiles. Group each set of similar users into use cases, and evaluate performance based on peak average use.

Additional Writable Volumes operations

See the section Additional Configuration Options for Writable Volumes of App Volumes Configuration.

Multi-site design

Multi-site implementations should be designed using a multi-instance model with separate instances per site. In this model, each instance works independently, with its own set of App Volumes Managers and its own database instance. When deploying separate instances in different sites, separate, local SQL servers should be used.

Using separate instances per site is simple to implement and allows for easy scaling if you have more than two sites.

During an outage, the remaining instances in the remaining sites can provide access to packages with no intervention required. For detailed information on the failover steps required and the order in which they need to be performed, refer to Failover.

Figure 28: App Volumes multi-instance model

This strategy makes use of the following components:

• App Volumes Managers – At least two App Volumes Manager servers are used in each site to form an instance, for local redundancy and scalability.
• Load balancers – Each site has its own namespace for the local App Volumes Manager servers. This is generally a local load balancer virtual IP that targets the individual managers. 
  Note: The App Volumes Agent, which is installed in virtual desktops and RDSH servers, must be configured to use the appropriate local namespace.
• Separate databases – A separate database is used for each instance; each site should have separate SQL servers. That is, you have a separate Windows Server Failover Clustering (WSFC) cluster and an SQL Server Always On availability group listener for each site, in order to achieve automatic failover within a site.
• vCenter Server machine managers – The App Volumes Manager instance and servers at each site have machine managers registered only for the vCenter servers from their own site.

Table 10: Strategy for deploying App Volumes in multiple sites

Decision	App Volumes was set up in the second site used for Horizon (on-premises). A separate database and App Volumes instance deployment option was used. An NFS datastore was used as a common datastore among the storage groups to facilitate cross-site package replication.
Justification	This strategy provides App Volumes capabilities in the second site. The separate-databases option is the most resilient, provides true redundancy, and can also scale to more than two sites. With packages replicated between sites, the packages are available for use at both locations.

Replication of packages

Application packages can be replaced or copied from one App Volumes instance to another. This enables the packages to be reused in multiple deployments and locations.

vSphere storage replication

When using vSphere storage, a shared, non-attachable datastore can be added to the storage groups of different App Volumes instances to automatically replicate packages from one instance to another. This shared datastore must be visible to at least one vSphere host from each App Volumes instance. As this shared datastore is configured to be non-attachable, it will not be used to deliver attachments to user machines, so does not need to be overly performant, and often a low-cost NFS share is used to provide this.

Figure 29: Replicating VMDK packages between instances with a shared datastore

Using NFS datastores on VMware Cloud on AWS

When deployed on VMware Cloud on AWS, App Volumes can use AWS managed external NFS datastores to assist in the replication of packages from one App Volumes instance to another. AWS managed external NFS datastores are provided by Amazon FSx for NetApp ONTAP. 

These NFS datastores can be attached to VMware Cloud on AWS vSphere clusters and used as shared datastore between different vSphere clusters to facilitate App Volumes package replication between App Volumes instances.

For more information on using Amazon FSx for NetApp ONTAP see:

• VMware Cloud on AWS integration with Amazon FSx for NetApp ONTAP
• Configure Amazon FSx for NetApp ONTAP as External Storage

Using Azure NetApp Files on Azure VMware Solution

When deployed on Azure VMware Solution, App Volumes can use Azure NetApp Files for package replication via storage groups. The Azure NetApp Files NFS datastores can be attached to AVS vSphere hosts and used as shared datastores between different vSphere clusters to facilitate App Volumes package replication between App Volumes instances.

• The Azure NetApp Files datastore must be set as not attachable in the App Volumes Manager.
• Writable Volumes are not supported on Azure NetApp Files.

For more information on using Azure NetApp Files see:

• What is Azure NetApp Files
• Attach Azure NetApp Files datastores to Azure VMware Solution hosts

Manual replication

In some environments, network design might prevent the use of storage group replication between sites. See Copying an AppStack/Packages to another App Volumes Manager instance When Storage Groups not in use (2107127) for more information about manually copying packages from one instance of App Volumes to another.

Multi-instance management

App Volumes instances can be joined together to manage them from a single source instance. Used in combination with storage groups replicating the packages, this allows you to set a source and target relationship between App Volumes instances so that packages are distributed across different App Volumes instances and locations. With App Volumes version 2203, the ability to synchronize metadata, markers, and assignments between instances was added.

A multi-instance deployment of App Volumes provides the capability to:

• Use one App Volumes instance as the source for replicated packages
• Synchronize application and package metadata across all connected App Volumes instances
• Synchronize application and package deletes
• Synchronize application markers across instances (optional)
• Synchronize assignments across instances (optional)
• Assisted replication and import removes the need for import background job

Table 11: Multi-instance components

Component	Description
App Volumes Manager Instance	An App Volumes install bound by a database Multiple App Volumes Manager servers can access a single database
Source Instance	App Volumes instance that synchronizes replicated applications and packages to other App Volumes instances
Target Instance	App Volumes instance with replicated applications and packages that are synchronized by another (source) App Volumes instance
Related Instance	A target instance or a source instance with reference to a current App Volumes Manager instance
Replication	An App Volumes feature which enables the copying of applications and packages between storage locations
Synchronization	An App Volumes feature which ensures information about the replicated applications and packages remain the same across App Volumes Manager instances

When configuring replication between multiple App Volumes instances, you should designate one instance as the source, and the other instances as targets. This gives a star topology, with one instance acting as the source, where the administrative changes will be made. This avoids the risk of having conflicting information from different App Volumes instances.

Figure 30: Star topology with one source instance and multiple target instances

Determine which App Volumes instance you will use as the administrative source. That instance will be where you will create packages and assignments. From that instance, add in the other instances as targets. For more information, see Register an App Volumes Instance as a Target.

To properly set up the source and target instances relationships, configure the following:

• When adding a target instance to a source instance, select the option to enable application package import. You can also select whether to synchronize markers and assignments; with production target instances, you usually want to replicate both markers and assignments.

• On all instances, configure the shared datastore storage location (that is used for replicating between instances) to Not Attachable. This prevents this datastore being used for when mounting application packages. See Manage Storage Locations for instructions.
• On the target instances, mark the shared datastore as read-only. This prevents inadvertent changes on target instances from being replicated back to the source instance, keeping it as the single source of truth for packages.
• Set up packages replication using a shared datastore and storage groups as described in Replication of Packages.
• Storage groups on all instances should be configured to:
  • Automatically Import AppStacks and Packages = Off
  • Automatically Replicate AppStacks and Packages = On

For more detail, see Configure Multiple App Volumes Instances for Application Synchronization and for instruction on the configuration, see the Multi-Instance Configuration section of App Volumes Configuration.

Test and development instances

For App Volumes infrastructure, separate instances of App Volumes, for purposes such as test or development, allow you to carry out certain tasks separate from your production environment. This might include projects such as testing out infrastructure, version, or OS upgrades during which you want to ensure that App Volumes application packages function as intended before upgrading the production environment.

Test and development instances of App Volumes can be defined as targets to the source production instance to allow you to replicate the application packages. You might not want to synchronize all of the application package metadata and can choose whether to include the assignments or markers information. When you add a target instance, you can select which metadata is synchronized to that target instance. This allows you to replicate the packages into the test or dev instance and then add local assignments to the packages within the test or dev instance.

Figure 31: Selective metadata synchronization to test and dev instances

A test or development instance is not intended to be the location for creating application packages. Rather it should be configured as a target instance and packages replicated into it for testing or use in development processes. Capturing and validating application packages should be carried out in the production source instance.

A separate test instance is optional. You do not need to have a dedicated test or development environment to test or verify application packages.

Writable Volumes replication

Writeable Volumes can be replicated between App Volumes instances using storage replication of the datastore that contains the writable volumes. The storage arrays must be capable of replicating the LUN (logical unit number) that is used for the writable volumes datastore.

Writable Volumes contain user-generated data, so care should be taken to only have one copy active for a particular user at a time. If more than one copy is available, a user could make changes to one copy of their writable copy, and then not find those changes present in the other active copies.

Failover

In this model, each site works independently, with its own set of App Volumes Managers and its own database instance. During an outage, the remaining site can provide access to packages with no intervention required.

• The packages have previously been copied between sites using non-attachable datastores that are members of both sites’ storage groups.
• The entitlements to the packages are replicated from the source App Volumes instance to the target instances.

In use cases where Writable Volumes are being used, there are a few additional steps:

• Attach and mount the storage array replicated datastore that contains the Writable Volumes, against the vSphere hosts in the failover site.
• Perform a rescan of that datastore. If the datastore was the default Writable Volume location, App Volumes Manager automatically picks up the user entitlements after the old assignment information has been cleaned up.
• (Optional) If the datastore is not the default Writable Volume location, perform an Import Writable Volumes operation from the App Volumes Manager at the second site.

All assignments to Writable Volumes are successfully added, but to the new valid location.

Summary and additional resources

Now that you have come to the end of this design chapter on Omnissa App Volumes, you can return to the reference architecture landing page and use the tabs, search, or scroll to select a further chapter in one of the following sections:

• Overview chapters provide an understanding of business drivers, use cases, and service definitions.
• Architecture chapters give design guidance on the Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
• Integration chapters cover the integration of products, components, and services needed to create an environment capable of delivering the services you want to offer your users.
• Configuration chapters reference specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.

Additional resources

For more information about App Volumes, you can explore the following resources:

• App Volumes product page
• App Volumes documentation

• Knowledge Base

Changelog

The following updates were made to this guide:

Date	Description of Changes
2025-02-15	RA has been updated with a new structure, which includes new platform support and capabilities Understand the App Volumes infrastructure components Manual deployment of App Volumes Automated deployment of App Volumes using AWS and Azure Marketplace deployment options Unmanaged App Volumes for physical Windows endpoints Updates to the Packages and Writable Volumes section The Packaging Day 2 operations section moved to App Volumes Configuration
2024-10-10	Updated graphics and diagrams.
2024-06-05	Updated for Omnissa docs, KB, and Tech Zone links.
2023-12-18	Added section on Test and Development Instances
2023-07-19	Added this Summary and Additional Resources section to list changelog, authors, and contributors within each design chapter.
2023-02-03	Added new section on Horizon Published Apps on Demand.
2022-07-19	Updated Horizon 8 Active-Passive Service Using Stretched VMware vSAN Cluster to remove restriction on using App Volumes in a stretched vSAN cluster.
2022-05-25	Rewritten to add details on new multi-instance management capability.
2022-01-24	Clarified details about precedence with Packages and Writable Volumes.
2021-05-21	Added link to guide on database best practices.
2021-05-06	Added guidance on App Volumes 4.x packages.
2020-07-01	Updated App Volumes version 2.x to App Volumes 4.

Author and contributors

This chapter was written by:

• Graeme Gordon, Senior Staff Architect, Omnissa
• Josh Spencer, Senior Product Line Manager, Omnissa.
• Rick Terlep, Staff Technical Marketing Architect, Omnissa.
• Sujay Gopalan, Sr. Technical Marketing Architect, Omnissa.

Feedback 

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.