Using App Volumes applications functionality, you can manage the entire life cycle of applications, including packaging, updating, and retiring an application. You can also customize application assignments to deliver specific versions of an application to end users.

Important: As described in Tour of the Cloud-Based Horizon Universal Console for Administrative Tasks in Horizon Cloud, the cloud-based console is dynamic and reflects the workflows and settings that are appropriate for the up-to-the-moment situation in your Horizon Cloud tenant environment. Access to features varies depending on factors such as the tenant's regional cloud plane, whether your cloud-connected pods are running the latest software level, and whether features are based on specific licensing. The console dynamically reflects the elements related to such features only when your license or tenant account configuration includes use of such features. When you are expecting to see a feature in the console and do not see it, you have to contact your VMware account representative to verify whether your license and tenant account configuration entitles its usage.

Overview of VMware App Volumes Functionality in Horizon Cloud

The following table provides an overview of VMware App Volumes functionality in Horizon Cloud.

Functional Area Description
Deployment
  • Zero-touch deployment. Auto-provisioning of App Volumes infrastructure components, such as App Volumes Managers, App Volumes databases, and storage.
  • Leverages Microsoft Azure PostgreSQL managed service for database needs. No additional database management required.
  • Automatic provisioning of Microsoft Azure File Shares during pod setup to store and deliver apps.
Management Console
  • App Volumes console is seamlessly integrated into the Horizon Universal Console. Manage desktops and apps in the same console.
  • App Volumes Agent installation experience seamlessly integrated into the Horizon Cloud image creation workflows.
App Volumes 4 agent

Unified performance-optimized agent used both for on-premises and Microsoft Azure deployments.
Packaging
  • Supports VHD based packages that are delivered using Microsoft Azure fileshares.
  • Application package creation performed natively within Horizon Cloud. No command-line tools necessary.
  • Customers can import MSIX app attach VHDs and deliver this new package format using App Volumes.
Application Lifecycle Management

Supports Simplified Application Management (SAM) capability that is already a part of App Volumes 4 on-prem. Administrators can now manage the entire life cycle of the application, including packaging, updating, and retiring.
Application Assignment
  • Administrators can customize their application assignments to deliver specific versions of an application to end users.
  • Supports multi-pod application delivery.
Hybrid Cloud Support

On-prem App Volumes customers can now import their application packages from their on-prem deployments into Horizon Cloud on Microsoft Azure. Reuse on-prem packages. No need to repackage for Microsoft Azure.

Overview of the App Volumes Application Process

Making App Volumes applications available to users is a two-step process:

Requirements and Prerequisites for Using App Volumes with your Horizon Cloud on Microsoft Azure Deployments

Important: To prevent rendering your App Volumes applications inaccessible and thus invalidating support for App Volumes features in your Horizon Cloud on Microsoft Azure deployment, the storage account key for the App Volumes-related storage account must not be touched in a way that causes that key to expire, change, or rotate.

If the storage account key is rotated - either manually or through an Azure Policy - the storage account and the file shares on which App Volumes relies will become inaccessible. If that occurs, App Volumes cannot deliver the applications to the end users, because the storage key stored within the deployment is invalid.

Although the Horizon Cloud on Microsoft Azure deployment resides in your provided Azure subscription, the deployment's App Volumes-related storage account is a VMware-managed component, same as the pod manager machines, Unified Access Gateway machines, and other service-deployed resources that are provisioned into your Azure subscription. Every Horizon Cloud on Microsoft Azure deployment includes the deployment of an App Volumes-related storage account.

When the service deploys the pod manager machines, the service provisions this App Volumes-related storage account into your Azure subscription. This storage account's purpose is to provide the file shares in which the App Volumes application files will be provisioned.

The data in this storage account is automatically encrypted by Azure Storage using Microsoft-managed keys. If your or your organization makes this storage account key expire, change, or rotate, the storage key will be rendered invalid. If that occurs, App Volumes cannot access the file shares and then cannot deliver the applications to the end users.

Before you can add App Volumes applications into your inventory, confirm that your environment meets the following prerequisites.

