Horizon Cloud Service - next-gen Architecture

This chapter is one of a series that make up the Omnissa Workspace ONE and Horizon Reference Architecture, a framework that provides guidance on the architecture, design considerations, and deployment of Omnissa Workspace ONE and Omnissa Horizon solutions. This chapter provides information about architecting Omnissa Horizon Cloud Service - next-gen to use capacity in the supported capacity providers. A companion chapter, Horizon Cloud Service - next-gen Configuration, provides information about common configuration and deployment tasks.

Introduction

Omnissa 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 Omnissa Horizon Control Plane, from the resource capacity, which is delivered by supported capacity providers.

Table 1: Horizon Cloud Service next-gen Setup Strategy

Architectural Overview

A successful deployment of Omnissa 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 of the Horizon Cloud Service – next-gen that you will need to understand.

Figure 1: Horizon Cloud Service next-gen Overview

The Horizon Cloud Service is divided into two parts: the Cloud and the Edge. The Cloud components are hosted in the Horizon Cloud Service and the Edge component is hosted in a customer’s infrastructure. Horizon Cloud Service – next-gen includes the following components and features.

Table 2: Components of Horizon Cloud Service - next-gen

Horizon Control Plane

The Omnissa 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 2: 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.

With Horizon Cloud Service - next-gen, the Horizon Control Plane includes end-user services, such as:

• Licensing
• Identity and Access Management
• Session Brokering
• Monitoring and Analytics Service
• Image Management Service

The capabilities of, or access to, each feature may be different based on the capacity provider being used. Refer to the product documentation for each feature listed previously for details on the platforms each feature serves. You can find relevant terms and conditions regarding Workspace ONE Cloud, and Horizon Cloud services in the  Omnissa Contract Center. 

Access to the Next-Gen Horizon Control Plane requires the use of a subscription license for your Horizon deployment. The Horizon universal license entitles you to any version of Horizon that you want through a single subscription entitlement. For more information, see the Compare tab titled Horizon Subscription SaaS on the  Horizon 8 page.

Horizon Universal Console

All of the services and functions provided by the Horizon Cloud Service – next-gen are managed through the Omnissa Horizon Universal Console. Functions managed by the Universal Console include:

• Manage capacity – Add and manage capacity and Horizon Edge deployments
• Customer onboarding – Allow customers to choose where they want to store their metadata while onboarding to the service
• Role-based access control – Assign predefined roles to administrator users and groups
• Search – Search for users, and review their assigned desktops, applications, active sessions and entitlements
• Monitoring – Access dashboards powered by Workspace ONE Intelligence to monitor usage and health metrics for all core components and services
• Audit and logging – Export audit and system activity with support for third-party SIEM systems

To access the Horizon Universal Console, you first authenticate to Omnissa Connect and then launch services you are entitled to. To access the Horizon Universal Console, launch the Workspace ONE service, and from the console that opens, launch the Horizon Cloud Service.

Figure 3: Accessing the Omnissa Horizon Universal Console

For more information, see Onboarding for Horizon Cloud Service - next-gen Administrators.

You can create Horizon Cloud administrative users and assign them roles following the guidance in Assigning Administrative Roles to Horizon Universal Console Users.

Capacity Providers

Providers are -supported hypervisors and cloud platforms that provide the necessary resource capacity to deliver desktops and applications to end users. Each individual provider of capacity should have infrastructure sourced from a single physical location or data center.

There are different types of providers:

• Cloud-native Provider
  • Capacity provided by a Cloud Infrastructure as a Service (IaaS) platform
  • Supports Horizon Control Plane a pushed Horizon Edge Deployments
• Data Center Provider
  • Allows existing Omnissa Horizon 8 deployments, such as Horizon 8 pods, to connect to Horizon Cloud and utilize Horizon Control Plane services
  • Horizon 8 running on-premises or in a vSphere-based SDDC cloud platform

The following providers are currently supported:

Table 3: Capacity Providers

Cloud-native Provider Capacity

With cloud-native providers, the capacity provided can be categorized into two tiers.

