Horizon Cloud on Microsoft Azure Architecture
This chapter is one of a series that make up the , a framework that provides guidance on the architecture, design considerations, and deployment of Workspace ONE and Horizon solutions. This chapter provides information about architecting VMware Horizon Cloud on Microsoft Azure.
V is available using a software-as-a-service (SaaS) model. This service comprises multiple software components.
Figure 1: Horizon Cloud Service on Microsoft Azure
Horizon Cloud Service provides a single cloud control plane, run by VMware, that enables the central orchestration and management of remote desktops and applications in your Microsoft Azure capacity, in the form of one or multiple subscriptions in .
VMware is responsible for hosting the Horizon Cloud Service control plane and providing feature updates and enhancements for a software-as-a-service experience. The Horizon Cloud Service is an application service that runs in multiple Microsoft Azure regions.
The cloud control plane also hosts a common management user interface called the Horizon Cloud Administration Console, or Administration Console for short. The Administration Console runs in industry-standard browsers. It provides you with a single location for management tasks involving user assignments, virtual desktops, RDSH-published desktop sessions, and applications. This service is currently hosted in multiple Azure regions. The Administration Console is accessible from anywhere at any time, providing maximum flexibility.
A successful deployment of VMware Horizon Cloud Service on Microsoft Azure depends on good planning and a robust understanding of the platform. This section discusses the design options and details the design decisions that were made to satisfy the design requirements of this reference architecture.
The core elements of Horizon Cloud Service include:
- Horizon Cloud Control Plane
- Horizon Cloud Manager virtual machine, which hosts the Administration Console UI
- VMware Unified Access Gateway
- Horizon Agent
- VMware Horizon Client
- VMware App Volumes
The following figure shows the high-level logical architecture of these core elements. Other components are shown for illustrative purposes.
Figure 2: Horizon Cloud Service on Microsoft Azure Logical Architecture
This figure demonstrates the basic logical architecture of a Horizon Cloud Service pod on your Microsoft Azure capacity.
- Your Microsoft Azure infrastructure as a service (IaaS) provides capacity.
- Your Horizon Cloud Service control plane is granted permission to create and manage resources with the use of a service principal in Microsoft Azure.
- You provide additional required components, such as Active Directory, and optional components, such as a VMware Workspace ONE Access Connector or RDS license servers.
- The Horizon Cloud Service control plane initiates the deployment of the Horizon Cloud Manager VM, Unified Access Gateway appliances for secure remote access, and other infrastructure components that assist with the configuration and management of the Horizon Cloud Service infrastructure.
- After the Horizon Cloud Service pod is deployed, you can connect the pod to your own corporate AD infrastructure or create a new AD configuration in your Microsoft Azure subscription. You deploy VMs from the Microsoft Azure marketplace, which are sealed into images, and can be used in RDSH server farms.
- With the VDI functionality, you can also create Windows 10 assignments of dedicated and floating desktops.
- You can leverage RDSH Farms to deliver session-based desktops and applications to users.
- You can leverage Farms to deliver session-based desktops based on Windows 10 Multi-Session VM’s.
Horizon Cloud Service on Microsoft Azure includes the following components and features.
Table 1: Components of Horizon Cloud on Microsoft Azure
Table 2: Implementation Strategy for Horizon Cloud Service on Microsoft Azure
A Horizon Cloud on Microsoft Azure deployment was designed and integrated with the Workspace ONE platform, with Unified Access Gateways located in each pod’s management VNet.
This design accommodates an environment capable of scaling to 6,000 concurrent connections or users.
This strategy allowed the design, deployment, and integration to be validated and documented.
App Volumes in Horizon Cloud on Microsoft Azure
The App Volumes Agent is installed in the guest operating system of nonpersistent VMs. The agent communicates with the App Volumes Manager instances to determine package entitlements. Virtual disks containing the programs are attached to the guest operating system in the VM, making applications available to end users.
Figure 3: App Volumes Logical Components
The components and features of App Volumes are described in the following table.
Table 3: App Volumes Components and Concepts
App Volumes Manager
App Volumes Agent
Microsoft Azure Infrastructure
Key Design Considerations
- Provisioning of App Volumes infrastructure components, such as App Volumes Managers, App Volumes databases, and storage are handled automatically at pod deployment.
- Customers can access App Volumes functionality only through the Control Plane.
- App Volumes is deployed as a part of every Horizon Cloud on Microsoft Azure pod.
- App Volumes agent is available as on optional install from the Horizon Agent Installer package. For details, see:
- Any kernel mode applications should reside in the base image and not in a package.
- App Volumes Packages for Horizon Cloud on Microsoft Azure are stored as VHD files.
- Assign as few packages as possible per user or device. See the VMware Knowledge Base article for the recommended number of packages per VM.
Note: This KB article was written for App Volumes 2.x AppStacks. Although most of the content is applicable to App Volumes 4, the maximum number of package attachments tested has increased.
Network Ports for App Volumes
Brokering Methods for Horizon Cloud on Microsoft Azure
A connection broker is a critical function of every hosted desktop environment. It finds, on behalf of the user, the correct type of resource to service the end user’s needs, based on the entitlements that the administrator has allowed for that individual.
An administrator defines the rules that indicate which resources a user is entitled to use and how they can use them. The administrator also defines what authentication method will be used to assure the identity of the user.
After a user logs in to the system, they are presented with a list of resources and capacities that they can use in the current context. For example, an administrator might define that certain applications can be used remotely only if the user is on a trusted network connection. The connection broker would consider that information when deciding what resources to present to the end user.
When an authenticated user selects a resource to use, the connection broker finds a suitable resource to handle that request. The user is remotely connected to that resource for use. The connection broker can also, in some cases, influence the kind of display protocol that will be used to deliver the remote experience to the user, based on variables like locality, network conditions or security, with the intent of providing the best experience for the end user.
Choosing a Brokering Method
There are two separate methods you can broker connections within Horizon Cloud on Microsoft Azure:
- Single-pod brokering – Leveraging the broker that is built into the Horizon Cloud on Microsoft Azure Pod Manager VM.
- Universal Broker – A cloud-based connection broker delivered as a service that can broker resources from multiple pods.
Customers who are new to Horizon Cloud on Microsoft Azure as of July 2020, have a choice of broker. Customers who started prior to July 2020 will receive a notice when they can use the Universal Broker. After you select a broker, it cannot be changed. See for more details on selecting a broker.
If you select single-pod brokering, you can broker assignments only on a pod-by-pod basis—meaning that any user assignments must be created and are only valid for an individual, given pod, even if your customer account has multiple pods deployed and managed by Horizon Cloud Service.
If you choose Universal Broker, you can broker resources across multiple pods. Note that there are some limitations to the features available, client configurations, and the types of resources and you can broker to users across pods with the Universal Broker. These limitations might affect your choice of brokering method. See for details. There are also a number of that are required for different components of your Horizon Cloud on Microsoft Azure implementation.
Table 4: Implementation Strategy for Universal Broker
We are leveraging Universal Broker in the Reference Architecture environment. We are using it in conjunction with VMware Workspace ONE Access, so our users have visibility into all resources and applications assigned to them upon login to a single URL.
Universal Broker allows us to assign users to consume resources in both Horizon Cloud on Microsoft Azure pods from a single URL. It also integrates with VMware Workspace ONE Access so that users have a single URL for all Horizon entitlements and SaaS application entitlements in one UI.
Availability and Scalability
When creating your design, consider that you want an environment that can scale up when necessary and also remain highly available. Design decisions must be made with respect to some Microsoft Azure limitations and some Horizon Cloud limitations.
A Horizon Cloud pod is typically used to describe a deployment of Horizon Cloud in a Microsoft Azure subscription. The primary component of a pod is the Horizon Cloud Manager VM. A Horizon Cloud pod can have several functional components that support the key components of a Horizon Cloud pod. Examples of these components are a jump box, Unified Access Gateway virtual appliances, and the manager VM.
Several Microsoft Azure platform components and services are used in a pod, such as Microsoft Azure Database for PostgreSQL Service, Microsoft Azure load balancers, and Microsoft Azure virtual networks (VNets). A full list of platform requirements can be found in the .
One key design principle is to remove single points of failure in the deployment. The Horizon Cloud pod has a few components to protect against a single point of failure.
- Two Unified Access Gateway virtual appliances are deployed by default along with a Microsoft Azure load balancer configured to route traffic to the primary Unified Access Gateway. Availability is tested by using Http:80/favicon.ico as a health monitoring HTTP GET request to the load balancer.
- You can optionally deploy a secondary pod manager VM with a Microsoft Azure load balancer configured to route traffic to the currently active pod manager VM.
Horizon Cloud on Microsoft Azure leverages cloud-based software components that provide functionality for the Horizon Cloud pod, such as monitoring, image creation, and an administrative interface. To maintain the health and function of the Horizon Cloud pod, you must have line-of-site visibility to several cloud-based services. A full list of all of the DNS addresses that must have line-of-site visibility is documented in
Horizon Cloud on Microsoft Azure operates using Microsoft Azure infrastructure components. Subscriptions are hosted in (data centers) located throughout the world. Outages and service degradations on the Microsoft Azure platform can result in problems with the operations of a Horizon Cloud pod. Furthermore, Microsoft has regular maintenance windows for upgrades to the platform, and although most maintenance activities do not affect the operations of VMs, some might. For more information, see the Microsoft documents and . You can view the current status of Azure regions on the .
The way to expand a Horizon Cloud on Microsoft Azure environment is to deploy additional pods.
Horizon Cloud on Microsoft Azure has certain configuration maximums you must consider when making design decisions:
- Up to 2,000 concurrent active connections are supported per Horizon Cloud pod.
- Up to 2,000 desktop and RDSH server VMs are supported per Horizon Cloud pod.
- Up to 2,000 desktop and RDSH server VMs are supported per Microsoft Azure region or subscription.
To handle larger user environments, you can deploy multiple Horizon Cloud pods, but take care to follow the accepted guidelines for separating the pods from each other. For example, under some circumstances, you might deploy two pods in two different Microsoft Azure regions, or you might be able to deploy two pods in the same subscription in the same region if the IP address space is large enough to handle multiple deployments.
Table 5: Implementation Strategy for Horizon Cloud Pods
Three Horizon Cloud pods were deployed.
This design meets the requirements for scaling to 6,000 concurrent connections or users.
Configuration Maximums for Microsoft Azure Subscriptions
Horizon Cloud on Microsoft Azure leverages to deliver desktops and applications to end users. Each Microsoft Azure region can have different infrastructure capabilities. You can leverage multiple Microsoft Azure regions for your infrastructure needs.
These deployments are a part of your Microsoft Azure subscription or subscriptions. A subscription is a logical separate unit of Microsoft Azure capacity that you are responsible for. You can have multiple Microsoft Azure subscriptions as a part of the organization defined for you in Microsoft Azure.
A Microsoft Azure subscription is an agreement with Microsoft to use one or more Microsoft cloud platforms or services, for which charges accrue based either on a per-user license fee or on cloud-based resource consumption. For more information on Microsoft Azure subscriptions, see .
Some of the limitations for individual Microsoft Azure subscriptions might impact designs for larger Horizon Cloud on Microsoft Azure deployments. For details about Microsoft Azure subscription limitations, see Microsoft Azure has a maximum of that can be allotted for any given Microsoft Azure subscription per region.
If you plan to deploy 2,000 concurrent VDI user sessions in a single deployment of Horizon Cloud on Microsoft Azure, consider the VM configurations you require. If necessary, you can leverage multiple Microsoft Azure subscriptions for a Horizon Cloud on Microsoft Azure deployment.
Note: You might need to request increases in quota allotment for your subscription in any given Microsoft Azure region to accommodate your design.
Table 6: Implementation Strategy Regarding Microsoft Azure Subscriptions
Multiple Microsoft Azure subscriptions were used.
This strategy provides an environment capable of scaling to 6,000 concurrent connections or users, where each session involves a VDI desktop with 2 vCPUs (or cores), making a total requirement of 12,000 vCPUs.
Because the requirement for 12,000 vCPUs exceeds the maximum number of vCPUs allowed per individual subscription, multiple subscriptions must be used.
Other Design Considerations
Several cloud- and SaaS-based components are included in a Horizon Cloud on Microsoft Azure deployment. The operation and design of these services are considered beyond the scope of this reference architecture because it is assumed that no design decisions you make will impact the nature of the services themselves. Microsoft publishes a for individual components and services provided by Microsoft Azure.
Horizon Cloud on Microsoft Azure uses for some components included in the Horizon Cloud pod—specifically for the two Unified Access Gateways that are deployed as a part of any Internet-enabled deployment.
You can manually build and configure Horizon Cloud pods to provide applications and desktops in the event that you have an issue accessing a Microsoft Azure regional data center. Microsoft has suggestions for candidate regions for disaster recovery. For more information, see .
As was mentioned previously, Horizon Cloud on Microsoft Azure has no built-in functionality to handle business continuity or regional availability issues. In addition, the Microsoft Azure services and features regarding availability are not supported by Horizon Cloud on Microsoft Azure.
One method of accessing Horizon desktops and applications is through Workspace ONE Access. This requires integration between the Horizon Cloud Service and Workspace ONE Access using the SAML 2.0 standard to establish mutual trust, which is essential for single sign-on (SSO) functionality.
- When SSO is enabled, users who log in to Workspace ONE Access with Active Directory credentials can launch remote desktops and applications without having to go through a second login procedure when they access a Horizon desktop or application.
- When users are authenticating to Workspace ONE Access and using authentication mechanisms other than AD credentials, True SSO can be used to provide SSO to Horizon resources for the users.
Many user authentication options are available for logging in to Workspace ONE Access or Workspace ONE. Active Directory credentials are only one of these many authentication options. Ordinarily, using anything other than AD credentials would prevent a user from being able to SSO to a Horizon virtual desktop or published application through Horizon Cloud on Microsoft Azure. After selecting the desktop or published application from the catalog, the user would be prompted to authenticate again, this time with AD credentials.
True SSO provides users with SSO to Horizon Cloud on Microsoft Azure desktops and applications regardless of the authentication mechanism used. True SSO uses SAML, where Workspace ONE is the Identity Provider (IdP) and the Horizon Cloud pod is the Service Provider (SP). True SSO generates unique, short-lived certificates to manage the login process. This enhances security because no passwords are transferred within the data center.
Figure 4: True SSO Logical Architecture
True SSO requires a new service—the Enrollment Server—to be installed.
Table 7: Implementation Strategy for SSO Using Authentication Mechanisms Other Than AD Credentials
True SSO was implemented.
This strategy allows for SSO to Horizon Cloud Service on Microsoft Azure desktops and applications through Workspace ONE Access, even when the user does not authenticate with Active Directory credentials.
For True SSO to function, several components must be installed and configured within the environment. This section discusses the design options and details the design decisions that satisfy the requirements.
The Enrollment Server is responsible for receiving certificate-signing requests from the Connection Server and passing them to the Certificate Authority to sign using the relevant certificate template. The Enrollment Server is a lightweight service that can be installed on a dedicated Windows Server 2016 VM, or it can run on the same server as the MS Certificate Authority service.
Scalability for True SSO
A single Enrollment Server can easily handle all the requests from a single pod. The constraining factor is usually the Certificate Authority (CA). A single CA can generate approximately 70 certificates per second (based on a single vCPU). This usually increases to over 100 when multiple vCPUs are assigned to the CA VM.
To ensure availability, a second Enrollment Server should be deployed per pod (n+1). Additionally, ensure that the Certificate Authority service is deployed in a highly available manner, to ensure complete solution redundancy.
Figure 5: True SSO Availability and Redundancy
With two Enrollment Servers, and to achieve high availability, it is recommended to co-host the Enrollment Server service with a Certificate Authority service on the same machine.
Table 8: Implementation Strategy for Enrollment Servers
Two Enrollment Servers were deployed in the same Microsoft Azure region as the Horizon Cloud pod.
These ran on dedicated Windows Server 2016 VMs.
These servers also had the Microsoft Certificate Authority service installed.
Having two servers satisfies the requirements of handling 2,000 sessions and provides high availability.
You can implement optional components to provide additional functionality and integration with other VMware products:
- Workspace ONE Access – Implement and integrate the deployment with Workspace ONE Access so that end users can access all their apps and virtual desktops from a single unified catalog.
- VMware Dynamic Environment Manager – Leverage Dynamic Environment Manager to provide a wide range of capabilities such as personalization of Windows and applications, contextual policies for enhanced user experience, and privilege elevation so that users can install applications without having administrator privileges.
- True SSO Enrollment server – Deploy a True SSO Enrollment Server to integrate with Workspace ONE Access and enable single-sign-on features in your deployment. Users will be automatically logged in to their Windows desktop when they open a desktop from the Workspace ONE user interface.
- Avi Vantage – You can leverage the Avi Vantage network appliance in lieu of the Microsoft load balancers that are deployed as a part of the Horizon Cloud on Microsoft Azure pod. For details, see on the Avi Networks site.
- VMware Workspace ONE Assist - VMware Workspace ONE Assist for VMware Horizon is a real-time remote employee support solution that enables IT and help desk staff to support employees with virtual desktop task and issues remotely. .
Shared Services Prerequisites
The following shared services are required for a successful implementation of Horizon Cloud on Microsoft Azure deployment:
- DNS – DNS is used to provide name resolution for both internal and external computer names. For more information, see .
- Active Directory – There are multiple configurations you can use for an Active Directory deployment. You can choose to host Active Directory completely on-premises, completely in Microsoft Azure, or in a hybrid (on-premises and in Microsoft Azure) deployment of Active Directory for Horizon Cloud on Microsoft Azure. For supported configurations, see .
- RDS licensing – For connections to RDSH servers, each user and device requires a Client Access License assigned to it. RDS licensing infrastructure can be deployed either on-premises or in a Microsoft Azure region based on your organization’s needs. For details, see .
- DHCP – In a Horizon environment, desktops and RDSH servers rely on DHCP to get IP addressing information. Microsoft Azure provides DHCP services as a part of the platform. You do not need to set up a separate DHCP service for Horizon Cloud Service on Microsoft Azure. For information on how DHCP works in Microsoft Azure, see Address Types in .
- Certificate services – The Unified Access Gateway capability in your pod requires SSL/TLS for client connections. To serve Internet-enabled desktops and published applications, the pod deployment wizard requires a PEM-format file. This file provides the SSL/TLS server certificate chain to the pod’s Unified Access Gateway configuration. The single PEM file must contain the entire certificate chain, including the SSL/TLS server certificate, any necessary intermediate CA certificates, the root CA certificate, and the private key.
For additional details about certificate types used in Unified Access Gateway, see . Also, see for details on how certificates impact your Horizon Cloud on Microsoft Azure deployment.
Horizon Cloud on Microsoft Azure is a simple solution for providing desktops and streamed applications to your end users. The deployment is straightforward: You prepare and provide information to VMware on a Microsoft Azure subscription, and the Horizon Service deploys a Horizon Cloud on Microsoft Azure pod into the subscription on your behalf.
However, some companies need more flexibility in pod deployment options. For example, with the custom deployment options available in Horizon Cloud on Microsoft Azure, you can configure separate development, testing, and production environments, yet allow your application development team to access them all from the same Horizon Cloud on Microsoft Azure pod.
For a basic Horizon Cloud on Microsoft Azure deployment, all components of the pod are deployed into the same Microsoft Azure VNet in the same subscription.
Figure 6: Basic Horizon Cloud on Microsoft Azure Deployment – Same VNet and Subscription for All Components
Starting with Horizon Cloud on Microsoft Azure 1.5, two deployment options have been added to facilitate these architectures.
- Use a Different Subscription for External Gateway
- Use a Different Virtual Network
When you choose either of these new deployment options, the Unified Access Gateway configuration components are deployed into a separate VNet or Azure subscription from the rest of the Horizon Cloud on Microsoft Azure pod. These options require you to follow an amended set of prerequisites to make Horizon Cloud on Microsoft Azure function properly.
Important: For both of these deployment options, if you plan to create a network peering to provide visibility between your VNets, be sure to create the required subnets before running the deployment wizard. See .
Table 9: Implementation Strategy for Horizon Cloud on Microsoft Azure Networks
Default network configuration was used for all deployments. That is, we used the same subscription and VNet for all components.
This strategy provided the simplest method of deployment to support our hub and spoke deployment. For our test environment, there was no need to separate the environment due to security concerns or areas of responsibility.
Additional Network Topologies for Gateways and User Workloads
This section discusses optional use of different subnets or subscriptions for user workload and using a different subscription for an external gateway.
You can choose to deploy your Unified Access Gateway appliances into a separate subscription by toggling this option in the Horizon Cloud on Microsoft Azure deployment wizard.
Figure 7: Selecting a Separate Subscription for Unified Access Gateway Appliances
This option allows you to deploy the Unified Access Gateway (UAG) components into a separate subscription, as depicted in the following figure.
Figure 8: Additional Azure Subscription Used for the External Gateway
With this configuration, you must ensure that the two subscriptions are line-of-sight visible to each other through either of the following options:
- Network peering across subscriptions, as described in the Microsoft document
- Using a site-to-site virtual gateway, as described in the Microsoft document
Deploying Unified Access Gateways into a Different VNet
You can choose to deploy your Unified Access Gateway appliances into a separate virtual network by toggling this option in the Horizon Cloud on Microsoft Azure deployment wizard.
Figure 9: Selecting a Separate Virtual Network for Unified Access Gateway Appliances
This option allows you to deploy the Unified Access Gateway components into a separate VNet, as depicted in the following figure.
Figure 10: Unified Access Gateway in a Separate VNet – Same Subscription
With this configuration, you must ensure that the two VNets are line-of-sight visible to each other through either of the following options:
- Virtual network peering, as described in the Microsoft document
- Using a VNet-to-VNet connection, as described in the Microsoft document
Using the Options for a Separate Subscription or VNet in Other Configurations
The use of these two deployment options opens the door to a number of deployment configurations that were not available until now. The diagrams that follow describe examples of typical configurations that companies have used for more complex deployments. For example, the deployment configuration can make external traffic flow through a separate VNet, where network virtual appliances are deployed to provide a DMZ. This DMZ could manage Internet-based traffic prior to allowing access to the Unified Access Gateway appliances. This strategy follows the example described in the Microsoft document .
The configurations depicted in the following diagrams show how you can deploy the components leveraging a separate subnet for network virtual appliances (NVAs), with a trusted connection to the Horizon Cloud on Microsoft Azure components.
Figure 11: Trusted Unified Access Gateway Traffic Using a Separate VNet – Same Subscription, with NVA
Figure 12: Trusted Unified Access Gateway Traffic Using a Separate VNet – Separate Subscriptions, with NVA
You can choose to deploy user capacity workloads into a separate VNet to distinguish user workloads from each other within your pod’s subscription. There are some limitations to this configuration that are detailed in .
This can be useful if you need to build distinct environments to support separated testing environments, or secure access to other resources to individual VNets. Deploying assignments into separate VNets allows you more granular control of your deployment and enables you to use firewalls and other networking components to secure ingress and egress of the environment. If you leverage these features, you might need to set up VNet peerings to allow for communications between the pod management VNet or other VNets. To configure an assignment to use a separate VNet for user workloads, follow the guidelines in .
Figure 13: Using a separate VNet for user workload separation
Microsoft Azure is a cloud-based service platform that is deployed in many Azure data centers throughout the world, organized into regions. As the Microsoft states: “A region is a set of data centers deployed within a latency-defined perimeter and connected through a low-latency network.”
It is good practice to select an Azure region near your primary user groups or applications to achieve low network latency between your users’ VDI desktops or RDSH server farms and the applications they use. Doing so will have a positive impact on your users’ experience with Horizon Cloud on Microsoft Azure. Also make sure that the region you select has access to all the Azure products and services you plan to use. Azure products are not distributed uniformly across all Azure regions. For example, some virtual machine types might not be available in any given region. See .
Table 10: Implementation Strategy for Microsoft Azure Regions
We decided to use the Azure regions East US and East US 2 for data centers.
Our current on-premises data center is in Atlanta, GA (USA). The East US and East US 2 Azure regions are in different parts of Virginia (USA). The Azure regional data centers are roughly between 300 and 350 miles from Atlanta and provide relatively low-latency connections (< 30 ms) to the Atlanta area.
East US and East US 2 have less than 10 ms latency between them. This setup provides an opportunity to distribute workloads geographically across three separate locations and still have a low-latency connection from any given site to the others. For more information, see:
You can deploy multiple Horizon Cloud on Microsoft Azure pods into a single Azure region. Doing so enables you to service more than 2,000 users in any given locality. To accomplish this, you must leverage multiple Azure subscriptions in the same region.
Figure 14: Logical Diagram of Horizon Cloud Deployments – Multiple Pods in a Single Azure Region
You can deploy Horizon Cloud pods to multiple Microsoft Azure regions and manage them all through the Horizon Cloud Administration Console. Each Horizon Cloud pod is a separate entity and is managed individually. VM golden images, assignments, and users must all be managed within each pod. No cross-pod entitlement or resource sharing is available.
Figure 15: Logical Diagram Showing Horizon Cloud Deployments – Multiple Pods in Multiple Azure Regions
Table 11: Implementation Strategy for Multi-site Deployments
Three Horizon Cloud pods were deployed to Microsoft Azure regions:
Each region used a different subscription.
The use of separate Microsoft Azure regions illustrates how to scale and deploy Horizon Cloud for multi-site deployments.
Note: A configuration might be required for a multi-site deployment, depending on how you want users to access the Horizon Cloud on Microsoft Azure environment. You can leverage both options to scale to multiple subscriptions in the same and other regions as required.
You can configure each pod to provide access to desktops and applications for end users located outside of your corporate network. By default, Horizon Cloud pods allow users to access the Horizon Cloud environment from the Internet. When the pod is deployed with this ability configured, the pod includes a load balancer and Unified Access Gateway instances to enable this access.
If you do not select Internet Enabled Desktops for your deployment, clients must connect directly to the pod and not through Unified Access Gateway. In this case, you must perform some post-deployment steps to create the proper internal network routing rules so that users on your corporate network have access to your Horizon Cloud environment.
Entitlement to Multiple Pods
Starting with the , you are able to entitle users across Horizon Cloud on Microsoft Azure pods. While each Horizon Cloud pod is managed individually, and you can create Multi-Cloud Assignments to allow users to leverage resources in multiple Horizon Cloud on Microsoft Azure pods.
To be able to leverage Multi-Cloud Assignments, you must have selected Universal Broker as your broker type for your Horizon Cloud tenant account. For more details on Multi-Cloud Assignments and Universal broker and how they can be used to entitle users across Horizon Cloud on Microsoft Azure Pods, .
You can also implement Workspace ONE Access to show all Horizon and Application entitlements to a given user.
App Volumes Packages in Horizon Cloud on Microsoft Azure
Currently, App Volumes with Horizon Cloud on Microsoft Azure applies to either Floating Assignments using Windows 10 within Horizon Cloud on Microsoft Azure or Session-Based Desktop Assignments using Windows 10 Multi-Session farms with Horizon Cloud on Microsoft Azure. Details on the types of configurations where App Volumes packages can be used with Horizon cloud on Microsoft Azure can be found in .
By default, a single 20-GB package template is available with the App Volumes service. This template is automatically used during the packaging process to create packages in the VHD format.
Packages at Scale
Horizon Cloud on Azure currently supports up to 2000 concurrent users per pod. With Simplified Application Management (SAM), administrators can now record a single application in a package, there is no need to group them together. This approach simplifies the lifecycle management of an individual application but increases the number of packages that need to be delivered to the virtual desktop. The maximum number of App packages that can be mounted into a Windows desktop is bound by the limits in the Windows Operating system. Significantly increasing the number of App packages can impact the login time across users that are being serviced by a single pod only in certain cases.
In practice, the number of packages attached to a VM will likely be considerably lower than the maximum values.
Attaching packages involves the following processes:
- The disk mount (mounting the package VHD to the VM)
- The virtualization process applied to the content in the package (merging files and registry entries with the guest OS)
The time required to complete the virtualization process varies greatly, depending on the programs contained in a given package. The more packages that need to be attached, the longer this operation might take to complete.
Recommended Practices for Packaging Applications
Consider the following best practices when creating and packaging applications:
- The following characters cannot be used when naming packages: & “ ‘ < >
- The packaging process automatically creates packaging VMs based on an Image you create. Ensure the image selected contains the App Volumes agent, and that it resembles as closely as possible the target environment where the package is to be deployed. For example, the packaging VM and target should be at the same OS patch and service pack level and, if programs are included in the golden image, they should also be in the packaging VM image.
- Do not use a packaging machine where you have previously installed and then uninstalled any of the programs that you will capture. Uninstalling a program might not clean up all remnants of the software, and the subsequent App Volumes package capture might not be complete.
Recommended Practices for Updating and Assigning Updated Packages
App Volumes 4 introduced assignment types called marker and package to improve the administrative process of updating application packages. Using the current marker enables distribution of the current package to your end-user population, whereas using the package assignment type enables distribution of test versions to a subset of users for validation.
After a new package has been tested and approved, you can simply change the Current marker to point to the new package. As end users log out of their desktop sessions, the old version of the package is detached. When they log on again, the new version is attached.
The following illustration shows the Notepad++ application, which contains three packages with different versions of the software.
Figure 16: Portion of the Application Detailing the Three Packages and Current Marker
Notepad++ v7 has the Current marker, so it is distributed to the general population of end users. Notepad++ version 7.87 is an updated package that contains a newer version of the Notepad++ program.
Figure 17: Portion of the Application Assignment Detailing the Assignment Options
Notepad++ version 7.8.7 is using a package assignment type to directly assign that specific package to a group of test users for validation.
To learn more about assignment types, refer to Assign Application Package in App Volumes 4 Feature Review.
To initiate an update to programs in an existing package, use the App Volumes Manager console to invoke the update process. This process clones the original package for you to work with and apply updates. End users continue to work from the original package to prevent user downtime. The new package with the updated programs is distributed by simply moving the Current marker once it has been approved.
Consider the following best practices when updating and assigning updated packages:
- When creating and updating packages, use the Stage drop-down list to select an appropriate value. This makes it easy for you and other App Volumes admins to manage the lifecycle of the package.
Figure 18: List of Available Package Stages
- Use the marker assignment type to simplify updates for your general population of users
- Use the package assignment type for one-off, explicit assignments of a specific version.
Performance Testing for Packages
Test packages immediately after packaging to determine their overall performance. Using a performance analytics tool, to gather relevant performance information for use when packages are operated on a larger scale. Do not neglect user feedback, which can be extremely useful for assessing the overall performance of an application.
This evaluation can be time-consuming for the administrator, but it is necessary for any desktop- transformation technology or initiative.
ThinApp Integration with Packages
Microsoft Office Application Packages
For deploying Microsoft Office applications through App Volumes, see the VMware Knowledge Base article Installing and using Microsoft Office Products with VMware App Volumes 2.x/4.x.
The most straightforward method is to include Microsoft Office plug-ins or add-ons in the same package as the Microsoft Office installation.
However, if necessary, you can include plug-ins or add-ons in packages that are separate from the packages that contain the Microsoft applications to which they apply. Before packaging the plug-in or add-on, install the primary application natively in the OS of the packaging VM.
Note: Ensure the plug-in or add-on is at the same version as the Microsoft Office application in the package. This includes any patches or updates.
VMware recommends that you install core Microsoft Office applications in the base virtual desktop image, and create one package for non-core Microsoft Office applications, such as Visio, Project, or Visio and Project together.
To create the package with Visio and Project, use a packaging machine with the same core Microsoft Office applications as on the base image. After the package is created, you can assign the package to only the users who require these non-core Microsoft Office applications.
More Guidance and Considerations on Packages
- Overview chapters provide understanding of business drivers, use cases, and service definitions.
- Architecture chapters explore the products you are interested in including in your platform, including Workspace ONE UEM, Workspace ONE Access, Workspace ONE Assist, Workspace ONE Intelligence, Horizon, App Volumes Dynamic Environment Manager, and Unified Access Gateway.
- Integration chapters cover the integration of components and services you need to create the platform capable of delivering what you want.
- Configuration chapters provide reference for specific tasks as you build your platform, such as installation, deployment, and configuration processes for Horizon, App Volumes, Dynamic Environment Management, and more.