App Volumes Applications for Horizon Cloud on Microsoft Azure - Overview and Prerequisites

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.

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:

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

• Create an App Volumes assignment to assign the App Volumes application to users. See Horizon Cloud - Create an App Volumes Assignment.

Prerequisites for Adding App Volumes Applications to Your Tenant's Inventory

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

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 level of the pod's software, 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.

• New Customers:
  • Starting on July 9, 2020, all new customers that purchase the Horizon Universal License subscription will have their tenant accounts enabled by default to use App Volumes for Horizon Cloud on Microsoft Azure pods.
• Existing Customers:
  • Customers with existing tenant accounts created after March 16, 2020 and before July 9, 2020 can use App Volumes for Horizon Cloud on Microsoft Azure pods after the version 3.1 (manifest version 2298.0) upgrade has been made available and those customers have upgraded all their pods to that version. To request App Volumes capability after successfully upgrading all pods, contact VMware Support as described in https://kb.vmware.com/s/article/2006985.
  • Customers with existing tenant accounts created on or before March 16, 2020 are not able to have App Volumes enabled for their Horizon Cloud on Microsoft Azure pods at this time. Those accounts must first be migrated to one of the regional Horizon Cloud control plane instances in Microsoft Azure. The VMware Horizon Service Team will notify such customers by email when this migration is available.

• Pod manifest requirements:
  • To use the App Volumes features with single-session types of Microsoft Windows operating systems, the pod must be of manifest 2298.x or later.
  • To use the App Volumes features with Microsoft Windows 10 Enterprise multi-session operating system, the pod must be of manifest 2747.x or later.
• The pod must be configured with Unified Access Gateway instances, and you have completed the Active Directory domain registration workflow as described in Getting Started Using Your Horizon Cloud Environment.
• If you have set the 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 the Horizon Universal Console, verify that every pod’s details page shows that the pod has its mounted file shares.
• 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.
• You have completed the Unified Access Gateway’s FQDN-mapping steps, as is required for pods in Microsoft Azure that are configured with Unified Access Gateway instances.
• You have confirmed that the following settings are shown on the pod detail page for your pod. You open the page by navigating to the Capacity page (Settings > Capacity) and clicking the pod:
  • 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.
• 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 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 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 10 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.