Pod-related prerequisites
  • To use the App Volumes features with single-session types of Microsoft Windows operating systems, the Horizon Cloud Service on Microsoft Azure deployment must be running manifest 2298.x or later.
  • To use the App Volumes features with Microsoft Windows 10 or 11 Enterprise multi-session operating system, the deployment must be running manifest 2747.x or later.
  • The deployment must have a gateway configuration (Unified Access Gateway instances), and you have completed the Unified Access Gateway’s FQDN-mapping steps, as is required for Horizon Cloud on Microsoft Azure deployments that are configured with Unified Access Gateway instances.
  • Check each pod's details page and confirm that the page indicates each pod has its mounted file shares. The console allows you to navigate to the pod details page after you have completed the Active Directory domain registration workflow. These file shares are generated by the service, and use of the App Volumes features relies on their existence.

    Display a pod's details page by navigating to the Capacity page (Settings > Capacity) and clicking the pod. Then confirm:

    • The Fileshares field under Properties has a value of 2 and when you point to the number both fileshares are listed.
    • The Gateway settings at the bottom of the page are filled in, indicating that Unified Access Gateway is configured.
Configuration requirements
  • You have completed the Active Directory domain registration workflow as described in Getting Started Using Your Horizon Cloud Environment.
  • If you have set your Active Directory domain's Domain Controller Policy Domain controller: LDAP server signing requirements to Require Signing after registering the domain using the Horizon Universal Console, you must do the following:
    1. On the Setings > Active Directory page, click the edit (pencil) icon next to Domain Bind.
    2. Enter the primary bind account password in the Bind Password text box. Do not make any other changes.
    3. Click Domain Bind.
  • In addition to meeting the Horizon Cloud DNS, ports, and protocol requirements, you must also open port 445 for TCP protocol traffic. Port 445 is the standard SMB port for accessing an SMB file share on Microsoft Windows. The AppStacks are stored in an SMB file share located in the pod’s resource group in your Microsoft Azure subscription.
Image requirements
To add an App Volumes application by creating an application package using the Create workflow in the console, your inventory in the console must have a published image that meets the following criteria.
  • Has a client type of Microsoft Windows 10 or Windows 11 operating system. This client type is sometimes referred to as a VDI type of operating system. The in-cloud capturing workflow is available for use only with VDI types of operating systems. The in-cloud capturing workflow is not available for multi-session or RDS types of operating systems.
  • Has the App Volumes Agent installed.

Best Practices for Using a Microsoft Windows 10 or 11 Enterprise Multi-Session Image with App Volumes Applications in Horizon Cloud Pods in Microsoft Azure

The following practices tend to provide a better user and administrator experience. Also see Setting up a Microsoft Windows 10 or 11 Enterprise Multi-Session Image with App Volumes Applications in Horizon Cloud Pods in Microsoft Azure.

  • Install hardware printers, with printer drivers, in the base image. See the Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods guide for related known-issue information, specifically in the known issues topic.
  • As described in the Microsoft documentation FAQ, Microsoft Windows 10 Enterprise multi-session is a Remote Desktop Session Host (RDSH) type of VM that allows multiple concurrent interactive sessions, which previously only Microsoft Windows Server operating systems provided. Because Microsoft Windows 10 Enterprise multi-session is an RDSH type of operating system, the Horizon Cloud RDSH-applicable workflows apply to it instead of the VDI-related workflows. As a result, to provide session desktops to end users based on these multi-session systems, you create a farm as described in Create a Farm. To support using App Volumes applications in the session desktops based on the farm, all of the following farm settings are required. These settings provide for the operating system disks of the farm VMs to be refreshed to their initial state on a regular basis, and that regular refresh is required to support the use of App Volumes applications in such VMs.
    Required Rolling Maintenance Settings
    • Maintenance Type: Session
    • Number of sessions: Equal to the number of sessions per VM
    • VM Action: Rebuild
    • Concurrent Quiescing VMs: 40% of farm size
    Required Timeout Handling Settings
    • Log Off Disconnected Sessions: Timeout after 90 minutes
    • Session Timeout Interval: 90 minutes
  • You must deactivate auto-update services for each application you intend to provision as an app package on Microsoft Windows 10 multi-session. Auto-update behavior is problematic in this type of Microsoft Windows 10 multi-session environment.
    • If the application has an auto-update service, deactivate the service, such as with Windows Services Manager, during the application-provisioning process.
    • If you cannot or do not deactivate the auto-update service during the application provisioning process, after you encounter an issue, such as users receive an incomplete version of an unassigned application, modify the base image by configuring the registry. This configuration ensures that the service of interest is not started when the application package is deployed on the user VM. Specifically, configure the registry by adding the application service name to the svservice registry configuration DisableAppServicesList. See the Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods guide for related known-issue information, specifically in the known issues topic.
  • Inform users that when they install applications or create files that they do not intend to share among all user sessions on the same VM, they can place the file in their own profile location.