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.
Overview of VMware App Volumes Functionality in Horizon Cloud
The following table provides an overview of VMware App Volumes functionality in Horizon Cloud.
|App Volumes 4 agent||
Unified performance-optimized agent used both for on-premises and Microsoft Azure deployments.
|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.
|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:
- Add an App Volumes application in the Horizon Universal Console. There are two ways of doing this:
- Add an App Volumes application by creating and importing a new application package.
If an application package has not yet been created, you can create it with the Create option, which uses App Volumes to create the application package and automatically import it. See Add an App Volumes Application to Your Horizon Cloud Tenant's Inventory Using the Create Workflow.
- Add an App Volumes application by importing an existing application package.
If you have an application package that was previously created with App Volumes, you can import it with the Import option. This means you can reuse application package from on-premises deployments without having to repackage the applications. See Horizon Cloud - Add an App Volumes Application by Importing an Existing App Package.
- Add an App Volumes application by creating and importing a new application package.
- Create an App Volumes assignment to assign the App Volumes application to users. See Horizon Cloud - Create an App Volumes Assignment.
Requirements and Prerequisites for Using App Volumes with your Horizon Cloud on Microsoft Azure Deployments
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 ( ) 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:
- On the Domain Bind. page, click the edit (pencil) icon next to
- Enter the primary bind account password in the Bind Password text box. Do not make any other changes.
- 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.