App Volumes architecture

This chapter is one of a series that makes 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 provides 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 technical 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 App Volumes for physical Windows endpoints 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, RDSH, or physical machine. 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 version 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	The 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 [VHD] In-Guest Services - If the storage is configured as the machine manager, the instructions for attach/detach are sent to the App Volumes Agent to directly fetch the disk from storage for mount/unmount operation within the target endpoint vCenter - Virtual desktop environments using VMware vSphere capacity can opt use vCenter as the machine manager, for App Volumes Manager to provide instructions
	Storage	App Volumes Packages and Writable Volumes can be stored on storage locations supporting: SMB version 3 based storage to store VHD format disks and MSI formatted applications VMFS datastores to store VMDK disks
	Storage group	Groups of storage locations 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 machine manager types section to understand the machine manager interaction with the App Volumes Manager server.

Figure 4: App Volumes using [VHD] In-Guest Services as the machine manager

Figure 5: App Volumes using vCenter 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, such as 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.

Machine manager types

When you first initialize an App Volumes instance you configure one of three types of machine managers during the initial setup and configuration of the App Volumes Manager server. You can add multiple machine managers of the same type to an App Volumes instance. The type of machine manager selected determines the disk format of App Volumes applications: VHD or VMDK.

The type of machine manager cannot be changed without reinstalling the App Volumes instance.

Machine manager types:

• [VHD] In-Guest Services
  • Uses storage as the machine manager and storage locations for the applications.
  • The instructions for application attach and detach are sent to the App Volumes Agent to directly fetch the disk from storage for mount and unmount operations within the target endpoint.
  • Application packages are stored in VHD (and optionally MSI) file format.
  • Select [VHD] In-Guest Services as the machine manager.
  • Auto populated for Azure Marketplace deployments supporting Azure Virtual Desktops.
• VMware vCenter Server
  • Uses vCenter as the machine manager to support a VMware vSphere virtual desktop environment that will use vSphere datastores as storage locations.
  • vCenter coordinates reconfiguration of virtual machines running the App Volumes Agent to attach and detach virtual disks.
  • Application packages are stored in VMDK virtual disks.
  • Select vCenter as the machine manager.
• VMware ESXi host
  • Similar to the use of vCenter but should only be used for non-production or PoC virtual desktop environment.
  • Select ESXi as the machine manager.

Recommendation

There are technical benefits to using VHD In-Guest Services, and the recommendation is that new installations of App Volumes instances should use this as the default. Advantages include:

• VHD packaged applications are more portable and can be used with any hypervisor platform.
• Apps on Demand are more performant with VHDs on SMB and are more robust than using vCenter automation since VM reconfigurations are not necessary.
• App Volumes tools can be used to edit VHD packaged applications,
• VHD files can be scanned on the SMB shares.

Considerations for VMware vCenter environments

The use of vCenter as a machine manager is still supported for virtual desktop environments using VMware vSphere capacity AND which want to leverage vSphere datastores as storage locations for App Volumes applications.

vSphere-based deployments can opt to use [VHD] In-Guest Services as the machine manager type using SMB file shares as storage locations, and applications in VHD format. This provides a hypervisor agnostic instance, with applications that are portable and usable on any hypervisor platform.

Cloud Hosted App Volumes

The selection of a machine manager is not applicable and does not apply to Cloud Hosted App Volumes from Horizon Cloud, 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 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 option is only applicable to VDI deployments using VMware vSphere as capacity, and where you have chosen not to use [VHD] In-Guest Services and SMB shares.

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 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 vCenter to use the ESXi host currently associated with the target virtual machine and to attach the App Volumes Package and/or the Writable Volume VMDK disk from storage.
3. The vSphere host validates having a line of sight to the App Volumes storage
4. Then, a VMDK disk mount operation is initiated, attaching the App Volumes Package VMDK to the target virtual machine.
5. Within the Guest OS, the App Volumes Agent sees the mounted VMDK, virtualizes the application within the guest OS presenting the application as an icon for launch. The application is also registered within the OS.

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.

Storage

App Volumes supports three packaging formats: VHD, VMDK, and MSI. With these three industry-standard formats, App Volumes can store its application packages on storage platforms that support VHD and VMDK storage file systems. The type of storage supported depends on the machine manager type selected.

