You must have a subscription for cloud capacity in Microsoft Azure and then bring that subscription information to pair that cloud capacity with Horizon Cloud. After the pod is deployed in Microsoft Azure, you use Horizon Cloud Administration Console to create master images, farms and VDI desktops, assign use of desktops and applications to your users, as well as how to perform other administrative tasks. From a pod located in Microsoft Azure, your end users can securely access their desktops and applications from any device. You can choose where the desktops and applications reside, based on the location of the deployed pod.

For the overall introduction to Horizon Cloud, see Introduction to Horizon Cloud and Cloud-Connected Pods. For the suggested workflow of activities for a pod in Microsoft Azure, see Suggested Workflow for When Your Very First Cloud-Connected Pod is from Deploying into Microsoft Azure.

Horizon Cloud Pod Deployed in Microsoft Azure

You connect your Microsoft Azure subscription to Horizon Cloud to manage and deliver VDI desktops and RDSH-served desktops and applications. Setting up the environment involves deploying the pod into your Microsoft Azure capacity.

The pod deployed by Horizon Cloud into Microsoft Azure has a physical regional location in a Microsoft Azure cloud. In the pod deployment wizard, you select where to place the pod, according to the regions available for your particular Microsoft Azure subscription. You also select an existing virtual network (VNet) that the pod will use in your selected region.
Note: You preconfigure your Microsoft Azure environment with that VNet, and you can either create the subnets required by the pod in advance or let the pod deployer create the subnets during deployment. If you do not create the subnets in advance, the pod deployer creates the subnets as it deploys the pod into your environment. If you choose to have the pod deployer create its required subnets, you have to know what IP address spaces you want to use for the pod's subnets before you start the deployment wizard. If you choose to create the subnets in advance, you must ensure they meet certain requirements before you start the deployment process. For details about requirements when you create the subnets in advance, see Optionally Create the Pod's Required Subnets on your VNet in Microsoft Azure and When Using Existing Subnets for a Horizon Cloud Pod in Microsoft Azure.
Important: This pod in Microsoft Azure is not a tenant. This pod does not adhere to the exact same set of characteristics that defines a tenant and which you would expect from a tenant. For example, even though a tenant would have a one-to-one mapping to an Active Directory domain and be isolated from other tenants, all of the Horizon Cloud pods in Microsoft Azure that are deployed using the same Horizon Cloud customer account record need to be able to reach the same Active Directory servers and the DNS configuration needs to resolve all of those Active Directory domains.

To do multi-tenancy, you would set up multiple Horizon Cloud customer account records. The Horizon Cloud customer account record, which is created when you registered with VMware to use the Horizon Cloud Service and is associated with your My VMware credentials, is more like a tenant. A Horizon Cloud customer account record is isolated from other Horizon Cloud customer account records. A single customer account record maps to multiple pods, and when someone uses any of the account credentials associated with that customer account record to log in to the Administration Console, the console reflects all of the pods that are mapped to that customer account record.

The pod deployment process automatically creates a set of resource groups in your Microsoft Azure capacity. Resource groups are used to organize the assets that the environment needs and creates, such as:

  • VMs for the pod's manager instance (multiple VMs for a pod that is enabled for high availability)
  • VMs for the Unified Access Gateway instances and their load balancers
  • VMs for the master RDS-enabled server images
  • VMs for the master VDI desktop images
  • VMs for the assignable (published) images that are made from the master images
  • VMs for the RDSH farms that provide the RDSH desktops and remote applications
  • VMs for the VDI desktops
  • Additional assets that the VMs and the environment require for supported operations, such as network interfaces, IP addresses, disks, key vaults, Microsoft Azure Database for PostgreSQL server resource, and various items along those lines. The pod deployment process can create the required virtual subnets also, using the values you specify in the deployment wizard.

All of the resource groups created by Horizon Cloud in your Microsoft Azure environment are named using the prefix vmw-hcs.

Caution: Do not manually modify or delete the pod-related resources using the Microsoft Azure portal except for:
  • Manual creation of master images.
  • Modifying farm and VDI desktop assignment network security groups as need to configure ports for your business circumstances.

Horizon Cloud automatically configures the pod-related resources to ensure the pod operates as designed. Do not manually change settings for the resources that are automatically created and deployed during workflows, assigned IP addresses or names, and so on. Do not manually power off VM instances directly using the Microsoft Azure portal. Do not manually delete the manager VM or Unified Access Gateway VMs. Do not manually delete NICs from the resource groups, especially from the Unified Access Gateway resource groups. If you change the generated settings or manually power off VMs or manually delete VMs or NICs that were created by the pod deployer, unpredictable results can occur and pod operations and pod upgrades might encounter failures.

The following diagram illustrates a deployed pod that is enabled for high availability and has both the external and internal types of Unified Access Gateway configurations. In this diagram, RG means resource group. The Unified Access Gateway instances in the external Unified Access Gateway configuration have NICs on the demilitarized (DMZ) network. When your pod has the external Unified Access Gateway configuration, your end users located in the Internet, outside your corporate network, can access their pod-provisioned virtual desktops and applications through that configuration. When your pod has the internal Unified Access Gateway configuration, your end users located in your intranet, inside your corporate network, can make trusted connections to their pod-provisioned virtual desktops and applications through that gateway. The pod deployment wizard provides the option to deploy the pod with both configurations up front. Alternatively, you can deploy the pod with only one gateway configuration or with none at all, and edit the deployed pod to add the non-chosen gateway configuration later.

