Horizon Cloud Service - next-gen 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 Horizon Cloud Service - next-gen.
Introduction
Horizon Cloud Service – next-gen is a modern cloud-first, multi-cloud Desktop as a Service (DaaS) deployment with Thin Edge Infrastructure. The service provides you with a global view of your desktops and applications spanning across on-premises and cloud environments. Regardless of the location of your desktop and application deployments, Horizon Cloud Service enables you to consistently manage and monitor them.
The Horizon Cloud Service - next-gen infrastructure components, such as the connection servers, applications volumes manager, pod managers, and databases are removed from the user environment and the functionality moved into the cloud control plane. This separates the management infrastructure and functionality, which is delivered as cloud services from the Horizon Control Plane, from the resource capacity, which is delivered by supported capacity providers.
Figure 1: Horizon Cloud Service next-gen Overview
Table 1: Horizon Cloud Service next-gen Setup Strategy
| Decision | A Horizon Cloud Service – next-gen deployment was designed and implemented. |
| Justification | This strategy allowed the design, deployment, and integration to be validated and documented. |
Architectural Overview
A successful deployment of VMware Horizon Cloud Service – next-gen depends on good planning and a robust understanding of the platform. This section gives an architectural overview and introduces the key components and concepts that you will need to understand.
The core elements of Horizon Cloud Service – next-gen include:
- Horizon Control Plane
- Horizon Edge
- Provider
- Horizon Edge Deployment
- Provider Networking
- User Capacity
Figure 2: Logical Architecture Overview
Horizon Cloud Service – next-gen includes the following components and features.
Table 2: Components of Horizon Cloud Service - next-gen
| Description | |
| Horizon Control Plane | A distributed cloud-based control plane that includes the containerized services that deliver Horizon Cloud Service – next-gen. It is used for 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 the ability to deploy and manage all Horizon Edges from a single, centralized user interface, no matter which regional data center you use. With Horizon Cloud Service next-gen, the control plane also provides end-user services, such as session brokering. |
| Horizon Universal Console | A web-based UI, based in the Horizon Control Plane, that administrators use to register resource providers and deploy Horizon Edge instances. The console also allows administrators to manage VM images, provision and manage Horizon desktops, applications, and resource entitlements. The Universal Console provides full life-cycle management of desktops and Remote Desktop Session Host (RDSH) servers through a single, easy-to-use web-based console. |
| Horizon Edge | A Horizon Edge is an instance of Horizon pushed out by Horizon Cloud Services as defined in the Horizon Universal Console. A Horizon Edge is deployed into the customer's resource capacity in a specified primary provider in a specific site. A Horizon Edge contains:
See Horizon Edge. |
| Horizon Edge Deployment | A Horizon Edge Deployment is automatically created when you select to deploy a new Horizon Edge to a new provider. It contains:
|
| Horizon Edge Gateway | Provides user capacity resource monitoring and management. This enables VMware to create single-user VDI desktops and multi-user applications and session hosts and to monitor those resources. Handles end-user authentication services (SSO module) that allow the service to communicate with a trusted identity provider and a customer Active Directory instance for single sign-on (SSO) capabilities. Allows VMware to install, manage, and monitor Unified Access Gateways in the provider capacity. For more information, see Horizon Edge Gateway. |
| Unified Access Gateway | Virtual appliances that enable secure remote access from an external network to a variety of internal resources, including Horizon-managed resources. For more information, see Unified Access Gateway. |
| Site | A physical location or data center that is used to logically group one or more Horizon Edges. The site can be used to define where end users get delivered resources from.
|
| Provider | The supported hypervisors and cloud platforms that provide the necessary resource capacity to provision and deliver desktops and applications to end-users. Primary Provider - The provider that contains the Horizon Edge deployment (Horizon Edge Gateway & Unified Access Gateways). Secondary Providers –additional providers used to expand a Horizon Edge beyond the number of VMs supported by the primary provider. See Providers. |
| Provider Networking | Network and subnets that are required for the Horizon Edge deployment VMs and customer-managed workload. For more information, see Azure Provider Networking. |
| User Capacity | User capacity is where the desktop pools and application farms are hosted within the resource provider. This capacity can be provided by primary and secondary providers. See Single Horizon Edge Scaling. User capacity is also used for VM images (templates). |
Horizon Control Plane
The Horizon Control Plane is a distributed cloud-based control plane that contains the containerized services that deliver Horizon Cloud Service – next-gen. It is used for all administrative functions and policy management and to provide user services.
The cloud control plane provides the ability to deploy and manage Horizon Edges from a single, centralized user interface.
Figure 3: Horizon Control Plane Services
With Horizon Cloud Service - next-gen, many of the infrastructure components and functionality that were traditionally deployed into each site are now provided by the Horizon Control plane and the distributed services it runs.
This means that the footprint for a deployment only requires a thin edge (a Horizon Edge Deployment) which makes for easier deployment, management, lower cost, and nimble scalability.
With Horizon Cloud Service - next-gen, the Horizon Control Plane includes end-user services, such as integration into identity management and session brokering.
Horizon Edge
A Horizon Edge is an instance of Horizon pushed out by Horizon Cloud Services as defined by an administrator in the Horizon Universal Console.
A Horizon Edge is deployed into the customer’s resource capacity in a specified primary provider in a selected site. It is based in a single physical location or region and can be divided into multiple blocks to provide scalability.
A Horizon Edge contains:
- A Horizon Edge deployment (Horizon Edge Gateway, Unified Access Gateways, and load balancers)
- User capacity to host image templates, desktop pools, and published application.
- Capacity can be provided by either the initial provider used when creating the Horizon Edge or with secondary providers to allow scaling. See Providers.
- Networking inside the provider to allow the components to properly communicate
Horizon Edge Deployment
A Horizon Edge deployment is created on your behalf in the provider that you have registered and chosen for the Horizon Edge. All the necessary configuration components are automatically deployed on Azure via the service principal that was defined in the provider configuration.
A Horizon Edge deployment includes:
- A Horizon Edge gateway component
- Unified Access Gateway appliances
- Azure load balancing for the Unified Access Gateways
Figure 4: Horizon Edge Deployment
Horizon Edge Gateway
The Horizon Edge Gateway is an infrastructure component that is deployed into the selected primary provider as part of the Horizon Edge creation process.
The Horizon Edge Gateway:
- Allows the management, and monitoring of Unified Access Gateways, in the provider capacity
- Handles end-user authentication services (SSO module) that allow the service to communicate with a trusted identity provider and a customer Active Directory instance for single sign-on (SSO) capabilities
- Provides user resource monitoring of desktops, farms, and VMs with Horizon agents
- Can be provisioned in a highly available configuration
Unified Access Gateway
Unified Access Gateways (UAG) are virtual appliances that enable secure remote access from an external network to internal resources, including Horizon-managed resources, such as virtual desktops and published applications. They direct authenticated requests to the appropriate resource, proxying the Horizon display protocol from the client device to the VM with the agent.
Unified Access Gateways are deployed in a Horizon Edge by the Horizon Edge Gateway, into the same provider as the Horizon Edge Gateway.
The Unified Access Gateways can either be in the same VNet as the Horizon Edge Gateway, or in a different VNet that is part of the chosen provider configuration. If using different VNets, virtual network peering between the VNets is required. The UAGs are attached to the DMZ, management, and the desktops subnets defined in the chosen VNet. See Azure Provider Networking for information on required VNet subnets.
Azure load balancing is deployed as part of the configuration to load balance traffic across the Unified Access Gateways.
Horizon Edge Deployment Networking
A Horizon Edge deployment relies on a network location to deploy the Horizon Edge onto.
When using Microsoft Azure as a provider, the Horizon Edge deployment networking is a VNet. A Microsoft Azure VNet is a virtual infrastructure component of the Microsoft Azure platform. When deploying a Horizon Edge to an Azure provider, Azure networking must be configured to provide networking for Horizon resources and user capacity.
The network location must be segregated into multiple subnets, used to segregate resources from each other. When using Microsoft Azure, an Azure VNet must be configured with subnets before a Horizon Edge is deployed. For more information, see Azure Provider Networking.
You need to make sure that you have sufficient IP addresses in each subnet (VNet on Azure) to handle all the virtual machines deployed into each subnet. The management and DMZ subnets only contain a handful of networked resources. With the desktop subnet, you need to make sure that you have enough IP addresses available in the subnet to handle the number of standalone or shared desktops included in the deployment.
Figure 5: Horizon Edge Deployment Networking
Horizon Edge Connectivity
Each Horizon Edge needs to define how Horizon Agents connect to the Horizon Control Plane. This can be either via the Internet or with internal networking.
- Azure Private Link (internal).
- Internet – This is the simplest method of connecting Horizon Agents to the Horizon Control Plane.
In both configurations, a single VNet is used for each Horizon Edge.
Figure 6: Horizon Edge Connectivity
Configuration
The Universal Console in the Horizon Control Plane can be used to define, deploy, and manage Horizon Edges. Before deploying your first Horizon Edge, complete the onboarding tasks to assign roles, launch Horizon Cloud for the first time, and select a region for Horizon Cloud services metadata. See VMware Horizon Cloud Service - next-gen Deployment and Onboarding.
Figure 7: Deploying a Horizon Edge
To deploy a new Horizon Edge:
- Prepare Azure - See Preparing Microsoft Azure.
- Register a new resource provider to use.
- Define a site (if not using an existing site).
- Deploy the Horizon Edge.
Steps 2 and 3 can also be done as part of the Horizon Edge deployment wizard.
Note: Before deploying a Horizon Edge, you should configure identity management, including domain information, and single-sign-on configuration (if being used). See Identity Management for an overview of the process.
Certificates
When deploying a Horizon Edge, you need to supply a TLS/SSL certificate. The certificate is applied to the Unified Access Gateways when the Horizon Edge deploys them.
The certificate can be in either PEM or PFX format. The certificate should match the FQDN of the Unified Access Gateway as defined when deploying the Horizon Edge.
DNS
Two DNS records are required as part of the Horizon Edge deployment. One facilitates user connections and a second is used as part of the single sign-on configuration.
Load Balancer for Unified Access Gateways
To allow user connections to resources, you need to create a DNS record to the load balanced FQDN of the Unified Access Gateways.
Create a DNS record for the load balanced address of the Unified Access Gateways.
- The name should match Unified Access Gateway FQDN.
- The IP address is the load balancer IP in the Unified Access Gateway section.
- You should create a DNS record in your external DNS. If you use split DNS (where the internal domain name matches the internal domain name, also create a record in your internal DNS system).
The Unified Access Gateway FQDN and load balancer IP address are listed in the Horizon Edge detail which can be found in Resources > Capacity, clicking on the name of the Horizon Edge, and then within the Unified Access Gateway section.
Horizon Edge Gateway
As part of the single sign-on (SSO) configuration, you must set up a DNS record for the Horizon Edge gateway service. Desktops should be able to resolve the FQDN of the Horizon Edge Gateway to the IP address allocated to it in the Management subnet of the VNet used for deployment.
Create a DNS record for the Horizon Edge Gateway service.
- The name should match the Horizon Edge Services FQDN.
- The IP address is the load balancer IP in the Horizon Edge Gateway section.
- Create this DNS record in your internal DNS or the DNS system the desktops use for their DNS lookups.
The Horizon Edge Services FQDN and Load Balancer IP address are listed in the Horizon Edge detail which can be found in Resources > Capacity, clicking on the name of the Horizon Edge and then within the Horizon Edge Gateway section.
Providers
Providers are VMware-supported hypervisors and cloud platforms that provide the necessary resource capacity to deliver desktops and applications to end users. A single provider should have infrastructure sourced from a single physical location or data center.
There are two different types of providers:
- Primary Provider – The provider that contains the Horizon Edge deployment (Horizon Edge Gateway & Unified Access Gateways). The primary provider can be dedicated to the Horizon Edge and Unified Access Gateways or can also contain virtual desktops and shared hosts for published applications.
- Secondary Provider - Additional providers are used to expand a Horizon Edge beyond the number of VMs supported by the primary provider. You can add up to three secondary providers to a single Horizon Edge. See Single Horizon Edge Scaling. Secondary providers can be either added to a Horizon Edge during deployment or added later.
Each Horizon Edge must be configured to use a provider. Only one Horizon Edge can be deployed per provider.
Note: Currently, only Microsoft Azure-based providers are supported.
Using Azure Subscriptions as Provider
A Microsoft Azure subscription is the base unit of provider capacity for providers using Native Microsoft Azure IaaS infrastructure.
You must supply the following information:
- Subscription ID
- Azure Cloud Type (Commercial / Government)
- Azure Region
- Directory ID – Unique Azure Active Directory Identifier for your Azure Subscription
- Service Principal – See Azure Service Principals
It is advised to use a new subscription for the Edge deployment. This approach means that the Azure Service Principals and Azure Subscriptions Configuration Maximums are dedicated to Horizon Edge and resources not potentially consumed by other workloads.
Table 3: Azure Subscription Design Decision
| Decision | A new Azure Subscription was used. | |
| Justification | This allowed the subscription to be dedicated to the Horizon Edge deployment. | |
Azure Subscriptions Configuration Maximums
A Microsoft Azure 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 – next-gen 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.
Note: You might need to request increases in quota allotment for your subscription in any given Microsoft Azure region to accommodate your design.
Azure Service Principals
An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level.
You can supply multiple Service Principals for each Microsoft Azure subscription. Each Service Principal is rate limited at executing API calls (1250 calls per hour) on behalf of the owner of the Subscription. To accommodate deployments of greater than 1,000 VMs in a single provider, you need to supply four additional Service Principals, for a maximum of 5,000 VMs or users per Native Microsoft Azure Subscription.
See Create a Service Principal for the Microsoft Azure Subscription and Use the portal to create an Azure AD application and service principal that can access resources.
Azure Managed Identities
Managed identities for Azure resources can be used to get an Azure Active Directory (Azure AD) token for services. The services can use the token when accessing resources that support Azure AD authentication. For more information, see What are managed identities for Azure resources?
A User-assigned Managed Identity is used when deploying the Edge Gateway components of a Horizon Edge. Before deploying a Horizon Edge to a subscription, you must setup a User-assigned Managed Identity in that subscription using the process outlined in Manage user-assigned managed identities.
The User-assigned Managed Identity requires the following roles assigned:
- Network Contributor role at the management VNet’s resource group scope
- Managed Identity Operator role at the Microsoft Azure subscription scope.
Azure Regions
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 next-gen. 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 4: Implementation Strategy for Microsoft Azure Region
| Decision | Azure region East US was used. |
| Justification | Our current on-premises data center is in Atlanta, GA (USA). The East US Azure regional data center is roughly between 300 and 350 miles from Atlanta and provides relatively low-latency connections (< 30 ms) to the Atlanta area. For more information, see: |
Azure Provider Networking
A Microsoft Azure Virtual Network (VNet) is required for each Horizon Edge. In the primary provider for each Horizon Edge, the VNet should contain at least three different subnets for management components of the service, a DMZ, and desktop capacity.
These subnets are used for the Horizon Gateway Appliances and customer-managed workload. Network security group (NSG’s) policies are applied on the VNet, to allow and disallow traffic in and out of that VNet and to segregate that network into subnets.
Figure 8: Primary Provider VNet Subnets
For each provider, you can select which VNets and subnets are allowed to be used for desktop capacity. You can deploy desktops to other VNets and subnets onto different VNets / subnets. If you are using multiple VNets, you need to set up virtual networking peering between the VNets in use. See Virtual network peering.
Table 5: Implementation Strategy for Microsoft Azure Networking
| Decision | A VNet was configured in the resource group for the chosen Azure region. Three subnets were defined on this VNet. |
| Justification | A VNet with three subnets is required in the target resource provider for a Horizon Edge deployment. |
To facilitate the deployment of a Horizon Edge Gateway, a NAT gateway is required in the management subnet of the Azure primary provider. This is required for outbound connectivity from the Horizon Edge Gateway components. See the Networking Requirements section of VMware Horizon Cloud Service on Microsoft Azure Requirements Checklist For New Deployments.
Table 6: NAT Gateway Strategy for Microsoft Azure Networking
| Decision | A NAT Gateway was created on the management subnet of the VNet of the primary Azure provider. |
| Justification | A NAT Gateway is required on a management subnet of the primary provider to allow outbound communication from the Horizon Edge Gateway components. |
Inter-Provider Networking
With a basic Horizon Cloud Service – next-gen deployment, all components, including desktops, are deployed into the same Microsoft Azure VNet which is in a single subscription. When scaling a Horizon Edge you can add additional providers, as covered in the Scaling and Availability section of this guide.
When adding additional Azure-based providers, each provider will use a separate VNet. To facilitate traffic flow, you will need to connect the VNets with virtual network peering. See Virtual network peering.
Preparing Microsoft Azure
To deploy a Horizon Edge to a Microsoft Azure provider, the Azure subscription must first be prepared.
Figure 9: Preparing Azure for a Horizon Edge Deployment
To prepare an Azure subscription for a new Horizon Edge deployment:
- Obtain an Azure subscription with suitable capacity.
- Set up an identity provider - See Setting Up Your Identity Provider.
- Either Microsoft Azure Active Directory or VMware Workspace ONE Access
- Microsoft Azure Active Directory (Azure AD)
- Install Azure AD Connect on an on-premises active directory server to link Microsoft Azure AD. See Integrate on-premises AD domains with Azure AD.
- VMware Workspace ONE Access
- Configure user attributes.
- Enable the people search feature in Workspace ONE Access.
- Create Active Directory domain bind and domain join accounts. A main account and an auxiliary are required for each of these.
- Create a Resource Group in the target Azure region – See Manage Azure resource groups by using the Azure portal.
- Configure Networking – See the Networking Requirements section of VMware Horizon Cloud Service on Microsoft Azure Requirements Checklist For New Deployments and Configure the Network Requirements.
- Setup a new VNet or configure an existing VNet to be used for the Horizon Edge deployment.
- Define subnets for DMZ, management, and desktop VMs.
- Add NAT Gateway to the management subnet. The Horizon Edge Gateway needs a NAT Gateway for outbound connectivity. For guidance on creating an Azure NAT Gateway, see Quickstart: Create a NAT gateway using the Azure portal.
- Configure any required virtual network peering between VNets. For example, between the target VNet and other VNets that contain supporting infrastructure such as Active Directory domain controllers, or DNS servers.
- Create Service Principal and User-assigned Managed Identity
- Add a Service Principal for the Azure subscription – Service Principals can be defined using the Azure Portal in Azure Active Directory > App registrations. See the Azure Service Principals section and Create a Service Principal for the Microsoft Azure Subscription for more information and the process.
- Add a User-assigned Managed Identity to the Azure subscription. See the Azure Managed Identities section and Manage user-assigned managed identities for more information and the process.
Identity Management
The Horizon Cloud Service – next-gen platform separates the user identity component of the service from the machine identity. This separation allows you to choose different kinds of identity solutions that you want to use with Horizon Cloud Service and ensures that the platform remains secure and functional.
User Identity
Horizon Cloud Service – next-gen relies on an external identity provider (IdP) to perform the authentication required when users attempt to access their desktops and published applications. A trust is set up between Horizon Cloud Service – next-gen and the identity provider to allow that authentication token to be used for platform authorization.
The use of an external IdP allows for integration with third-party products and solutions to provide multi-factor authentication (MFA) and SSO capabilities. It also ensures that user credentials are not managed within the Horizon Cloud Service.
You can leverage Azure Active Directory or Workspace ONE Access as your user identity provider. For both, you must connect an Active Directory domain to the external identity provider. For more information, see Setting Up Your Identity Provider.
The service uses the OpenID Connect Protocol, which is built as an identity layer on top of an OAuth 2.0 foundation. OpenID Connect allows applications to verify the identity of a user by trusting the authentication performed by a separate Authorization Server. Using this protocol, the Horizon Cloud Service can receive basic information about the individual user along with the authentication token. This allows the service to authenticate access for end users without needing to store, manage or even be aware of passwords or other secrets used to achieve the authorization.
End users access Horizon Cloud Service – next-gen via either a Horizon Client or a browser. A user’s authentication to the service is currently accomplished only through a web browser. If the end user attempts to access Horizon Cloud Service – next-gen with a Horizon Client, the default web browser configured for the machine will be launched and used to authenticate the end user to the IdP.
Machine Identity
Managing many Windows machines can be burdensome. Windows Machines can be joined to a directory so that they can be manageable objects within a single directory. In other words, it allows you to entitle users, which in this context are objects in the same or a trusted directory, to leverage only the computers or endpoints that they are allowed to use. This enables the directory to manage users across numerous machines.
Once the user has been verified and authenticated into the Horizon Service, the user selects a resource from a list of resources that they are entitled to use. In most cases, the target resource will be a virtual machine running the Microsoft Windows operating system. Windows-based operating systems require users to log on to the computer with a valid account to access local and network resources. Windows-based computers secure resources by implementing the logon process, in which users are authenticated.
Horizon Cloud Service – next-gen provides a mechanism for a user to accomplish this sign-in automatically using the authorization granted when the user initially logged into the service. The single sign-on component for the service runs in the Horizon Edge Gateway Appliance. The single sign-on component is a Certificate Authority that has a trust relationship configured with a Microsoft Active Directory.
Since the user has already been verified and granted authorization to the service via the IdP, the Horizon Cloud Service uses the token granted as a part of user authentication to request a certificate from the CA that is built-in to the Horizon Edge Gateway Appliance. Since that CA has a trust relationship with a configured Active Directory, the Active Directory accepts an authenticated certificate from CA as a means for authenticating the user on behalf of the service and initiating the Windows login service. This allows the resource to be available for the user to use as soon as the login process has completed.
Single Sign-on for Users with Horizon Cloud Service – next-gen
Horizon Cloud Service – next-gen provides a feature that allows end users a single sign-on experience to access the resources provided by the service. Enabling this feature allows the user to authenticate once and gain access to an appropriate resource without needing to authenticate again.
There are two major components (flows) of the end-user single sign-on feature in Horizon Cloud Service – next-gen. The first is when a user authenticates to the service via an Identity Provider. The second is when the authenticated user is directed to a virtual desktop, application or workspace, and the user is automatically logged in to Active Directory. The service uses trust-based certificates to authenticate the user into a virtual machine.
End User Sign-In Process for Horizon Cloud Service – next-gen
The diagram below describes a login for an End User of Horizon Cloud Service – next-gen leveraging the service’s brokering mechanism. Currently, this brokering mechanism is only used for native Microsoft Azure workloads. An explanation of each step in the process follows the diagram.
Note: Horizon 7 or Horizon 8 environments leverage a different mechanism to log in to gain access to resources. For more information on the login flow for Horizon 7 and Horizon 8 environments, see the Authentication section of the Horizon Reference Architecture.
Figure 10: End User Sign-In Process Diagram
- From Horizon Client, the user authenticates, using an Internet browser, on Workspace ONE Access or Azure AD and receives an access token.
- The user launches the Horizon resource from Horizon Client. Horizon Control Plane generates and signs a token (desktop token) that includes the user and desktop details. The token is used by Horizon Control Plane to start brokering the desktop session.
- Horizon Control Plane interacts with Horizon Agent to start a session.
- Horizon Agent replies with the session details and data required for SSO (certificate signing request and request ID).
- Horizon Control Plane generates and signs a new token that includes the initial token from step 1 and SSO request data sent by the agent. The new token is sent to Horizon Agent.
- Horizon Agent receives and uses the token to call Edge Gateway (Auth Engine) to request a logon certificate.
- Auth Engine validates the token, extracts the CSR, signs it using Horizon Signing CA, and returns a short-lived logon certificate.
- Horizon Agent presents the certificate to the Windows Operating System, and Windows validates the authenticity of the certificate with Active Directory.
- The user is logged onto the Windows desktop or application, and a remote session is initiated on the Horizon Client (this step happens in parallel with steps 5, 6, 7, and 8).
Explanation of Trust Relationships between Horizon Cloud Service – next-gen and other components
The user login flow is explained in the previous section but for clarity’s sake, we have drawn a diagram that also includes the trust relationship details between Horizon Cloud Service – next-gen and other components.
These trusts may be configured with the Horizon Cloud Control Plane during initial setup (IdP binding) or during Horizon Edge Gateway configuration (SSO information). Tokens or certificates are used to prove trust between resources during user logins, but the trusts are configured ahead of time. These trusts do not require communication flows between objects, in fact, they enable the user login process to be seamless and secure.
Figure 11: Single Sign-on trust diagram
Configuring Single Sign-On
To enable a single sign-on experience for your users, you can add SSO configuration to be deployed on the Horizon Edge Gateway. This process sets up the required trust relationship to allow users to authenticate once in the Horizon Cloud service and then get automatically logged into their desktop or applications without having to enter their credentials a second time at the resource.
To set up SSO, the following steps must be completed.
- Create an SSO Configuration. See Adding SSO Configuration.
- Ensure that the active directory domains, that you intend to use for desktops, are defined in the Universal Console and have the SSO configuration selected.
- Install and configure the Certificate Authority (CA) role on a Domain Controller. See Install the Certification Authority.
- Download the CA bundle for the SSO Configuration and install it on the domain controller by running the included PowerShell script.
- Add an internal DNS record for the management interface of the Horizon Edge Gateway service and ensure that desktops can resolve this FQDN to the correct IP address. See DNS for more information.
- When defining a pool, select the option to use SSO.
Table 7: SSO Strategy
| Decision | Single sign-on was configured. |
| Justification | Using SSO prevents users from being challenged for their credentials again when they launch a desktop or application. |
Configuring Identity Management
As Horizon Cloud Service – next-gen platform separates the user identity component of the service from the machine identity you need to configure both.
- User identity - Horizon Cloud Service -next-gen relies on an external user identity provider and currently supports Microsoft Azure Active Directory and VMware Workspace ONE Access.
- Machine identity - Horizon Cloud Service - next-gen currently supports Microsoft Active Directory.
The machine identity provider you configure with Horizon Cloud performs the authentication required when users attempt to access their desktops.
When using either Microsoft Azure Active Directory or Workspace ONE Access for user identity, you must connect an Active Directory to the external identity provider for the purposes of Machine Identity.
Configuring an IdP for User Identity
As a part of the onboarding process, Horizon Cloud Service – next-gen requires you to configure a trust with an Identity Provider (IdP) to provide authentication services for that customer tenant. You can choose to leverage Workspace ONE Access or Microsoft Azure Active Directory as your IdP. More IdP options may be available in future releases.
Figure 12: Identity Management Setup
To configure Identity Management:
- Define at least one active directory domain and the associated domain bind and join account information.
- Add SSO configuration (optional) – See Adding SSO Configuration.
- Connect to the chosen identity provider. See Connecting your Identity Provider.
You can now proceed with deploying Horizon Edges. For an overview of that process, see Horizon Edge.
Table 8: Identity Management Strategy
| Decision | Workspace ONE Access was used as the identity provider. |
| Justification | Workspace ONE Access was already in place, used for other Horizon deployments with Workspace ONE Access connectors already connecting to Active Directory. |
Configuring Active Directory for Machine Identity
Active Directory is required for machine identity and must also be connected to the chosen user identity provider.
Use one of the following supported Active Directory configurations.
- Active Directory (often referred to as on-premises Active Directory)
- Domain controllers require line-of-sight to the Horizon Edge Gateways and desktop subnets.
- For example, on-premises domain controllers connected via VPN or Express Route, or domain controllers located in Microsoft Azure.
- Microsoft Azure Active Directory Domain Services
Table 9: Active Directory Strategy
| Decision | Active Directory was used. Domain controllers were located in Azure in the same region as the Horizon Edge. |
| Justification | Active Directory was already in place and synchronizing to Workspace ONE Access. Locating domain controllers in Azure and the same region reduces latency and dependency on WAN links to other locations. |
Scaling and Availability
A design should take into consideration how to increase in scale to address an increase in demand and more users when needed. This should be achieved without requiring a complete redesign of the environment. The initial design should be able to be easily grown, added to, and amended to cope with an increase in demand.
As the Horizon Edge deployment is made to Microsoft Azure, design decisions must be made with respect to some Microsoft Azure providers and subscription limitations. Scaling past those limitations can be achieved by:
- Scaling out an individual Horizon Edge by:
- Adding additional Service Principals to support more VMs
- Adding extra resource capacity with secondary providers
- Deploying multiple Horizon Edges to the same site
- Deploying Horizon Edges into other sites
Single Horizon Edge Overview
A single Horizon Edge consists of one Horizon Edge Deployment (Horizon Edge Gateway and Unified Access Gateway).
A Horizon Edge consumes resources from one primary resource provider and, optionally, some secondary resource providers. All the resource providers for a Horizon Edge should come from one physical location or site.
Figure 13: Horizon Cloud Service – next-gen Logical Architecture
User Capacity
Blocks of capacity, for desktop and application pools, can be formed from user capacity from the registered providers. A block is made up of a single provider.
This can be either:
- The primary provider if this is the first block in the site.
- A secondary provider, to add more capacity to the site.
All blocks must use the same provider type, that is, a similar hypervisor and platform capacity.
Single Horizon Edge Scaling
A Horizon Edge usually has initial user capacity from the primary provider where the Horizon Edge was deployed. A single provider has the constraints on Azure subscription maximums and VMs per Service Principal. See Azure Subscriptions Configuration Maximums and Azure Service Principals.
Figure 14: Scaling Out a Horizon Edge with Secondary Providers
Additional secondary providers, using either the same or a different Azure subscription, can be added to provide extra user capacity to a Horizon Edge. You can add up to three secondary providers to a single Horizon Edge.
- Each secondary provider that you add to a Horizon Edge requires a VNet with subnets for desktops.
- VNet peering is required between the secondary provider VNet and the primary provider VNet of the Horizon Edge.
- The secondary provider VNet requires line of sight to the Active Directory domain controllers and the DNS servers.
Additional service principals can be added to increase the number of VMs supported. A maximum of five service principals are supported per provider.
- When adding additional Azure service principals to a Horizon Edge, they must have read access to the Azure subscription being used for the primary provider. See Service principal requirements in Horizon Image Management Service System Requirement.
- This can be achieved by adding the additional service principals to the primary subscription with either the contributor role, or with a custom role with appropriate permissions. See Assign Azure roles using the Azure portal.
Table 10: Microsoft Azure Subscription Strategy
| Decision | Two Microsoft Azure subscriptions were used. |
| Justification | The first Azure subscription was used to provision a primary resource provider into which a Horizon Edge was deployed. The second subscription was used to provision a secondary resource provider, which was used to expand the Horizon Edge with additional capacity. |
Table 11: Microsoft Azure Service Principal Strategy
| Decision | Two service principals were used. |
| Justification | At least one service principal is required for each subscription. The scale of the environment only required one service principal per subscription. |
Single Site Scaling
You can also deploy multiple Horizon Edges into a single site or region. Each Horizon Edge requires a separate resource provider.
Figure 15: Deploying Multiple Horizon Edges per Site
Multiple Sites
You can deploy Horizon Edges to multiple sites and manage them all through the Horizon Universal Console.
Figure 16: Multiple Site Deployments
Desktops and Apps
After a Horizon Edge has been deployed, you can import images, use them to create pools, pool groups, and entitle users to desktops and applications.
Figure 17: Import Images, Add Pools, Add Pool Groups, and Entitle Users
The process involves the following steps:
- Import a virtual machine (VM) image. This image becomes a golden virtual machine image that is used to create individual VM clones.
- Publish the image to the Horizon Edges that you want to use it on.
- Create a pool to use the published image.
- Create a pool group to apply policy to the consumption of one or more pools.
- Entitle users to allow access to the resources.
Image
A virtual machine image can be imported from the Microsoft Azure Marketplace, the Microsoft Azure Compute Gallery, or from a Microsoft Azure Custom VM. After it is imported, you can remotely connect to the image and make changes such as installing applications.
When an image is ready to use you publish it to the Horizon Edges where you want to use it. Publishing an image to a Horizon Edge copies the image to each provider in that edge making it available for use in creating pools of virtual machines on that edge, and in any provider capacity assigned to that edge.
As part of the publishing process, the various agents (Horizon Agent, Dynamic Environment Manager FlexEngine, and App Volumes agent) are installed and configured using the selections you make.
If you publish an image to a Horizon Edge and then add additional secondary providers, you will need to republish the image. This ensures it is copied to the new providers before you can create a pool in those new providers.
Pool
A pool uses a published image to create a collection of virtual machines within the selected provider. A pool can be either single-session or multi-session, depending upon the type of published image used for its creation. Single-session pools can be either dedicated or floating. With dedicated, each user is assigned a particular virtual desktop and returns to the same desktop at each login. With floating, a user is assigned a random desktop each time they log in, with the desktop being regenerated and returned to the available pool, on user logoff.
Table 12: Pool Settings
| Component | Settings |
| Destination | Site – Select the site which you want this pool to be associated with. Horizon Edge – Select the Horizon Edge. This list will be populated with the Horizon Edges associated with the chosen site. Provider – Select the provider to use. |
| Image | Generation type – V1 or V2 Image – Select an image that has previously been published to the Horizon Edge being used. The capabilities of the image must match the type of pool being created (i.e., single-session or multi-session). Marker – Select which marker on the image to use. Version – Select the desired version of the published image to use. Windows license – Confirm that you have eligible Windows licensing. |
| VM Details | Model – Choose the VM model to use. Disk type - Select a supported disk type from the available options. Disk type options are based on the VM model selected, and the Microsoft Azure subscription and region. Disk size – Size of disk in GB Encrypt disks – Choose whether hard disks should be encrypted or not. |
| Domain | Domain - Select the active directory domain to use. Computer OU – Define the Active directory organization unit (OU) where the computer objects should be created. This is the distinguished name of the target OU. |
| Provisioning | Provision VMs on-demand or all at once – Choose whether the total number of VMs defined should be created when the wizard completes, or on-demand, as they are needed by users. Minimum provisioned VMs - The minimum number of spare VMs. Must be less than or equal to maximum VMs to avoid frequent capacity updates. Only applicable if provisioning VMs on demand. Maximum provisioned VMs - The maximum number of spare VMs. Must be greater than or equal to minimum VMs to avoid frequent capacity updates. Only applicable if provisioning VMs on demand. Total VMs - The maximum number of VMs that can be provisioned. Sessions per VM – For multi-session pools, set the total number of sessions to allow per virtual machine. |
| Properties | VM name prefix – Define a prefix for the VMs and the computer objects that will be created. Desktop admin username - Create a username for the local admin account to access the image's operating system, and to use during the image conversion process. Desktop admin password – Define the password to set for the desktop admin account. Outbound proxy – Choose whether to route outbound requests to the Internet through a proxy server. If selected define the proxy host, port, and any IP addresses that should bypass the proxy. |
| Networks | Select which VNets and subnets to create this pool in. Note that after the pool is saved, the networks cannot be edited or changed. |
| VMware Dynamic Environment Manager | When defining a pool, you can optionally select a VMware Dynamic Environment Manager configuration that you have previously defined. See Dynamic Environment Manager. |
For more information, see Create a Pool.
Pool Group
A pool group collects together one or more pools. This allows:
- A common set of policies to be applied to the pools that define how users will consume the resources of the pools.
- Users to be entitled to resources in the pool group and therefore consume resources from the pools that are members of that pool group.
The pools consumed by a pool group can be from any provider. A pool can only be consumed by one pool group. A pool group can be either a single-session or multi-session pool group and will consume pools of the same type that you have previously created. With multi-session pools, you can publish desktops, publish applications, or publish both the applications and desktops.
The policies that you define on a pool group include the following.
Table 13: Pool Group Policies
| Component | Policies |
| Client | Default protocol – Select the default protocol for end-user sessions. Currently, only Blast Extreme is supported. You can also select whether to Allow users to select protocol. Allow users to select protocol Preferred client type – Select whether to launch assignments in Horizon Client or a browser. |
| Brokering | Scope – Select whether to search for available desktops on any site or only within the end-user's site. Site connection affinity – Select the default site that end users will connect to. Options are Nearest Site or Home Site. Home site restriction – Restrict users to accessing the assignment only through the assignment home site override, or through the user's home site if an override is not designated. If not selected, the nearest site will be used. Only selectable when site connection affinity is set to Home Site. |
| SSO (Single sign-on) | Use SSO – Defines whether to use SSO for the pool. To enable SSO for the pool, SSO must be enabled on the Horizon Edge Gateway and SSO configuration set up as detailed in Single Sign-On. |
| Power Management | Minimum VMs - The minimum percentage of VMs to keep powered on relative to the total VMs in a pool at any point in time. Power management mode – Select the threshold of virtual machine utilization for this assignment at which a new virtual machine is spun up and drained respectively. Choose from Optimized for performance, Balanced, or Optimized for cost. This setting is only available for a multi-session pool.
Power off protect time - Enter the number of minutes (from 1 to 60) a VM is protected from powering off after powering on due to a headroom error. The default is 30. Power management schedule – Optionally, set up a schedule for power management. |
For more information, see Create a Single-Session Pool and Create a Multi-Session Pool.
Entitlement
Users and groups are entitled to use pool groups. An entitlement is for a desktop session and/or published applications in the pool group, which will allow consumption of resources from the pools that are members of the pool group.
To entitle users or groups of users see Desktops and Applications.
Dynamic Environment Manager
Dynamic Environment Manager offers personalization and dynamic policy configuration for end-user desktops and applications.
- Install and configure Dynamic Environment Manager to a file share – See the deployment guidance in the Dynamic Environment Manager Activity Path.
- Add a Dynamic Environment Manager Configuration – See Configuring VMware Dynamic Environment Manager.
- Select the Dynamic Environment Manager Configuration when defining the Pool – See Create a Pool.
For more guidance on architecting Dynamic Environment Manager, see Dynamic Environment Manager Architecture. For guidance on configuring Dynamic Environment Manager, see Dynamic Environment Manager Configuration.
Launching a Desktop or Application
To launch a desktop or application:
- Open a web browser and connect to https://cloud.vmwarehorizon.com.
- Enter the company domain to authenticate to.
- You will be redirected to the integrated identity provider to authenticate.
- The desktops and applications that you are entitled to will be presented.
- Click the desired desktop or app to launch it. You can also click the three dots or right-click to select whether to launch it in the browser or with the Horizon Client (if installed).
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.
Associated Content
From the action bar MORE button.