• Primary Provider – The provider that contains the Horizon Edge deployment (Horizon Edge Gateway and 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 secondary providers are used to expand a Horizon Edge beyond the number of VMs supported by the primary provider. Secondary providers can be either added to a Horizon Edge during deployment or added later. See Single Horizon Edge Scaling for more information.

Each Horizon Edge must be configured to use a provider and only one Horizon Edge can be deployed per provider.

Data Center Provider Capacity

With a data center-based provider, the capacity is attached to the Horizon Cloud Service via a Horizon Edge Gateway Appliance.

In the case of a Horizon 8 provider, the capacity is a single vSphere-based Horizon 8 pod. The vSphere environment could be running on-premises or in a vSphere-based SDDC cloud platform.

Data center provider capacity types include:

• Private data center
• Microsoft Azure
• Amazon Web Services
• Google Cloud
• Oracle Cloud
• Alibaba Cloud
• Dell EMC Cloud

Depending on the infrastructure type, the end-user applications and virtual machines may be able to take advantage of different components of the Horizon Cloud Service. The feature set of components that Horizon 8 pods can leverage from the service is dependent on the subscription entitlement that you have for Horizon. For more information, see Horizon 8 Provider.

Horizon Edge

A Horizon Edge defines an instance of Horizon capacity as registered in the Horizon Control Plane. It is based in a single physical location or region and can be divided into multiple blocks to provide scalability.

There are different implementations of a Horizon Edge, depending on what type of capacity provider is being used for the instance.

• Omnissa Horizon Cloud Service
  • A Horizon Edge Deployment is pushed into the customer’s resource capacity in a supported cloud-native provider in a specified primary provider in a selected site.
  • A Horizon Edge deployment uses a thin edge infrastructure and consists of a Horizon Edge Gateway, Unified Access Gateways, and load balancers.
  • Networking inside the infrastructure provider is required to allow the components to properly communicate.
  • This allows the consumption of the cloud-native infrastructure for delivery of desktops and apps. User capacity, within the provider, can 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 Capacity Provider for more information.
• Omnissa Horizon 8
  • Connects a Horizon 8 pod to Horizon Cloud Service – next-gen services.
  • A Horizon Edge Gateway appliance is manually deployed to register an existing Horizon 8 pod.
  • For more information on Horizon 8 pods in Horizon Cloud Service – next-gen, see Horizon 8 Provider.

The remainder of this section deals with the architecture of the Horizon Cloud Service implementation of a Horizon Edge when deployed into a supported cloud-native provider, such as a Microsoft Azure Provider.

Figure 4: Horizon Edge Logical Architecture Overview

Table 4: Components for a Horizon Cloud Service Implementation of Horizon Edge

Horizon Edge Deployment

An Omnissa Horizon Edge deployment is created on your behalf in the provider that you have registered and chosen for the Horizon Edge.

• For Azure, 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
• Load balancing for the Unified Access Gateways

Figure 5: Horizon Edge Deployment

Horizon Edge Gateway

The Omnissa 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

Omnissa 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 are deployed as passthrough appliances, with minimal policy or configuration implemented in the appliances in a Horizon Edge Deployment. The Unified Access Gateways are considered part of the Horizon Cloud Service and are managed by the service provider. Automated updates are provided as a part of the service.

Unified Access Gateways Deployment Types

With Unified Access Gateway deployments on a cloud-native provider, there are three end-user connection configurations to choose from.

• Internal – Typically used if you want your users to connect to virtual desktops and published applications via intranet (internal corporate network) only.
• External - Users connect to their virtual desktops and published applications via the Internet. A layer 4 load balancer is deployed with a public IP to facilitate inbound access.
• Internal and External – Allows both internal and external user access.
  • Typically, this requires the configuration of split-horizon DNS so that users can access virtual desktops and published applications appropriately.
  • The external load balancer’s front-end IP address can either be automatically assigned or manually configured.
  • This type of deployment allows a third-party Network Virtual Appliance (NVA) to be placed in front of the Unified Access Gateways to allow traffic inspection.
  • This configuration supports a hub and spoke network architecture.

Unified Access Gateways on Microsoft Azure Deployments

When deployed into a Microsoft Azure provider, 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.

For Horizon Edge deployments in cloud-native capacity providers, such as Microsoft Azure, an initial two Unified Access Gateways are deployed.  More Unified Access Gateways can be added to support a greater number of concurrent user connections, up to the limits of a single Horizon Edge deployment. See Scaling and Availability for more information.

More information on user connection options see Add and Deploy a Microsoft Azure Edge.

Horizon Edge Deployment Networking

A Horizon Edge deployment relies on a network location to deploy the Horizon Edge onto. The network location must be segregated into multiple subnets, used to segregate resources from each other.

Ensure that there are 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. See Configure Network Settings for Microsoft Azure Regions for details on IP address space details.

Figure 6: Horizon Edge Deployment Networking

Networking with Microsoft Azure Deployments

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.

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.

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.

Figure 7: Horizon Edge Connectivity

Connectivity with Microsoft Azure Deployments

When deploying into an Azure provider, Horizon Agents can connect to the Horizon Control Plane with:

• Azure Private Link (internal)
• Internet – The simplest method of connecting Horizon Agents to the Horizon Control Plane.

In both configurations, a single VNet is used for each Horizon Edge.    More details can be found in the Fleet Management section.

Microsoft Azure Provider

A Microsoft Azure subscription is the base unit of a capacity provider using Native Microsoft Azure IaaS infrastructure. The Horizon Control Plane can push a deployment of a Horizon Edge into Azure capacity that you provide.

Figure 8: Horizon Edge Deployment on Microsoft Azure Provider

You must supply the following information:

• Subscription ID
• Azure Cloud Type (Commercial / Government)
• Azure Region
• Directory ID – Unique Microsoft Entra ID (Azure Active Directory) Identifier for your Azure Subscription
• Service Principal – See Azure Service Principals for more information

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 5: Azure Subscription Design Decision

Azure Preparation Resources

For configuration detail on deploying Horizon Edge to Microsoft Azure, see Preparing Microsoft Azure in Horizon Cloud Service – next-gen Configuration.

For more details on preparing Azure infrastructure for a Horizon Edge deployment, please review the Evaluation Guide for Horizon Cloud Service.

Azure Horizon Edge Deployment Considerations

There are several considerations that you need to be aware of when deploying the Horizon Edge in a Microsoft Azure provider.  A Horizon Edge Gateway can be deployed in two different configurations. 

• An Azure Kubernetes Cluster - In this configuration the Kubernetes kubes are configured to be highly available.  See Azure Kubernetes Service for more information.
• A single Microsoft Azure virtual machine - In this configuration, there is no high-availability configuration available with this deployment configuration.  Availability is reliant on Microsoft Azure’s SLA for virtual machines.  Also, If the Horizon Edge Gateway is unavailable, users of the service will not be able to use Single Sign-on capabilities, and monitoring and performance data will not be sent to any monitoring solution.

See Deploying a Microsoft Azure Edge for more details on these deployment configurations.

Table 6: Implementation Strategy for Azure 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.

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 on behalf of the owner of the Subscription. For more information, see the values for Write API calls and Read API calls in Azure Data Factory limits in the Azure documentation Subscription and service limits.

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. For more information, 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.

Note: Be careful when applying templates (for example: Azure Policy Templates) that may affect the ability of the Service Principal or other platform components from behaving in a manner that would prohibit the Horizon Cloud Service from managing your Microsoft Azure subscription. Make sure all of the platform pre-requisites are still met when these types of policies are configured.

Azure Managed Identities

Managed identities for Azure resources can be used to get a Microsoft Entra ID (Azure Active Directory) 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 for more information.

Table 7: Implementation Strategy for Microsoft Azure Region

Azure Kubernetes Service

Horizon Edge Gateway leverages Azure Kubernetes Service (AKS) as an option to run and manage the Horizon Edge Gateway components. The Horizon Edge Gateway components are organized into an AKS cluster. The components that exist in the cluster are managed by the Horizon Service and should not be modified. You can find details on the Microsoft Azure Capacity requirements in Requirements Checklist for Deploying a Microsoft Azure Edge.

Figure 9: Kubernetes Services for the Horizon Edge Viewed in the Azure Portal

Communications to the AKS cluster is managed by a cluster Classless Inter-Domain Routing (CIDR) address, which cannot be changed after deployment of the Horizon Edge Gateway. Be aware that if you typically restrict network communications to the Horizon Edge Gateway components, the service may not operate. Make sure that the Horizon Edge Gateway has line-of-sight visibility to the appropriate ports and URL’s.

The components in the AKS cluster require a /21 range of IP addresses. Each cluster node gets pre-allocated with 256 IP addresses from this IP range. During AKS cluster upgrades, (33% of the Cluster nodes * 256) additional IP addresses are necessary to deploy updated containers for a blue-green upgrade of each resource to occur.

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 10: Azure 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 for more information.

Table 8: Implementation Strategy for Microsoft Azure Networking

To facilitate the deployment of a Horizon Edge Gateway, outbound connectivity from the Horizon Edge Gateway components, needs to be allowed. This can be achieved by one of the following methods:

• Defining a NAT gateway in the management subnet of the Azure primary provider.
• Setting up User Defined Routing (UDR) for the Azure Kubernetes Service (AKS).

Horizon Edge Gateway deployments on Azure can have a proxy configured for outbound traffic. The proxy must be reachable via the management subnet.

For more information, see the following documentation:

• The Microsoft Azure documentation, Configure outbound type for AKS.
• The Networking Requirements section of Requirements Checklist for Deploying a Microsoft Azure Edge.

Table 9: NAT Gateway Strategy for Microsoft Azure Networking

Azure Inter-Provider Networking

With the simplest installation of a Horizon Cloud Service – next-gen Edge 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. The Horizon Edge requires line-of-site to end user capacity resources to deliver monitoring data collection and SSO functionality. To facilitate traffic flow to the Horizon Edge, you will need to connect the VNets with virtual network peering. For more information, see Virtual network peering.

Azure Hub - Spoke Network Topology

Horizon Edge deployments on Microsoft Azure can accommodate a hub and spoke architecture built with Microsoft Azure Infrastructure components. Organizations typically adopt this kind of configuration to reduce the cost of infrastructure, maintain subscription limits and provide workload isolation in their environment. This allows you to adopt configurations that provide traffic inspection of traffic to and from the Horizon Edge deployment.

The external Azure Load Balancer for Unified Access Gateways can now be deployed with a private IP address. This type of deployment allows a third-party Network Virtual Appliance (NVA) to be placed in front of the Unified Access Gateways. This allows for the inspection of user session traffic to virtual desktops and applications.

The use of NVAs does not accommodate inspection of traffic from Horizon components, such as Horizon Edge Gateway and Horizon Agent, to the Horizon Cloud Service.

Figure 11: Azure Hub - Spoke Network Topology with Network Virtual Appliances for Traffic Inspection

To configure a Horizon Edge deployment for a hub - spoke architecture:

• From the Horizon Universal Console, select the Internal and External as the Access Type configuration in the Unified Access Gateway section of a Horizon Edge deployment.
• Configure a Manual Public IP address that will be assigned to the front-end IP load balancer.  This is configured on the DMZ subnet to allow an alternate route for users to access resources.
• The Access Type can be configured during the initial Horizon Edge deployment or by editing an existing Horizon Edge deployment.
• The Hub VNet can be peered to the Horizon Edge deployment VNet (i.e., the Primary Provider) using the Microsoft Azure console. This allows the routing of user traffic via a secure Hub VNet before reaching the Horizon Edge Deployment.

Note: Source IP affinity is used on the Azure Load Balancer to persist sessions from the same client through the same Unified Access Gateway. NVAs that do not support passing through the client source IP cause all traffic to be routed to a single Unified Access Gateway.

For more information see Deploying a Horizon Azure Edge.

Horizon 8 Provider

Existing Omnissa Horizon 8 pods can be added to Horizon Cloud Service – next-gen. This enables the consumption of Next-gen Horizon Control Plane services and features such as subscription licensing and, depending on your license entitlement, monitoring via Omnissa Intelligence for Horizon.

Figure 12: Horizon 8 Pod added to Horizon Cloud Service – next-gen

Horizon 8 environments are not pushed out by the Horizon Cloud Service. You need to architect and deploy the Horizon 8 environment following the design guidance in Horizon 8 Architecture.

For information on how to connect a Horizon 8 pod to Horizon Cloud Service – next-gen, see the Horizon Edge Gateway Appliance section of the Horizon 8 Architecture chapter.

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.

For current scaling numbers see the Horizon Cloud Service - next-gen Product Documentation.

The remainder of this section deals with the scaling of Horizon Edges when deployed into a supported cloud-native provider, such as a Microsoft Azure Provider.

Microsoft Azure Deployment Scaling Overview

When an Omnissa Horizon Edge deployment uses Microsoft Azure capacity providers, design decisions must be made with respect to some Microsoft Azure providers and subscription limitations. Scaling past those limitations can be achieved by using one or more of the following methods:

1. Scale out an individual Horizon Edge by:
   1. Adding additional Service Principals to support more VMs in the provider
   2. Adding extra resource capacity with secondary providers
2. Deploy multiple Horizon Edges to the same site
3. Deploy additional 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: Single Horizon Edge Deployment Overview

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 capacity 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

An Omnissa Horizon Edge usually has initial user capacity from the primary provider where the Horizon Edge was deployed. Depending on the provider being used for the Horizon Edge Deployment, certain platform constraints might apply.

A single Horizon Edge Deployment can be scaled up by either increasing the capability of the primary provider or by adding in secondary providers.

Figure 14: Scaling Out a Horizon Edge with Secondary Providers

 Single Horizon Edge Scaling with Microsoft Azure Deployments

A single Azure provider has constraints of Azure subscription maximums and VMs per service principal. See Azure Subscriptions Configuration Maximums and Azure Service Principals for more information.

By adding additional Azure service principals and secondary capacity providers, a single Horizon Edge deployment can support up to 20,000 VMs.

Additional Azure service principals can be added to increase the number of VMs supported.

• An Azure service principal is rate limited.
• Additional service principals can be added to increase API call throughput.
• Up to 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 and all storage providers. See Create a Service Principal for the Microsoft Azure Subscription for more information.

• 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 for more information.

Additional secondary providers, using either the same or a different Azure subscription, can be added to provide extra user capacity to a Horizon Edge.

• Each provider can support up to 5,000 VMs.
• Five service principals per provider are recommended to support 5,000 VMs in the provider.
• The maximum number of providers per Horizon Edge is 50, allowing you to add up to 49 secondary providers to supplement the initial primary provider. Note that you may need to use the API to achieve the maximum number of allowable secondary providers.

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

Table 10: Microsoft Azure Subscription Strategy

Table 11: Microsoft Azure Service Principal Strategy

Single Site Scaling

You can also deploy multiple Horizon Edges into a single site or region. Each Horizon Edge requires a separate resource capacity 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

Licensing

The Horizon Cloud Control Plane provides licensing services for subscription-based licenses. This allows connected Horizon Edge deployments to consume the purchased subscriptions.

For more information, see Use the Horizon Universal Console to Track Your Horizon Licenses.

Horizon 8

Connecting an Omnissa Horizon 8 environment to Horizon Cloud Service – next-gen, with a Horizon Edge Gateway appliance, enables the consumption of subscription licensing. For information on implementing the Horizon Edge Gateway appliance for Horizon 8, see Horizon Edge Gateway Appliance.

To support the deployment of Omnissa Horizon 8, your Horizon Cloud subscription might also include Broadcom products such as vSphere, vCenter, vSAN, ThinApp, App Volumes, and Workstation. To generate license keys for these products, follow the instructions in Use the Horizon Universal Console to Obtain Enterprise Infrastructure Keys.

Identity and Access 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 integrates with an external user identity provider to authenticate and prove the identity of users. Both Microsoft Entra ID (Azure Active Directory) and Omnissa Access (formerly Workspace ONE Access), are currently supported.
• Machine identity - Horizon Cloud Service - next-gen uses a directory to manage the identity of the virtual machines that are created for virtual desktops, and applications. Microsoft Active Directory, and Microsoft Entra ID (Azure Active Directory), are currently supported.

Table 12: User Identity and Machine Identity Combinations

When using Microsoft Entra ID (Azure Active Directory) for user identity, you may choose to use either the same Microsoft Entra ID (Azure Active Directory), or a connected Active Directory, for machine identity.

When using Omnissa Access for user identity, only a connected Active Directory is supported, for machine identity.

Figure 17: Sample Overview of Horizon Edge with User and Machine Identity Sources

Table 13: Identity and Access Management with Different Capacity Provider Types

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 Microsoft Entra ID (Azure Active Directory) or Omnissa Access as your user identity provider. When using Access, you must connect an Active Directory domain to the external identity provider. For more information, see Setting Up Your Identity Provider.

When using either Microsoft Entra ID (Azure Active Directory) or Access for user identity, you must connect an Active Directory to the external identity provider for the purposes of Machine Identity.

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.

The machine identity provider you configure with Horizon Cloud performs the authentication required when users attempt to access their desktops.

Supported machine identity sources include:

• 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 the resource provider (for example, Microsoft Azure).
• Microsoft Entra ID (Azure Active Directory)

Table 14: Active Directory Strategy

Single Sign-on

Horizon Cloud Service – next-gen provides a feature that allow end users a single sign-on experience to access the resources provided by the service. Enabling single sign-on 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 single sign-on service uses a certificate authority to generate short-lived, trust-based certificates to authenticate the user into a virtual machine, to avoid prompting the users for Active Directory credentials.

There are two different ways that single sign-on can be implemented with Horizon Cloud Service – next-gen:

• SSO - Uses an Omnissa Horizon Certificate Authority
• True SSO -  Uses a Microsoft Certificate Authority

Note: Only one SSO configuration is allowed per active directory domain. You cannot have both SSO and True SSO configured for the same active directory domain.

Table 15: Single Sign-on with Different Capacity Provider Types

SSO

When SSO is implemented for Horizon edge deployments on cloud-native capacity providers, the single sign-on component for the service runs in the Horizon Edge Gateway Appliance. The single sign-on component is a Certificate Authority (CA) that has a trust relationship configured with a Microsoft Active Directory. For the native SSO configuration, a Horizon Certificate Authority is used.

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 appropriate CA that is configured. 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.

Notes:

• Currently SSO is not possible if you are using Microsoft Entra ID (Azure Active Directory) for Machine Identity. Users will be prompted to login to their virtual machine resource manually.

For more information, see the following resources in the documentation:

• Using an Omnissa CA for SSO with Horizon Cloud Service - next-gen
• Add an SSO Configuration to Horizon Cloud Service - next-gen for an Omnissa CA

For an overview of the configuration process, see the Configuring SSO section of Horizon Cloud Service – next-gen Configuration.

  End User Sign-In Process with SSO

The diagram below describes a login for an end user of Horizon Cloud Service – next-gen leveraging the service’s SSO 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.

Figure 18: SSO End User Sign-In Process Flow

1. Client connects to the Horizon Control Plane auth service to find out which IdP is being used for customer. This is a one-time operation if using the Horizon Client.
2. From the Horizon Client (installed or HTML Access), the user authenticates, using an Internet browser, with the IdP and receives an access token.
3. 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.
4. Horizon Control Plane interacts with Horizon Agent to start a session.
5. Horizon Agent replies with the session details and data required for SSO (certificate signing request and request ID).
6. 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.
7. Horizon Agent receives and uses the token to call the Horizon Edge Gateway (Auth Engine) to request a logon certificate.
8. Auth Engine validates the token, extracts the CSR, signs it using the Horizon Certificate Authority, and returns a short-lived logon certificate.
9. Horizon Agent presents the certificate to the Windows Operating System, and Windows validates the authenticity of the certificate with Active Directory.
10. 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 6 through 9).

   SSO Components Trust Relationships

