Horizon Cloud on Microsoft Azure Architecture

This chapter is one of a series that make up the VMware Workspace ONE and VMware Horizon Reference Architecture, 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.


VMware Horizon Cloud Service 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 Microsoft Azure.

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.

Deployment Overview

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 both dedicated and floating desktops.

Horizon Cloud Service on Microsoft Azure includes the following components and features.

Table 1: Components of Horizon Cloud on Microsoft Azure



Jump box

The jump box is a temporary Linux-based VM used during environment buildout and for subsequent environment updates and upgrades.

One jump box is required per Azure pod only during platform buildout and upgrades.

Management VM

The management VM appliance provides access for administrators and users to operate and consume the platform.

One management VM appliance is constantly powered on; a second is required during upgrades.

Horizon Cloud control plane

This cloud-based control plane is the central location for conducting all administrative functions and policy management. From the control plane, you can manage your virtual desktops and RDSH server farms and assign applications and desktops to users and groups from any browser on any machine with an Internet connection.

The cloud control plane provides access to manage all Horizon Cloud pods deployed to your Microsoft Azure infrastructure in a single, centralized user interface, no matter which regional data center you use.

Horizon Cloud Administration Console

This component of the control plane is the web-based UI that administrators use to provision and manage Horizon Cloud desktops and applications, resource entitlements, and VM images.

The Administration Console provides full life-cycle management of desktops and Remote Desktop Session Host (RDSH) servers through a single, easy-to-use web-based console. Organizations can securely provision and manage desktop models and entitlements, and native and remote applications, through this console.

The console also provides usage and activity reports for various user, administrative, and capacity-management activities.

Horizon Agent

This software service, installed on the guest OS of all virtual desktops and RDSH servers, allows them to be managed by Horizon Cloud pods.

Horizon Client

This software, installed on the client device, allows a physical device to access a virtual desktop or RDSH-published application in a Horizon deployment. You can optionally use an HTML client on devices for which installing software is not possible.

Unified Access Gateway

This gateway is a hardened Linux virtual appliance that allows for secure remote access to the Horizon Cloud environment. This appliance is part of the Security Zone (for external Horizon Cloud access) and the Services Zone (for internal Horizon Cloud access).

The Unified Access Gateway appliances deployed as a Horizon Cloud pod are load balanced by an automatically deployed and configured Microsoft Azure load balancer. The design decisions for load balancing within a pod are already made for you.

RDSH servers

These Windows Server VMs provide published applications and session-based remote desktops to end users.


Table 2: Implementation Strategy for Horizon Cloud Service on Microsoft Azure


A Horizon Cloud Service on Microsoft Azure deployment was designed and integrated with the Workspace ONE platform.

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

Architecture Overview

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

  • Runs on the Horizon Cloud on Microsoft Azure Pod Manager.
  • Installed and configured as a part of Horizon Cloud on Microsoft Azure Pod deployment.
  • Broker for App Volumes Agent for the assignment of packages.

App Volumes Agent

  • Runs on virtual desktops, Windows 10 multi-session VMs (in Tech Preview).
  • File system and registry abstraction layer running on the target system.

Application Assignment

  • Logical component containing one or more packages.
  • Used to assign AD entities to packages.
  • Supports marker and package assignment types.


  • Read-only volume containing programs.
  • VHD file that attaches to deliver apps to VDI.
  • One or more packages may be assigned per user.


  • Represents a piece of software captured in a package.
  • One or more programs may be captured in a package.


  • App Volumes database (AVDB) is one of the databases used by the HCSoA pod.
  • External PostgreSQL DB used when high availability (HA) is enabled on the pod for improved data resiliency, even with a pod re-deployment.
  • Embedded PostgreSQL DB used for pod without HA. 
  • Estimated database growth is less than 1MB per package.

Active Directory

  • Environment used to assign and entitle users to packages.

Microsoft Azure Infrastructure

  • App Volumes is implemented as a feature within Horizon Cloud on Microsoft Azure and uses pod-based components to leverage Microsoft Azure resources.