Table 3: Storage considerations for machine manager selection

Machine manager	Storage considerations
[VHD] In-Guest Services	When [VHD] In-Guest Services is selected as the machine manager, files shares are used as storage locations. Using SMB version 3, App Volumes packages are stored in the VHD or MSI format. This applies to 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.
vCenter	If the virtual desktop infrastructure is on a vSphere platform, and you select to use vCenter as the machine manager, then vSphere datastores are supported for storing App Volumes packages and writable volumes in VMDK format.

You can convert existing application packages to a different supported format, as covered in Package conversion between storage types.

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.

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 suited 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 App Volumes for physical Windows 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 Volumes 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 deployment model in the directory services design considerations section.

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 deployment model 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 Managers and SQL servers.
• 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.
• 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 forensics best practice. It is never a good idea to use a blanket or general-purpose AD user account for multiple purposes within AD.

If using [VHD] In-Guest Services as the machine manager:

• When the App Volumes Agent delivers VHD/MSI formatted packages to physical or virtual Windows desktops, it provides the ability to swap versions of an application without requiring a reboot. This does an in-guest unmount of the old package and a mount of the new version, either using a timed interval or forcing app closure.
• This gives additional control to change the version of application package being used to address corrupt or security compromised versions.

If using vCenter as the machine 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 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 instructions, see the reference configuration in the Configuring Avi Load Balancer for Horizon section of the Solution Guide in the Avi Load Balancer product documentation on TechDocs.

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

Horizon Cloud 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 scaling and availability section.

Automated deployment of App Volumes to Cloud platforms

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-premises 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 VHD and VMDK formats to support the underlying hypervisor and storage on which the on-premises 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 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 Workspace ONE 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 later 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.

This guide covers the following types of App Volumes implementations with sections for each:

• 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 managed App Volumes service 
• 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 following App Volumes deployment options.

• Prerequisites for Deploying App Volumes to support an On-Premises virtual desktop environment
• Prerequisites for Deploying App Volumes Manager through Azure Marketplace
• Prerequisites for Deploying App Volumes for Amazon AppStream 2.0
• Prerequisites For Integrating App Volumes with Horizon Cloud

Manual deployment of App Volumes in a Horizon 8 environment

A key concept in 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 for each pod in each site. [VHD] In-Guest Services was selected as the machine manager type during initial configuration.
Justification	Standardizing on the pod and block approach simplifies the architecture and streamlines administration when integrating with Horizon. The use of [VHD] In-Guest Services as the machine manager uses SMB files shares with application packages in VHD format. This provides better performance flexibility, and portability across any hypervisor platform.

In a production Horizon environment, it is important to adhere to the following best practices for sizing and scaling best practices, as documented in the Horizon Overview and Deployment Planning 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 requires a shared SQL Server.
• An App Volumes instance is bounded by the SQL database.
• The default recommendation is to use [VHD] In-Guest Services as the machine manager type. Review the guidance given in machine manager types.
• 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).
• Use storage groups to distribute load and IOPS across multiple storage locations.
• Storage groups may still be applicable to VMware vSAN storage for replicating packages, especially between instances. See multi-instance and multi-site design for more information.
• Any kernel mode applications should reside in the base image and not in a package.

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 for 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 7: 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. All the App Volumes Manager servers in the instance point to the availability group listener for the database.
Justification	An Always On availability group can provide automatic failover from one SQL server to another.

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 administrator’s 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.

When using vCenter as the machine manager and using VMware vSphere datastores, 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 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 storage locations that are used to serve application 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.

Two automation options for package storage groups are available:

• Automatic replication – Any package placed on any storage location in the storage group is replicated across all storage locations in the group.
• Automatic import – After replication, the package is imported into App Volumes Manager and is available for assignment from all storage locations 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 storage locations 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 storage locations and spreading user access across them.

Packages can be automatically replicated to multiple storage locations in a storage group. This replication creates multiple copies of packages. Access is spread across the storage locations, 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.

Writable Volumes and storage groups

Writable Volume storage groups are used to distribute volumes across storage locations 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 storage location.