The user login flow is explained in the previous section but for clarity’s sake, we have provided 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 19: SSO Trust Relationships Overview

True SSO

True SSO is an optional method to enable Single-Sign-On capabilities to users. The primary difference between using the built-in SSO process and True SSO is the Certificate Authority that is used to provide the short-lived certificates to facilitate user login. True SSO uses an external Microsoft Certificate Authority.

True SSO works similarly in Horizon Cloud Service - next-gen as in Horizon 8. For details about the Horizon 8 implementation, see the True SSO section of Horizon 8 Architecture. One key difference is that the enrollment service is built into the Horizon Edge Gateway that is pushed out to cloud-native providers, such as Azure. The enrollment service runs as part of the authentication service on the Horizon Edge Gateway and is responsible for communicating with the Microsoft Certificate Authority to request the logon certificate.

A Horizon Edge Gateway requires line-of-sight communication to the Microsoft Certificate Authority servers to be able to use them for True SSO certificate generation.

Note: Multi-forest domain support is not yet available when using True SSO.

For more information, see the following resources in the documentation:

• Horizon Cloud - True SSO Requirements - Microsoft Enterprise Certificate Authority, Required Certificate Templates
• Add an SSO Configuration to Horizon Cloud Service - next-gen to Use True SSO with Your Horizon Edges