Packaging VMs

  • Clean Windows VM with App Volumes Agent.
  • Used to capture software programs to packages for distribution.
  • Automatically created as a part of the packaging process with Horizon Cloud on Microsoft Azure.
  • Administrator is automatically connected to the packaging VM when it is ready.

Azure Files


Key Design Considerations

Network Ports for App Volumes

See App Volumes Applications - Overview and Prerequisites for a list of ports requirements for App Volumes.

See Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later for details on Ports and Protocols and DNS Requirements for Horizon Cloud on Microsoft Azure, and much more.

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 with in 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 Introduction to Universal Broker and Single-Pod Broker 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 Known Limitations of Universal Broker for details. There are also a number of system requirements for Universal Broker that are required for different components of your Horizon Cloud on Microsoft Azure implementation.

Table 4: Implementation Strategy for Universal Broker


We are leveraging the single pod brokering method. Using VMware Workspace ONE Access, our users have visibility into all resources and applications assigned to them upon login to a single URL.


At the time of writing, Universal Broker has a number of limitations that prohibited us from using Universal Broker. The reasons are detailed in the Horizon Control Plane Component Design guide.

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 Horizon Cloud Service on Microsoft Azure Requirements Checklist for New Pod Deployments.


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 DNS Requirements for a Horizon Cloud Pod in Microsoft Azure.