Implementation strategy for storage groups

Table 8: Implementation strategy for storage groups

Decision	A storage group was configured for each App Volumes instance to replicate packages between multiple storage locations.
Justification	This allows the packages to be automatically replicated between multiple storage locations within the App Volumes instance to provide local scaling, performance, and resilience.

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 virtual machines. Availability features such as hypervisor high availability for VMs can complement App Volumes deployments and should be considered for 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 a hypervisor platform, underlying host, cluster, network, and storage configurations should adhere to hypervisor vendors best practices with regard to availability.

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 9: 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 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 Domains 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 13: Enabling non-domain-joined entities

vSphere considerations

When using VMware vSphere as the hypervisor platform there are a few specific considerations.

Multiple vCenter server considerations

If you are using vCenter as the machine manager, you can add multiple vCenter Servers as 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.

ESXi hosts

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.

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

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. There is a detailed list of the Configuration Scenarios for Azure Marketplace Deployment of App Volumes.

Figure 14: 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 by App Volumes version 2410 or later.
  • 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 Azure Resources Created After App Volumes Manager Deployment on Azure.

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

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

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. See About App Volumes for Amazon AppStream 2.0 for details on the Preparing for App Volumes for Amazon AppStream 2.0 and the detailed deployment Workflow of App Volumes for Amazon AppStream 2.0.

Figure 15: 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 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. It is 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 are 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.

Amazon AppStream 2.0, network requirements are documented under Resources used in App Volumes Deployment on Amazon AppStream 2.0. Review the Elastic IP address and security group requirements.

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.

Cloud-hosted App Volumes

Omnissa Horizon Cloud delivers virtualized Windows desktops and apps to target endpoint devices. As the Horizon Cloud 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 hosted VDI and RDSH pools. Read about Horizon Cloud.

App Volumes with Horizon Cloud

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. 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 Windows virtual machines and Azure file objects.

Figure 16: App Volumes service in Horizon Cloud

• 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 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. See Manually Replicate App Volumes Application Packages Between Horizon Edge Deployments for the prerequisites and the procedure for manual replication.

Multi-site

As described in the Horizon Cloud 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.

Horizon Edge deployments using cloud-native providers support App Volumes functionality. However, Horizon 8 pods do not use the App Volume functionality provided by Horizon Cloud.  By default, applications are stored in the primary provider of Horizon Edge in storage. The Horizon Cloud 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 reference architecture provides details on the delivery of App Volumes Application Packages to virtual endpoints and the methods of entitlement.

For more information, see Integrating App Volumes with Horizon Cloud.

Database design considerations

Horizon Cloud 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

Horizon Cloud separates user identity from machine identity. This distinction enables you to select various identity solutions for use with Horizon Cloud 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 architecture documentation.

Table 10: Horizon Cloud 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. 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. For a comprehensive list of port requirements, refer to Ports and Protocols Required by Horizon Edge.

Storage design considerations

App Volumes packages are stored in the VHD format and delivered from Microsoft Azure file shares which are documented in Prerequisites for Using App Volumes with Horizon Cloud on Edge deployments.

App Volumes for physical Windows endpoints

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

App Volumes Agent version 2412 and later can now be installed on physical Windows endpoints without requiring 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.

With the release of version 2509, the App Volumes Manager supports managing physical Windows endpoints, enabling application lifecycle management.

Figure 17: Delivery of App Volumes packages to managed Windows endpoints

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 on a physical Windows endpoint, the target 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 18: 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 19: 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 an 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 20: 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 21: 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 later 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, Workspace ONE 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 formats

App Volumes supports three package formats. The App Volumes package capture process supports VMDK, VHD, and MSI output formats for specific platform delivery.

Package format	Detail
VHD	The default package format used when delivering App Volumes applications to virtual desktop environments that use [VHD] In-Guest Services as the machine manager type.
VMDK	Used when delivering App Volumes applications to VMware vSphere-based environments that elected to use vSphere datastores and vCenter as the machine manager type.
MSI	Used when delivering App Volumes applications to physical target endpoints. The App Volumes MSI package is distributed by enterprise software delivery products like Omnissa Workspace ONE UEM or third-party solutions like SCCM or Intune.