For an overview of the configuration process, see the Configuring True SSO section of Horizon Cloud Service – next-gen Configuration.

 End User Sign-In Process with True SSO

The diagram below describes a login for an end user of Horizon Cloud Service – next-gen leveraging the True SSO method.  

Figure 20: True SSO End User Sign-In Process Flow

1. Client connects to the Horizon Control Plane auth service to find out which IdP is being used for the environment. This is a one-time operation if using the Horizon Client.
2. From the Horizon Client (installed or HTML Access), the user authenticates, using an Internet browser, with the IdP and receives an access token.
3. The user launches 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.
4. Horizon Control Plane interacts with Horizon Agent to start a session.
5. Horizon Agent replies with the session details and data required for SSO (certificate signing request and request ID).
6. 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.
7. Horizon Agent receives and uses the token to call Horizon Edge Gateway (Auth Engine) to request a logon certificate.
8. Auth Engine validates the token, extracts the CSR, signs it with the enrolment agent certificate, and sends the signed request to the Microsoft Certificate Authority.
9. The Microsoft Certificate Authority validates the request and returns a short-lived logon certificate.
10. Auth Engine receives the short-lived logon certificate and returns it to the agent.
11. Horizon Agent presents the certificate to the Windows Operating System, and Windows validates the authenticity of the certificate with Active Directory. 
12. 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 6 through 11).

 True SSO Components Trust Relationships