You can also choose not to enable the high availability option in the deployment wizard, and then edit the deployed pod later to enable high availability on it. A new pod is always deployed with the Azure Postgres database and pod load balancer, even when you do not enable the high availability option in the wizard. Having those assets available allows for easy enablement of high availability on an already deployed pod. The second pod manager VM is only deployed when high availability is enabled on the pod.

Figure 1. Illustration of the Horizon Cloud Pod Architecture for a Pod with High Availability Enabled and Configured with Both External and Internal Unified Access Gateway Configurations

Architecture illustration of the pod's resource groups, VMs, and subnets for a pod that has high availability enabled and both types of Unified Access Gateway configurations

Subscriptions and Number of Pods

Be mindful about the number of pods you deploy into a single subscription, especially if you plan to have each pod running at a large scale. Even though multiple pods can be deployed into a single Microsoft Azure subscription, whether all into one region or spread across multiple regions, Microsoft Azure imposes certain limits within a single subscription. Because of those Microsoft Azure limits, deployment of a large number of pods into a single subscription increases the likelihood of hitting those limits. Numerous variables, and combinations of those variables, are involved in reaching those limits, such as the number of pods, the number of farms and assignments within each pod, the number of servers within each pod, the number of desktops within each assignment, and so on.

If you plan to have pods running at a large scale, consider adopting the approach of having multiple subscriptions with those multiple subscriptions under one Microsoft Azure account. Microsoft Azure customers use this approach, and often prefer it, because it provides some benefits for ongoing management of the subscriptions. Using this approach, you would deploy a single pod per subscription, roll up those subscriptions in a single "master" account, and avoid the chances of hitting the Microsoft Azure limits that are imposed on a single subscription.

When You Have Existing Pods That Were Deployed Prior to This Current Horizon Cloud Release

As described in Updating Your Horizon Cloud Pod, VMware updates the Horizon Cloud software components periodically to include new features and bug fixes. The in-cloud management environment is updated on a weekly basis and the pod software components are typically updated on a roughly quarterly basis. The Horizon Cloud Service documentation page provides access to versioned Release Notes where the versions correspond to those quarterly releases, such as version 2.1 for the September 2019 release.

When you deploy a new pod, that pod is always created at the manifest version that is the latest one for the current in-production service environment. As an example, if you created a new pod in August 2019, that pod was deployed with software components that were current for Horizon Cloud as of that date. Depending on how long you have been using your Horizon Cloud environment, on a given calendar date, your overall Horizon Cloud environment might include some pods that are at the latest released version and some that are at an earlier released version which are not yet upgraded to the latest manifest.

Important: In general, the content in this Administration Guide describes features, workflows, and behaviors that are available in the current in-production release and which are applicable when your pod is at the latest pod manifest version which was made available in this current release. The Administration Console is dynamic and will typically display messages when an area or action in the user interface requires upgrading the pod to use that feature. For a pod that existed prior to this release, some workflows might require different steps than are described in this Administration Guide. For a list of workflows in this release that are now different for pods at the latest manifest version, see the latest Release Notes document at

Microsoft Azure Terminology and References

The VMware Horizon Cloud Service on Microsoft Azure product documentation uses the applicable Microsoft Azure terminology as appropriate in the descriptions and task steps of the VMware Horizon Cloud Service on Microsoft Azure workflows. If the Microsoft Azure terminology is unfamiliar to you, you can use the following applicable references in the Microsoft Azure product documentation to learn more.

Note: All capitalization and spelling in the citations below follow the same capitalization and spelling found in the linked-to articles in the Microsoft Azure documentation itself.
Useful Microsoft Azure References Description
Microsoft Azure glossary: A dictionary of cloud terminology on the Azure platform Use this glossary to learn the meaning of terms as used in the Microsoft Azure cloud context, for terms such as load balancer, region, resource group, subscription, virtual machine, and virtual network (vnet).
Note: The Microsoft Azure glossary does not include the term service principal because the service principal is a resource automatically created in Microsoft Azure when an application registration is created in Microsoft Azure. The reason why you create an application registration in your Microsoft Azure subscription is because that is the way you authorize Horizon Cloud as an application to use your Microsoft Azure capacity. The application registration and its companion service principal enable the Horizon Cloud cloud service acting as an application to access resources in your Microsoft Azure subscription. Use the next reference below to learn about applications and service principals that can access resources in Microsoft Azure.
Use portal to create an Azure Active Directory application and service principal that can access resources

Use this article to learn about the relationship between an application and a service principal in a Microsoft Azure cloud.

Azure Resource Manager overview

Use this article to learn about the relationships between resources, resource groups, and the Resource Manager in Microsoft Azure.

Azure VNet

Use this article to learn about the Azure Virtual Network (VNet) service in Microsoft Azure. See also Azure Virtual Network FAQs.

Azure VNet Peering

Use this article to learn about virtual network peering in Microsoft Azure.

Microsoft Azure ExpressRoute Overview

Use this article to learn about Microsoft Azure ExpressRoute and how you can use it to establish connections between your on-premises networks, Microsoft Azure, and your Horizon Cloud pods.

About VPN Gateway

Planning and design for VPN Gateway

Create a Site-To-Site connection in the Azure portal

Use these articles to learn about how to configure VPNs in Microsoft Azure.

What is Azure Load Balancer?

Use this article to learn about the Azure load balancers that are deployed for a pod: the load balancer for the pod manager VMs and the load balancers for the gateway configurations.

What is Azure Database for PostgreSQL? Use this article to learn about the Microsoft Azure Database for PostgreSQL service.