Package capture process

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.

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

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 VHD, VMDK, or MSI formats.
   1. If using App Volumes Managers with [VHD] In-Guest Services as machine managers, package the applications into VHD format
   2. If using App Volumes Managers with vCenter as machine managers, package the applications into VMDK format
3. Copy the output application file to the virtual desktop or physical infrastructure storage location that will consume the delivery of the App Volumes application.
   1. If using App Volumes Managers with [VHD] In-Guest Services as machine managers, copy the application file to the SMB file share registered with the App Volumes Managers.
   2. If using App Volumes Managers with vCenter as machine managers, upload the application file to the vSphere-supported datastore 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 VHD, VMDK, and MSI formats.  App Volumes tools can convert App Volumes package VHD, VMDK, 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 conversion between storage types

App Volumes tools have the capability to convert existing packages between formats, reducing the effort of packaging and capturing directly to multiple formats or converting easily from VMDK, VHD, or MSI formats.

Conversion process	Overview
Manual	Can convert from VHD, VMDK, or MSI formats. An existing vmdk package must be converted to monolithic sparse .vmdk file before converting. See Windows Command-Line Arguments for the App Volumes Application Capture Command-Line Program, for more information.
Automated	Can be used to convert packages from VMDK to VHD format. Can convert one or multiple VMDK packages that are either located natively on a VMFS datastore, or in monolithic sparse .vmdk files. For more information see, Automate VMDK to VHD Conversion for App Volumes Packages.

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.

There are delivery models for attaching application packages:

• Classic
  • 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).
  • Useful for applications that are always used by the users.
• On-demand
  • App Volumes attaches a package at a user-initiated time, when they launch the application.
  • On-demand delivery avoids attachments at user login, so speeds up the login process.
  • Packages are only attached if a user uses the application, minimizing resources consumed.
  • From App Volumes version 2603, on-demand is the default package capture mode.

With on-demand attachments, the App Volumes Agent performs a call to the App Volumes Manager, communicating the 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 Understanding Package Delivery Modes in App Volumes to learn more about package delivery models.

Figure 23: App Volumes Agent and Manager communication

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 an App Volumes Application with an App Link.

Horizon Published Apps on Demand

App Volumes 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 Horizon integration 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 24: Published Apps on Demand components

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

1. Create an automated RDSH server farm in Horizon.
   1. vSphere - Create an Automated Instant-Clone Farm
   2. Nutanix - Creating an Automated RDSH 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 25: Published 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 machine manager (hypervisor management) 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 11: 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-instance and 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. Application packages and writable volumes can be replicated between instances, as covered in Replication between instances.

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

Figure 26: 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.
• Machine managers – Each App Volumes Manager instance only has machine managers registered that are in the same site.
• Storage – Each App Volumes Manager instance has its own set of storage locations, local to the machines it is attaching packages to.

Table 12: Strategy for deploying App Volumes in multiple sites

Decision	App Volumes was set up in the second site used for Horizon 8. A separate database and App Volumes instance deployment option was used. Application packages were replicated from the instance in site A to the instance in site B.
Justification	This strategy provides App Volumes capabilities in the second site. The separate database 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.

Multi-instance using [VHD] In-Guest Services as the machine manager

When using [VHD] In-Guest Services as the machine manager, each App Volumes instance has its own set of storage locations. These are used for application packages and writable volumes, which are stored in VHD format.

Figure 27: App Volumes multi-instance model using [VHD] In-Guest Services as the machine manager

Multi-instance using vCenter as the machine manager

When using vCenter as the machine manager, each App Volumes instance has its own set of vSphere datastores. These are used as the storage locations for application packages and writable volumes, which are stored in VMDK disk format.

Figure 28: App Volumes multi-instance model using vCenter as the machine manager

Multi-instance management

App Volumes instances can be joined together to manage them from a single source instance. Used in combination with replication of the application 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 13: Multi-instance components

Component	Description
App Volumes Manager instance	An App Volumes install that is 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.
Replication	An App Volumes feature which enables the copying of applications packages between storage locations.
Synchronization	An App Volumes feature which ensures information about the replicated applications packages, markers, and entitlements remains 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 29: 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.

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 30: 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.