The user login flow is explained in the previous section but for clarity’s sake, we have provided 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 21: True SSO Trust Relationship Overview

True SSO Scalability

A single Microsoft Certificate Authority (CA) can generate approximately 35 certificates per second. To ensure availability, it is best practice to deploy at least two Microsoft Certificate Authority instances and add both to the SSO Configuration.

Session Brokering

The broker service is a cloud-based brokering technology that allows you to broker desktops and applications sessions to end users across all cloud-connected Horizon pods, regardless of the infrastructure that they run on.

The broker service simplifies hybrid Horizon deployments with a few key features.

• A single connection FQDN (Fully Qualified Domain Name) for all remote resources. Users can connect to a single FQDN to access assignments across multiple Horizon pods.
• The broker service provides connectivity awareness of Horizon pods, which allows for redirection of requests for resources from an unavailable pod to another pod with sufficient resources to handle the request.
• Smart Brokering functionality can deliver desktops from multi-cloud assignments to end users along the shortest network route.

The broker service is aware of geographical locality and pod topology. Using this information, the broker service can make better resource-matching decisions and deliver desktops from multi-cloud assignments to end users along the shortest network route.

In Horizon 8 deployments, the Horizon Connection Servers acts as the broker for each Horizon 8 pod.

Table 16: Broker Service with Different Capacity Provider Types