Horizon Cloud on Microsoft Azure operates using Microsoft Azure infrastructure components. Subscriptions are hosted in Azure regions (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 Maintenance for virtual machines in Azure and SLA summary for Azure services. You can view the current status of Azure regions on the Azure status page.


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 a single pod 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.

For more information, see VMware Horizon Cloud Service on Microsoft Azure Service Limits.

For information about creating subnets and address spaces, see Configure the Required Virtual Network in Microsoft Azure.

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 Microsoft Azure infrastructure 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.

A Microsoft Azure region is a set of data centers deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network.

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 Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings.

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 Azure subscription and service limits, quotas, and constraints. Microsoft Azure has a maximum of 10,000 vCPUs 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 Service Level Agreement for individual components and services provided by Microsoft Azure.

Horizon Cloud on Microsoft Azure uses Azure availability sets 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 Business continuity and disaster recovery (BCDR): Azure Paired Regions.

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.

For details, see Integrate a Horizon Cloud Node with a Workspace ONE Access Environment and Configure True SSO for Use with Your Horizon Cloud Environment.

See Horizon Cloud Service with Workspace ONE Access Integration in the Platform Integration chapter.

True SSO

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.

Design Overview

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.

For information on how to install and configure True SSO, see Configure True SSO for Use with Your Horizon Cloud Environment. Also, see Setting Up True SSO for Horizon Cloud Service on Microsoft Azure in Horizon Configuration.

Optional Components

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 Load Balancing UAGs in Horizon Cloud on Microsoft Azure Deployments on the Avi Networks site.

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 Configure the Virtual Network’s DNS Server.
  • 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 Active Directory Domain Configurations.
  • 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 License your RDS deployment with client access licenses (CALs).
  • 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 Add, change, or remove IP addresses for an Azure network interface.
  • 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 Selecting the Correct Certificate Type. Also, see Environment Infrastructure Design for details on how certificates impact your Horizon Cloud on Microsoft Azure deployment.

Network Design

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

Basic Horizon Cloud on Microsoft Azure Deployment – Same VNet and Subscription for All Components

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

Using these two deployment options allows you to deploy Horizon Cloud on Microsoft Azure to accommodate a hub and spoke architecture built within Microsoft Azure

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 In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure.

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.

Additional Azure Subscription Used for the External Gateway

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:

Also, see Prerequisites for Running the Pod Deployment Wizard in the Horizon Cloud Deployment Guide.

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.

Unified Access Gateway in a Separate VNet – Same Subscription

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:

Also, see Prerequisites for Running the Pod Deployment Wizard in the Horizon Cloud Deployment Guide.

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 Hub-Spoke network topology with shared services in Azure.

Using a Separate VNet for Trusted UAG-NVA Traffic to Horizon Cloud Components

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.

Trusted Unified Access Gateway Traffic Using a Separate VNet – Same Subscription, with NVA

Figure 11: Trusted Unified Access Gateway Traffic Using a Separate VNet – Same Subscription, with NVA

Trusted Unified Access Gateway Traffic Using a Separate VNet – Separate Subscriptions, with NVA

Figure 12: Trusted Unified Access Gateway Traffic Using a Separate VNet – Separate Subscriptions, with NVA

Using a Separate VNet for User Workload Separation

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 Overview of Using Multiple Tenant Subnets with your Horizon Cloud Pod.

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 peelings 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 Overview of Using Multiple Tenant Subnets with your Horizon Cloud Pod.

Figure 13: Using a separate VNet for user workload separation

Single-Site Design

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 Azure regions page 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 Products available by region.

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.

Logical Diagram of Horizon Cloud Deployments – Multiple Pods in a Single Azure Region

Figure 14: Logical Diagram of Horizon Cloud Deployments – Multiple Pods in a Single Azure Region

Multi-site Design

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 master images, assignments, and users must all be managed within each pod. No cross-pod entitlement or resource sharing is available.

Logical Diagram Showing Horizon Cloud Deployments – Multiple Pods in Multiple Azure Regions


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:

  • One pod was deployed to the US East Region of Microsoft Azure.
  • Two pods were deployed to the US East 2 Region of Microsoft Azure.

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 Split-horizon DNS 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.

External Access

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.

If you decide to implement Horizon Cloud on Microsoft Azure so that only internal connections are allowed, you will need to configure your DNS correctly with a Split-horizon DNS configuration. 

Entitlement to Multiple Pods

You can manually spread users across multiple Horizon Cloud pods. However, each Horizon Cloud pod is managed individually, and there is no way to cross-entitle users to multiple pods. Although the same user interface is used to manage multiple Horizon Cloud pods, you must deploy separate VM images, RDSH server farms, and assignments on each pod individually. 

You can mask this complexity from a user’s point of view by implementing Workspace ONE Access so that end users must use Workspace ONE to access resources. For example, you could entitle different user groups to have exclusive access to different Horizon Cloud on Microsoft Azure deployments, and then join each pod to the same Active Directory.

Note: Although this method works, there is currently no product support for automatically balancing user workloads across Horizon Cloud pods.

App Volumes Packages in Horizon Cloud on Microsoft Azure

Currently, App Volumes with Horizon Cloud on Microsoft Azure only applies to Floating Assignments using Windows 10 within Horizon Cloud on Microsoft Azure. This section will be updated as App Volumes for Horizon Cloud on Microsoft Azure supports more assignment types. 

Package Templates

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.

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.

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.

Graphical user interface, application</p>
<p>Description automatically generated

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.

Graphical user interface, text, application, chat or text message</p>
<p>Description automatically generated

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.

Graphical user interface, website</p>
<p>Description automatically generated

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.

Some performance guidance details might be covered in Known Limitations for App Volumes on Horizon Cloud.

ThinApp Integration with Packages

For details about using ThinApp in App Volumes packages, see ThinApp Integration with Packages in the App Volumes Architecture chapter.

Microsoft Office Application Packages

For deploying Microsoft Office applications through App Volumes, see the VMware Knowledge Base article VMware App Volumes 2.x with Microsoft Office Products (2146035).

Office Plug-Ins and Add-Ons

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.

Recommended Practices for Installing Office

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. 

For additional guidance, see Best Practices for Delivering Microsoft Office 365 in VMware Horizon 7.

More Guidance and Considerations on Packages

For more guidance and considerations on App Volumes packages, see Application Suitability for Packages in the App Volumes Architecture chapter.

What’s Next?

Now that you have come to the end of this chapter, you can return to the landing page and search or scroll to select your next chapter in one of the following sections:

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

Filter Tags

Horizon Horizon Cloud Service Document Reference Architecture Advanced Design Windows Delivery