Replication between instances

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

Storage groups can be used to automatically replicate packages from one App Volumes instance to another.

• Use a shared storage location that is accessible to all the App Volumes instances.
• Use overlapping storage groups, one from each App Volumes instance.
• The shared storage location is configured as not attachable, so that it is ignored by App Volumes Manager while mounting application packages, and it is used solely for replication of packages.
  • This means you can use shared storage on slow or inexpensive storage for as it only needs to act as an intermediary for the replication process.
• Best practice is to designate one App Volumes instance as the one where you create and update packages to avoid update conflicts. Align this instance to the source instance defined for multi-instance management.
• In the target instances you can mark the shared storage as read-only to protect against it accidentally being used on those target instances to update packages.

Note: A not attachable storage location can also be used as a staging area for package creation before deploying to production storage groups.

Package replication with [VHD] In-Guest Services as the machine manager

When using [VHD] In-Guest Services as the machine manager, SMB file shares are used as the storage locations for application packages and writable volumes, which are stored in VHD format.

Use a shared file share that is accessible by the App Volumes Managers in each site and combine it with overlapping storage groups, one from each App Volumes instance. Packages will be replicated from one instance to the shared file share, and then to other instances and locations.

Figure 31: Replicating VHD packages between instances

Writable Volumes replication when using [VHD] In-Guest Services as the machine manager

With the [VHD] In-Guest Services as the machine manager, Writeable Volumes are stored on SMB files shares as VHD files. These can be replicated between App Volumes instances using file replication of the storage location that contains the writable volumes.

Writable Volumes contain user-generated data, so care should be taken to only have one active copy 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.

Package replication with vCenter as the machine manager

When using vCenter as the machine manager, vSphere datastores are used as the storage locations for application packages and writable volumes, which are stored in VMDK disk format.

Use a shared datastore that is accessible to the vSphere hosts in each site and combine it with overlapping storage groups, one from each App Volumes instance. Packages will be replicated from one instance to the shared datastore, and then to other instances and locations.

.

Figure 32: Replicating VMDK packages between instances with a shared vSphere datastore

Writable Volumes replication when using vSphere datastores

Writeable Volumes stored on vSphere datastores 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 active copy 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.

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

Failover

In a multi-instance App Volumes deployment, with packages replication, 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 replicated between sites.
• The entitlements to the packages are replicated from the source App Volumes instance to the target instances using multi-instance management.

Failover of Writable Volumes with [VHD] In-Guest Services as the machine manager

If you are using [VHD] In-Guest Services as the machine manager with SMB file shares, and using Writable Volumes, some manual intervention is required to fail them over.

1. In the failover site, add the file share (where you replicated the writable volumes to).
2. Perform an Import Writable Volumes operation.

Writable Volumes contain user-generated data, so care should be taken to only have one active copy 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 of Writable Volumes with vCenter as the machine manager

If you are using vCenter as the machine manager and vSphere datastores, you will also need to attach the replicated datastore to the vSphere hosts in the failover site.

1. Attach and mount the storage array replicated datastore that contains the copy of the Writable Volumes, against the vSphere hosts in the failover site.
2. Perform a rescan of that storage location.
3. Perform an Import Writable Volumes operation.

If the storage location was the default Writable Volume location, App Volumes Manager automatically picks up the user entitlements after the old assignment information has been cleaned up.

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, 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, 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 technical product page
• App Volumes documentation
• Knowledge Base

Changelog

The following updates were made to this guide:

Date	Description of changes
2026-07-29	Extensively rewritten to show more detail on the use of VHD as a machine manager and favor this as the default recommendation. Various sections rewritten and updated for clarity.
2026-06-17	Update to the Load Balancing section
2026-05-27	Fixed grammar, product renames. Fixed broken links and updated for 2603 docs
2026-04-13	Update to the Machine Manager (vCenter) workflow
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 guide was written by:

• Graeme Gordon, Senior Staff Architect, Omnissa
• Sujay Gopalan, Sr. Technical Marketing Architect, Omnissa.
• Josh Spencer, Senior Product Line Manager, Omnissa.
• Rick Terlep, Staff 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.