Fleet Management

Fleet Management describes how the Horizon Cloud Service manages and maintains all the resources running on virtual machines for use by users. The control plane maintains the status of all of the virtual machines that are being used to deliver desktop and applications to end users so that they can be made available upon request from an end-user.

Communication Details in Horizon Cloud Service – next-gen

One of the key design pillars of Horizon Cloud Service – next-gen was to move functional components out of an individual customer’s deployment. Traditional Horizon components like brokering, user entitlements and App Volumes now have their configuration and functionality moved to the Horizon Cloud Control Plane.

The core components include a Horizon Client authenticating to the Horizon Cloud Service, which brokers connections to virtual desktops and apps.

For brokering to work correctly, the service needs to monitor and manage the build, status, and operational state of all the resources that are a part of the deployment. The broker needs to have up to date details on what resources are available to users so that it can efficiently assign users to the best available resources, according to the policies and assignments that the administrator has defined in the system.

Agent Command and Control Communications

The Horizon agents report their status directly to the cloud service via regional hubs that have been setup throughout the world. Each virtual machine managed by Horizon Cloud Service has a unique identifier that associates it with a specific customer tenant. That way, no matter where the virtual machine is deployed, the service has up-to date details on the entire fleet of virtual machines that it is managing on behalf of each customer account.

Figure 22: Horizon Agent Communication to Horizon Control Plane

To communicate with the fleet of virtual machines that are being used in customer environments, the Horizon Agent uses a modern, IOT protocol called MQTT to communicate to the service. This is the same kind of industry used protocol that is used for monitoring status of network-connected sensor, lighting, and environmental control devices. The product documentation details out specific DNS targets that the agents need to communicate to, so that you can restrict the agent VMs to only communicate with appropriate Horizon Cloud Service – next-gen resources.

