Horizon Cloud on Microsoft Azure Deployments

This documentation page introduces the key characteristics of Horizon Cloud on Microsoft Azure deployments. These deployments are also referred to as Horizon Cloud pods.

Brief Introduction

Horizon Cloud pods are based on the Horizon Cloud pod-manager technology. This pod-manager technology runs solely in a Microsoft Azure subscription and does not require a VMware SDDC.

A Horizon Cloud on Microsoft Azure deployment is distinct from other Horizon deployment types, which involve Horizon Connection Server software components.

Deployments

You deploy Horizon Cloud on Microsoft Azure by deploying a pod-manager-based pod using the automated pod deployment wizard. You must have a subscription for cloud capacity in Microsoft Azure and then bring that subscription information to pair that cloud capacity with your Horizon Cloud tenant.

The wizard deploys the required VMware software components into your Microsoft Azure cloud subscription, creating the Horizon Cloud on Microsoft Azure deployment.

The deployed VMware software creates an appropriately configured entity, called a pod, which pairs with the control plane.

After the pod is deployed, then you use the control plane to provision VDI desktops and RDSHs, and entitle access to desktops and remote applications to your end users.

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. You have the option to deploy an external gateway configuration with the pod, with that external gateway's resources deployed either into the same VNet as the pod or into a separate VNet that is peered with the pod's VNet.

Note: You preconfigure your Microsoft Azure environment with the pod VNet (and with the external gateway VNet if using that configuration option). You can either create in advance those subnets that the pod and external gateway configuration require, 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 required VMs and resources 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 In Advance of Pod Deployment, Create the Horizon Cloud Pod's Required Subnets on your VNet in Microsoft Azure and When Using Existing Subnets for a Horizon Cloud Pod in Microsoft Azure.

You can deploy more than one pod into Microsoft Azure and manage all of them from the same administrative console. The pods you deploy after the first one can reuse the same VNet as your first pod or use different VNets. Also, each pod can be in a different Microsoft Azure region, using a VNet in each region.

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 VMware Customer Connect 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 administrative 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 manager instances.
VMs for the Unified Access Gateway instances and their load balancers
VM for the connector VM in the external gateway configuration when you deploy that configuration in a VNet separate from the pod's VNet
VMs for the RDSH-capable golden images
VMs for the VDI desktop golden images
VMs for the assignable (published, sealed) images that are made from the golden 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.

The following diagram illustrates a deployed pod which has both the external and internal types of gateway configurations, and where the external gateway resides in the same VNet as the pod itself. In this diagram, RG means resource group.

The Unified Access Gateway instances in the external gateway configuration have NICs on the demilitarized (DMZ) network. With an external gateway configuration, you can have your end users located in the Internet, outside your corporate network, accessing their pod-provisioned virtual desktops and applications through that configuration. With an internal gateway configuration, you can have your end users located in your intranet, inside your corporate network, making trusted connections to their pod-provisioned virtual desktops and applications through that gateway.

The pod deployer 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 deploy the pod initially without either type and add on later.

The system deploys the pod with high availability, having two pod manager VMs by default.

Architecture illustration of the pod's resource groups, VMs, and subnets for a pod that has both types of Unified Access Gateway configurations, with the external gateway residing in the same VNet as the pod. — Figure 1. Illustration of the Horizon Cloud Pod Architecture where the Pod has Both External and Internal Gateway Configurations, the External Gateway Deployed into the Same VNet as the Pod, Three NICs on the External Gateway VMs, Two NICs on the Internal Gateway VMs, and a Public IP Enabled for the External Gateway's Load Balancer

The following diagram illustrates the resources that are deployed when you choose the option to have the external gateway residing in its own VNet, separate from the pod's VNet. The two VNets must be peered. This diagram also applies when you choose the option to have the external gateway's resources deployed using a Microsoft Azure subscription that is different than the one used for the pod. Because VNets cannot cross subscriptions, choosing to deploy the external gateway into its own subscription is a subset of choosing the external gateway to reside in its own VNet.

Tip: Deploying the external gateway configuration into its own VNet gives you the ability to deploy these Horizon Cloud pods into complex Microsoft Azure environments that use hub-spoke network topology in Microsoft Azure.

Architecture illustration of an external gateway's elements when the external gateway is deployed into its own VNet. In this case, there is a Connector VM with a NIC to the VNet's management subnet, along with the standard elements for the external gateway itself. — Figure 2. Illustration of the External Gateway's Architecture Elements When the External Gateway is Deployed into Its Own VNet, Separate from the Pod's VNet

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.
Hub-spoke network topology in Azure	Use this article to learn about hub-spoke network topology 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.
What is Azure Virtual Desktop?	Use this article to learn about Microsoft Azure Virtual Desktop and how it relates to Microsoft Windows 10 Enterprise multi-session and Microsoft Windows 7 Enterprise with Extended Security Updates. When your Horizon Cloud tenant account has the configuration for Horizon Cloud Service on Microsoft Azure extending Microsoft Azure Virtual Desktop, support is provided for using Microsoft Windows 10 Enterprise multi-session and Microsoft Windows 7 Enterprise with your pods deployed in Microsoft Azure.

Additional VMware Resources

The following resources provide in-depth technical details about the service.

Additional VMware Technical Resources	Description
Requirements Checklist	Use this checklist to learn about the assets you need to obtain and configure prior to beginning the pod deployment process.
Networking and Active Directory Considerations on Microsoft Azure with VMware Horizon Cloud	Use this article to learn about the various options and best practices for networking connections and using Microsoft Active Directory with your Horizon Cloud pods in Microsoft Azure.
Horizon Cloud Service on Microsoft Azure Security Considerations	Use this article to obtain information about the security details of the environment and the types of data stored.
Horizon Cloud on Microsoft Azure: RDS Desktop and App Scalability (technical paper download)	Use this article to gain insight from analyses on RDS desktop and remote application scalability and optimal user densities, as well as cost considerations related to farm deployment and power management settings.