If installed, the App Volumes Agent proxies its communications to the Horizon Service via the Horizon Agent to the Horizon Cloud Service. The Horizon Control Plane directs the App Volumes agent to attach any entitled App Volumes packages.

Agent Communication with Microsoft Azure Deployments

With Horizon Edges deployed on Microsoft Azure infrastructure, the agent status and control communications happens over the internet, or alternatively, via Microsoft’s Azure Private Link service. By selecting to use Microsoft Azure Private Link service, all command and control traffic leverages an endpoint in your virtual network to communicate directly to Horizon Cloud Service – next-gen over the Microsoft backbone network.

Connection and Protocol Communications

With Horizon Cloud Service - next-gen, the end-user login process straightforward. Since the Horizon Control plane is the single source of truth of resource status and availability, rather than individual pods, the service can make the decision on where to route the user to, based on policies defined in their assignments, and where those assigned resources are located.

Figure 23: Client Connection and Protocol Communication

Three phases of a user connection

1. Authentication to a supported IDP
2. Authorization token from IDP sent to Horizon Control Plane with user information
3. Protocol session is started with the resource assigned

Users’ login to the configured Identity Provider to authenticate into the service. Once they have received their authorization token, the client presents it to the Horizon Cloud Service. The service looks up user entitlements and presents the user with a list of authorized resources. Then the user selects a resource, and the service checks the status of available matching resources to fulfill the request. Finally, the user is sent a connection string, which is used to make a connection from the Horizon client or web browser to the brokered resource.

For Horizon Cloud Service, Blast is the only supported display protocol. For more details on user connectivity traffic flows with Horizon Cloud Service – next-gen brokering, review the  Horizon Cloud Service – next-gen Network Ports Diagrams. For more information on Horizon Clients and Agents supported for use with Horizon Cloud Service – next-gen, see KB80386.

Monitoring and Analytics Service

There are three components used for monitoring in the Horizon Cloud Service.

• Horizon Infrastructure Monitoring – Monitors all of the critical components of a Horizon deployment along with critical infrastructure components (such as DNS).
• User Monitoring – Monitors individual session and virtual desktop usage by end-user to provide details use for troubleshooting purposes.
• User Capacity Monitoring and Metrics - Monitors the health and performance of all end-user capacity (virtual machines). Monitoring data is collected by Horizon Agents, and other managed Horizon Cloud Service – next-gen resources, located in customer environments and sent to the Horizon Edge Gateway.  From there the monitoring data is handled differently based on license entitlement.

• Omnissa Intelligence – Used by Horizon Universal License entitled subscriptions
• Splunk Enterprise Integration – Used by Horizon Plus entitled subscriptions

Omnissa Intelligence Integration

When a Horizon Cloud tenant is integrated to Omnissa Intelligence, it provides insights into Horizon environment health, performance, and usage. From within the Intelligence console, this allows monitoring of the environment's health, performance, and end-user experience.

See the Intelligence documentation for more information, in particular the following sections:

• Experience Management for Horizon
• Horizon Cloud Next-Gen Integration

Image Management Service

Golden images are fundamental to the creation of desktop pools and RDS server farms. The Horizon Image Management Service can be used to create, customize, and publish golden image versions across your cloud-managed edge deployments. See Managing Horizon Images Using the Next-Gen Horizon Control Plane for more information.

With Horizon Edge deployments on cloud-native providers, the platform cloud services can be used to import a suitable image that can then be customized and used in pool and farm creation.

• For Azure-based deployments of Horizon Edge, see Images with Microsoft Azure Deployments.

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.

Table 17: Image Management with Different Capacity Provider Types

Images with Microsoft Azure Deployments

When the Horizon Edge deployment is on Azure, 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.

App Volumes

Omnissa App Volumes allows for the separation of applications from the OS image, simplifying application management with real-time application delivery, and one-to-many provisioning. App Volumes functionality is available in Horizon Cloud Service – next gen. App Volumes management components are provided as part of the cloud service, and App Volumes agents and packages reside in the deployed Horizon Edge.

For more information, see Using App Volumes.

Figure 24: App Volumes Service

Table 18: App Volumes with Different Capacity Provider Types

Applications and Packages

App Volumes provides the delivery of software programs that are not in the golden image VM image for VDI and RDSH.

• Packages - App Volumes groups one or more programs into packages, based on the requirements of each use case. A package is a virtual disk containing one or more programs that are captured together.
• Applications – An Application contains one or more Package, where each represents a different version of the Application and the programs in contains. Users and groups are entitlements are to an Application.

The Universal Console is used to create new App Volumes Applications, define new Package versions, and help with the capture, and packaging. A capture machine is automatically provisioned for the user that designated as the packager during the Package definition. That user can use the Horizon Client to connect to the capture machine, install the software, and complete the capture process. For more information, see Add an App Volumes Application.

Existing App Volumes packages can be imported into the Horizon Universal Console for use with a Horizon Edge deployment. For more information, see Add an App Volumes Application by Importing an Existing application package.

Assignments

There are multiple methods of assigning App Volumes applications.

• User Assignments –Use use the Entitlement workflow in the Desktop and App Catalog to assign App Volumes packages to users. User Assignment for The App Volumes management components attach the appropriate App Volumes application packages either when a user logs into a virtual machine or on-demand, depending on the delivery method chosen.
• Pool Groups – If you use a Pool Group for App Volumes package assignment, the App Volumes management components attach the appropriate App Volumes application packages to all VM’s in the pool group. regardless if the user has an assignment for those App Volumes Packages. 

For more information, see Create an Entitlement for an App Volumes Application using Horizon Cloud Service - next-gen.

Attachments

Application attachments are handled via the App Volumes Agent, which is installed in each virtual machine. To use App Volumes packages, you must have selected to add an App Volumes Agent to the image that the virtual machine pool is using, and the agent must be running on the virtual machine that is going to leverage App Volumes. The packages ae attached when the user logs in to a desktop.

Storage

By default, applications are stored in the primary provider of a Horizon Edge in storage.

If you have multiple Horizon Edge deployments in cloud-native providers, to replicate a captured or imported application package from one Horizon Edge to another, you must manually copy the packages from the file share of the source Horizon Edge to the file share of the destination Horizon Edge. For more information, see Manually Replicate App Volumes Application Packages Between Horizon Edge Deployments.

Pools, Pool Groups, 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 25: Import Images, Add Pools, Add Pool Groups, and Entitle Users

For more information on this process when using cloud-native deployments of Horizon Edge, such as Microsoft Azure, see Creating Desktops and Apps on Cloud-native Deployments.

Golden Image

With Horizon Edge deployments on cloud-native providers, you can import, customize, and prepare a suitable golden image. You can then publish the image to the Horizon Edges where this is to be used. See Image Management Service for more information.

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.

For more information, see Create a Pool.

Table 19: Pools with Different Capacity Provider Types

Pool Group

A pool group collects together one or more pools. Pool groups can include one or more pools from one or more edges and can include pools of differing pool machine sizes or workload profiles.

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.

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.

For more information, see Create a Single-Session Pool Group and Create a Multi-Session Pool Group.

Table 20: Pool Groups with Different Capacity Provider Types

Applications and Packages

Delivery of shared or pre-packaged applications to users in Horizon Cloud Service – next-gen takes on two different forms.

• Applications streamed through Application farm hosts (Windows 10 Multi-Session or Windows RDSH)
• Applications served through App Volumes Packages

Published Applications

Published applications are installed onto an appropriate Windows-based virtual machine image and then grouped together as a Shared Application Farm.

Entitlement

Once the required pools, pool groups, published applications, and App Volumes applications have been created, users and groups can be entitled to use the Horizon resources they require.

• Virtual Desktops – Users are entitled to pool groups, which allows the consumption of a desktop from the pools that are members of the pool group.
• Published Applications - Users are entitled to the applications, which allows the consumption from the multi-session pool group that supports those applications, and the individual pools that are members of the pool group.
• App Volumes - Users are entitled to the App Volumes applications.

For more information on entitling users or groups, see Desktops and Applications.

Dynamic Environment Manager

Omnissa Dynamic Environment Manager offers personalization and dynamic policy configuration for end-user desktops and applications.

For more information on configuring Dynamic Environment Manager for Horizon Edge deployments on cloud-native providers, see the Dynamic Environment Manager section of the Horizon Cloud Service – next-gen Configuration chapter.   

Summary and Additional Resources

Now that you have come to the end of this design chapter on Omnissa Horizon Cloud Service ­– next-gen, you can return to the reference architecture landing page and use the tabs, search, or scroll to select further chapter in one of the following sections:

• Overview chapters provide understanding of business drivers, use cases, and service definitions.
• Architecture chapters give design guidance on the Omnissa products you are interested in including in your deployment, including Workspace ONE UEM, Access, Intelligence, Workspace ONE Assist, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Manager, and Unified Access Gateway.
• Integration chapters cover the integration of products, components, and services you need to create the environment capable of delivering the services that you want to deliver to your users.
• Configuration chapters provide reference for specific tasks as you deploy your environment, such as installation, deployment, and configuration processes for Omnissa Workspace ONE, Horizon Cloud Service, Horizon 8, App Volumes, Dynamic Environment Management, and more.

Additional Resources

For more information about Horizon Cloud Service – next-gen, you can explore the following resources:

• Horizon Cloud Service – next-gen product page
•   Horizon Cloud Service – next-gen documentation

• Horizon Knowledge Base

Changelog

The following updates were made to this guide:

Author and Contributors

This chapter was written by:

• Graeme Gordon, Senior Staff Architect, Omnissa.
• Rick Terlep, Staff Architect, Omnissa.

The following people helped review and give feedback during the development of this content:

• Vernon Lihou, Senior Lead Solution Engineer, Omnissa.
• Nguyen Kim, EUC Solution Architect, Omnissa.

Feedback 

Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.