Horizon Cloud on Microsoft Azure - first-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 on Microsoft Azure using Horizon Cloud Service – first-gen.
• For new deployments, using Microsoft Azure to host and deliver desktops and applications, it is recommended to use Horizon Cloud Service – next-gen.

Introduction

Omnissa Horizon Cloud on Microsoft Azure is available using a software-as-a-service (SaaS) model. This service comprises multiple software components.

Figure 1: Horizon Cloud Service on Microsoft Azure

Horizon Cloud Service provides a single cloud control plane, that enables the central orchestration and management of remote desktops and applications in your Microsoft Azure capacity, in the form of one or multiple subscriptions in Microsoft Azure.

The Horizon Cloud Service control plane is a hosted service that includes feature updates and enhancements for a software-as-a-service experience. The Horizon Cloud Service is an application service that runs in multiple Microsoft Azure regions.

The cloud control plane also hosts a common management user interface called the Horizon Cloud Administration Console, or Administration Console for short. The Administration Console runs in industry-standard browsers. It provides you with a single location for management tasks involving user assignments, virtual desktops, RDSH-published desktop sessions, and applications. This service is currently hosted in multiple Azure regions. The Administration Console is accessible from anywhere at any time, providing maximum flexibility.

Deployment Overview

A successful deployment of Horizon Cloud Service on Microsoft Azure depends on good planning and a robust understanding of the platform. This section discusses the design options and details the design decisions that were made to satisfy the design requirements of this reference architecture.

The core elements of Omnissa Horizon Cloud Service include:

• Horizon Cloud Control Plane
• Horizon Cloud Manager virtual machine, which hosts the Administration Console UI
• Unified Access Gateway
• Horizon Agent
• Horizon Client
• App Volumes

The following figure shows the high-level logical architecture of these core elements. Other components are shown for illustrative purposes.

Figure 2: Horizon Cloud Service on Microsoft Azure Logical Architecture

This figure demonstrates the basic logical architecture of a Horizon Cloud Service pod on your Microsoft Azure capacity.

• Your Microsoft Azure infrastructure as a service (IaaS) provides capacity.
• Your Horizon Cloud Service control plane is granted permission to create and manage resources with the use of a service principal in Microsoft Azure.
• You provide additional required components, such as Active Directory, and optional components, such as a Workspace ONE Access Connector or RDS license servers.
• The Horizon Cloud Service control plane initiates the deployment of the Horizon Cloud Manager VM, Unified Access Gateway appliances for secure remote access, and other infrastructure components that assist with the configuration and management of the Horizon Cloud Service infrastructure.
• After the Horizon Cloud Service pod is deployed, you can connect the pod to your own corporate AD infrastructure or create a new AD configuration in your Microsoft Azure subscription. You deploy VMs from the Microsoft Azure marketplace, which are sealed into images, and can be used in RDSH server farms.
• With the VDI functionality, you can also create Windows 10 assignments of dedicated and floating desktops.
• You can leverage RDSH Farms to deliver session-based desktops and applications to users.
• You can leverage Farms to deliver session-based desktops based on Windows 10 Multi-Session VM’s.

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

Table 1: Components of Horizon Cloud on Microsoft Azure

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

App Volumes in Horizon Cloud on Microsoft Azure

Architecture Overview

The App Volumes Agent is installed in the guest operating system of nonpersistent VMs. The agent communicates with the App Volumes Manager instances to determine package entitlements. Virtual disks containing the programs are attached to the guest operating system in the VM, making applications available to end users.

Figure 3: App Volumes Logical Components

The components and features of App Volumes are described in the following table.

Table 3: App Volumes Components and Concepts

Key Design Considerations

• Provisioning of App Volumes infrastructure components, such as App Volumes Managers, App Volumes databases, and storage are handled automatically at pod deployment.
• Customers can access App Volumes functionality only through the Control Plane.
• App Volumes is deployed as a part of every Horizon Cloud on Microsoft Azure pod.
• App Volumes agent is available as on optional install from the Horizon Agent Installer package. For details, see:
  • Create the Virtual Machine Manually in Your Pod in Microsoft Azure
  • Create a Base Virtual Machine Automatically from the Microsoft Azure Marketplace and Pair it with Horizon Cloud on a Per-Pod Basis
• Any kernel mode applications should reside in the base image and not in a package.
• App Volumes Packages for Horizon Cloud on Microsoft Azure are stored as VHD files.
• Assign as few packages as possible per user or device. See the Knowledge Base article App Volumes Sizing Limits and Recommendations (67354) for the recommended number of packages per VM.
  
  Note: This KB article was written for App Volumes 2.x AppStacks. Although most of the content is applicable to App Volumes 4, the maximum number of package attachments tested has increased.

Network Ports for App Volumes

See Ports and Protocols Required by App Volumes Features for details on Ports and Protocols and DNS Requirements for Horizon Cloud on Microsoft Azure, and much more.

Brokering Methods for Horizon Cloud on Microsoft Azure

A connection broker is a critical function of every hosted desktop environment. It finds, on behalf of the user, the correct type of resource to service the end user’s needs, based on the entitlements that the administrator has allowed for that individual.

An administrator defines the rules that indicate which resources a user is entitled to use and how they can use them. The administrator also defines what authentication method will be used to assure the identity of the user.

After a user logs in to the system, they are presented with a list of resources and capacities that they can use in the current context. For example, an administrator might define that certain applications can be used remotely only if the user is on a trusted network connection. The connection broker would consider that information when deciding what resources to present to the end user.

When an authenticated user selects a resource to use, the connection broker finds a suitable resource to handle that request. The user is remotely connected to that resource for use. The connection broker can also, in some cases, influence the kind of display protocol that will be used to deliver the remote experience to the user, based on variables like locality, network conditions or security, with the intent of providing the best experience for the end user.

Choosing a Brokering Method

There are two separate methods you can broker connections within Horizon Cloud on Microsoft Azure:

• Single-pod brokering – Leveraging the broker that is built into the Horizon Cloud on Microsoft Azure Pod Manager VM.
• Universal Broker – A cloud-based connection broker delivered as a service that can broker resources from multiple pods.

Customers who are new to Horizon Cloud on Microsoft Azure as of July 2020, have a choice of broker.   Customers who started prior to July 2020 will receive a notice when they can use the Universal Broker. After you select a broker, it cannot be changed. See Introduction to Horizon Universal Broker for more details on selecting a broker.

If you select single-pod brokering, you can broker assignments only on a pod-by-pod basis—meaning that any user assignments must be created and are only valid for an individual, given pod, even if your customer account has multiple pods deployed and managed by Horizon Cloud Service.

If you choose Universal Broker, you can broker resources across multiple pods. Note that there are some limitations to the features available, client configurations, and the types of resources and you can broker to users across pods with the Universal Broker. These limitations might affect your choice of brokering method.  See Universal Broker - Feature Considerations and Known Limitations for details. There are also a number of System Requirements for Universal Broker that are required for different components of your Horizon Cloud on Microsoft Azure implementation.

Table 4: Implementation Strategy for Universal Broker

Availability and Scalability

When creating your design, consider that you want an environment that can scale up when necessary and also remain highly available. Design decisions must be made with respect to some Microsoft Azure limitations and some Horizon Cloud limitations.

A Horizon Cloud pod is typically used to describe a deployment of Horizon Cloud in a Microsoft Azure subscription. The primary component of a pod is the Horizon Cloud Manager VM. A Horizon Cloud pod can have several functional components that support the key components of a Horizon Cloud pod. Examples of these components are a jump box, Unified Access Gateway virtual appliances, and the manager VM.

Several Microsoft Azure platform components and services are used in a pod, such as Microsoft Azure Database for PostgreSQL Service, Microsoft Azure load balancers, and Microsoft Azure virtual networks (VNets). A full list of platform requirements can be found in the First-Gen - Horizon Cloud Service on Microsoft Azure - Requirements Checklist - Starting November 2, 2023.

Availability

One key design principle is to remove single points of failure in the deployment. The Horizon Cloud pod has a few components to protect against a single point of failure.

• Two Unified Access Gateway virtual appliances are deployed by default along with a Microsoft Azure load balancer configured to route traffic to the primary Unified Access Gateway. Availability is tested by using Http:80/favicon.ico as a health monitoring HTTP GET request to the load balancer.
• You can optionally deploy a secondary pod manager VM with a Microsoft Azure load balancer configured to route traffic to the currently active pod manager VM.

Horizon Cloud on Microsoft Azure leverages cloud-based software components that provide functionality for the Horizon Cloud pod, such as monitoring, image creation, and an administrative interface. To maintain the health and function of the Horizon Cloud pod, you must have line-of-site visibility to several cloud-based services. A full list of all of the DNS addresses that must have line-of-site visibility is documented in DNS Requirements for New Pod Deployment, Pod Updates, and Service Operations that Apply on a Tenant-Wide Basis

Horizon Cloud on Microsoft Azure operates using Microsoft Azure infrastructure components. Subscriptions are hosted in Azure regions (data centers) located throughout the world. Outages and service degradations on the Microsoft Azure platform can result in problems with the operations of a Horizon Cloud pod. Furthermore, Microsoft has regular maintenance windows for upgrades to the platform, and although most maintenance activities do not affect the operations of VMs, some might. For more information, see the Microsoft documents Maintenance for virtual machines in Azure and SLA summary for Azure services. You can view the current status of Azure regions on the Azure status page.

Scalability

The way to expand a Horizon Cloud on Microsoft Azure environment is to deploy additional pods.

Horizon Cloud on Microsoft Azure has certain configuration maximums you must consider when making design decisions:

• Up to 2,000 concurrent active connections are supported per Horizon Cloud pod.
• Up to 2,000 desktop and RDSH server VMs are supported per Horizon Cloud pod.
• Up to 2,000 desktop and RDSH server VMs are supported per Microsoft Azure region or subscription.

To handle larger user environments, you can deploy multiple Horizon Cloud pods, but take care to follow the accepted guidelines for separating the pods from each other. For example, under some circumstances, you might deploy a single pod in two different Microsoft Azure regions, or you might be able to deploy two pods in the same subscription in the same region if the IP address space is large enough to handle multiple deployments.

For more information, see First-Gen Tenants - Horizon Cloud Service on Microsoft Azure Service Limits.

For information about creating subnets and address spaces, see First-Gen Horizon Cloud - Configure the Required Virtual Network in Microsoft Azure.

Table 5: Implementation Strategy for Horizon Cloud Pods

Configuration Maximums for Microsoft Azure Subscriptions

Horizon Cloud on Microsoft Azure leverages Microsoft Azure infrastructure to deliver desktops and applications to end users. Each Microsoft Azure region can have different infrastructure capabilities. You can leverage multiple Microsoft Azure regions for your infrastructure needs.

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

These deployments are a part of your Microsoft Azure subscription or subscriptions. A subscription is a logical separate unit of Microsoft Azure capacity that you are responsible for. You can have multiple Microsoft Azure subscriptions as a part of the organization defined for you in Microsoft Azure.

A Microsoft Azure subscription is an agreement with Microsoft to use one or more Microsoft cloud platforms or services, for which charges accrue based either on a per-user license fee or on cloud-based resource consumption. For more information on Microsoft Azure subscriptions, see Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings.

Some of the limitations for individual Microsoft Azure subscriptions might impact designs for larger Horizon Cloud on Microsoft Azure deployments. For details about Microsoft Azure subscription limitations, see Azure subscription and service limits, quotas, and constraints. Microsoft Azure has a maximum of 10,000 vCPUs that can be allotted for any given Microsoft Azure subscription per region.

If you plan to deploy 2,000 concurrent VDI user sessions in a single deployment of Horizon Cloud on Microsoft Azure, consider the VM configurations you require. If necessary, you can leverage multiple Microsoft Azure subscriptions for a Horizon Cloud on Microsoft Azure deployment.

Note: You might need to request increases in quota allotment for your subscription in any given Microsoft Azure region to accommodate your design.

Table 6: Implementation Strategy Regarding Microsoft Azure Subscriptions

Other Design Considerations

Several cloud- and SaaS-based components are included in a Horizon Cloud on Microsoft Azure deployment. The operation and design of these services are considered beyond the scope of this reference architecture because it is assumed that no design decisions you make will impact the nature of the services themselves. Microsoft publishes a Service Level Agreement for individual components and services provided by Microsoft Azure.

Horizon Cloud on Microsoft Azure uses Azure availability sets for some components included in the Horizon Cloud pod—specifically for the two Unified Access Gateways that are deployed as a part of any Internet-enabled deployment.

You can manually build and configure Horizon Cloud pods to provide applications and desktops in the event that you have an issue accessing a Microsoft Azure regional data center. Microsoft has suggestions for candidate regions for disaster recovery. For more information, see Business continuity and disaster recovery (BCDR): Azure Paired Regions.

As was mentioned previously, Horizon Cloud on Microsoft Azure has no built-in functionality to handle business continuity or regional availability issues. In addition, the Microsoft Azure services and features regarding availability are not supported by Horizon Cloud on Microsoft Azure.

Authentication

One method of accessing Horizon desktops and applications is through Workspace ONE Access. This requires integration between the Horizon Cloud Service and Workspace ONE Access using the SAML 2.0 standard to establish mutual trust, which is essential for single sign-on (SSO) functionality.

• When SSO is enabled, users who log in to Workspace ONE Access with Active Directory credentials can launch remote desktops and applications without having to go through a second login procedure when they access a Horizon desktop or application.
• When users are authenticating to Workspace ONE Access and using authentication mechanisms other than AD credentials, True SSO can be used to provide SSO to Horizon resources for the users.

For details, see the following documentation:

• Horizon Cloud Environment with Universal Broker - Integrate the Tenant with Workspace ONE Access and Intelligent Hub Services
•  A Horizon Cloud Environment with Single-Pod Brokering — Integrating the Environment’s Horizon Cloud Pods in Microsoft Azure with Workspace ONE Access
• Configure True SSO for Use with Your Horizon Cloud Environment.

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

True SSO

Many user authentication options are available for logging in to Workspace ONE Access or Workspace ONE. Active Directory credentials are only one of these many authentication options. Ordinarily, using anything other than AD credentials would prevent a user from being able to SSO to a Horizon virtual desktop or published application through Horizon Cloud on Microsoft Azure. After selecting the desktop or published application from the catalog, the user would be prompted to authenticate again, this time with AD credentials.

True SSO provides users with SSO to Horizon Cloud on Microsoft Azure desktops and applications regardless of the authentication mechanism used. True SSO uses SAML, where Workspace ONE is the Identity Provider (IdP) and the Horizon Cloud pod is the Service Provider (SP). True SSO generates unique, short-lived certificates to manage the login process. This enhances security because no passwords are transferred within the data center.

Figure 4: True SSO Logical Architecture

True SSO requires a new service—the Enrollment Server—to be installed.

Table 7: Implementation Strategy for SSO Using Authentication Mechanisms Other Than AD Credentials

Design Overview

For True SSO to function, several components must be installed and configured within the environment. This section discusses the design options and details the design decisions that satisfy the requirements.

The Enrollment Server is responsible for receiving certificate-signing requests from the Connection Server and passing them to the Certificate Authority to sign using the relevant certificate template. The Enrollment Server is a lightweight service that can be installed on a dedicated Windows Server VM, or it can run on the same server as the MS Certificate Authority service.

Scalability for True SSO

A single Enrollment Server can easily handle all the requests from a single pod. The constraining factor is usually the Certificate Authority (CA). A single CA can generate approximately 70 certificates per second (based on a single vCPU). This usually increases to over 100 when multiple vCPUs are assigned to the CA VM.

To ensure availability, a second Enrollment Server should be deployed per pod (n+1). Additionally, ensure that the Certificate Authority service is deployed in a highly available manner, to ensure complete solution redundancy.

Figure 5: True SSO Availability and Redundancy

With two Enrollment Servers, and to achieve high availability, it is recommended to co-host the Enrollment Server service with a Certificate Authority service on the same machine.

Table 8: Implementation Strategy for Enrollment Servers

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

Optional Components

You can implement optional components to provide additional functionality and integration with other products:

• Workspace ONE Access – Implement and integrate the deployment with Workspace ONE Access so that end users can access all their apps and virtual desktops from a single unified catalog.
• Dynamic Environment Manager – Leverage Dynamic Environment Manager to provide a wide range of capabilities such as personalization of Windows and applications, contextual policies for enhanced user experience, and privilege elevation so that users can install applications without having administrator privileges.
• True SSO Enrollment server – Deploy a True SSO Enrollment Server to integrate with Workspace ONE Access and enable single-sign-on features in your deployment. Users will be automatically logged in to their Windows desktop when they open a desktop from the Workspace ONE user interface.
• Workspace ONE Assist - Workspace ONE Assist for Horizon is a real-time remote employee support solution that enables IT and help desk staff to support employees with virtual desktop task and issues remotely.

Shared Services Prerequisites

The following shared services are required for a successful implementation of Horizon Cloud on Microsoft Azure deployment:

• DNS – DNS is used to provide name resolution for both internal and external computer names. For more information, see First-Gen Tenants - Configure the DNS Server Settings Needed by the VNet Topology You Will Use for Your Horizon Cloud Pods in Microsoft Azure.
• Active Directory – There are multiple configurations you can use for an Active Directory deployment. You can choose to host Active Directory completely on-premises, completely in Microsoft Azure, or in a hybrid (on-premises and in Microsoft Azure) deployment of Active Directory for Horizon Cloud on Microsoft Azure. For supported configurations, see First-Gen Tenants - Horizon Cloud - Active Directory Domain Configurations.
• RDS licensing – For connections to RDSH servers, each user and device requires a Client Access License assigned to it. RDS licensing infrastructure can be deployed either on-premises or in a Microsoft Azure region based on your organization’s needs. For details, see License your RDS deployment with client access licenses (CALs).
• DHCP – In a Horizon environment, desktops and RDSH servers rely on DHCP to get IP addressing information. Microsoft Azure provides DHCP services as a part of the platform. You do not need to set up a separate DHCP service for Horizon Cloud Service on Microsoft Azure. For information on how DHCP works in Microsoft Azure, see Address Types in Add, change, or remove IP addresses for an Azure network interface.
• Certificate services – The Unified Access Gateway capability in your pod requires SSL/TLS for client connections. To serve Internet-enabled desktops and published applications, the pod deployment wizard requires a PEM-format file. This file provides the SSL/TLS server certificate chain to the pod’s Unified Access Gateway configuration. The single PEM file must contain the entire certificate chain, including the SSL/TLS server certificate, any necessary intermediate CA certificates, the root CA certificate, and the private key.
  
  For additional details about certificate types used in Unified Access Gateway, see Selecting the Correct Certificate Type. Also, see Environment Infrastructure Design for details on how certificates impact your Horizon Cloud on Microsoft Azure deployment.

Network Design

Horizon Cloud on Microsoft Azure is a simple solution for providing desktops and streamed applications to your end users. The deployment is straightforward: You prepare and provide information, to the service, about a Microsoft Azure subscription, and the Horizon Service deploys a Horizon Cloud on Microsoft Azure pod into the subscription on your behalf. 

However, some companies need more flexibility in pod deployment options. For example, with the custom deployment options available in Horizon Cloud on Microsoft Azure, you can configure separate development, testing, and production environments, yet allow your application development team to access them all from the same Horizon Cloud on Microsoft Azure pod. 

For a basic Horizon Cloud on Microsoft Azure deployment, all components of the pod are deployed into the same Microsoft Azure VNet in the same subscription.

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

Starting with Horizon Cloud on Microsoft Azure 1.5, two deployment options have been added to facilitate these architectures.

• Use a Different Subscription for External Gateway
• Use a Different Virtual Network

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

When you choose either of these new deployment options, the Unified Access Gateway configuration components are deployed into a separate VNet or Azure subscription from the rest of the Horizon Cloud on Microsoft Azure pod. These options require you to follow an amended set of prerequisites to make Horizon Cloud on Microsoft Azure function properly.  

Important: For both of these deployment options, if you plan to create a network peering to provide visibility between your VNets, be sure to create the required subnets before running the deployment wizard. See First-Gen Tenants - In Advance of Pod Deployment, Create the Horizon Cloud Pod’s Required Subnets on your VNet in Microsoft Azure.

Table 9: Implementation Strategy for Horizon Cloud on Microsoft Azure Networks

Additional Network Topologies for Gateways and User Workloads

This section discusses optional use of different subnets or subscriptions for user workload and using a different subscription for an external gateway.

You can choose to deploy your Unified Access Gateway appliances into a separate subscription by toggling this option in the Horizon Cloud on Microsoft Azure deployment wizard. 

Figure 7: Selecting a Separate Subscription for Unified Access Gateway Appliances

This option allows you to deploy the Unified Access Gateway (UAG) components into a separate subscription, as depicted in the following figure.

Figure 8: Additional Azure Subscription Used for the External Gateway

With this configuration, you must ensure that the two subscriptions are line-of-sight visible to each other through either of the following options:

• Network peering across subscriptions, as described in the Microsoft document Create a virtual network peering - Resource Manager, different subscriptions and Azure Active Directory tenants
• Using a site-to-site virtual gateway, as described in the Microsoft document Create a Site-to-Site connection in the Azure portal

Also, see First-Gen Tenants - Prerequisites for Running the First-Gen Pod Deployment Wizard in the Horizon Cloud Deployment Guide.

Deploying Unified Access Gateways into a Different VNet

You can choose to deploy your Unified Access Gateway appliances into a separate virtual network by toggling this option in the Horizon Cloud on Microsoft Azure deployment wizard.

Figure 9: Selecting a Separate Virtual Network for Unified Access Gateway Appliances

This option allows you to deploy the Unified Access Gateway components into a separate VNet, as depicted in the following figure.

Figure 10: Unified Access Gateway in a Separate VNet – Same Subscription

With this configuration, you must ensure that the two VNets are line-of-sight visible to each other through either of the following options:

• Virtual network peering, as described in the Microsoft document Connect virtual networks with virtual network peering using the Azure CLI
• Using a VNet-to-VNet connection, as described in the Microsoft document Configure a VNet-to-VNet VPN gateway connection by using the Azure portal

Also, see First-Gen Tenants - Prerequisites for Running the First-Gen Pod Deployment Wizard in the Horizon Cloud Deployment Guide.

Using the Options for a Separate Subscription or VNet in Other Configurations

The use of these two deployment options opens the door to a number of deployment configurations that were not available until now. The diagrams that follow describe examples of typical configurations that companies have used for more complex deployments. For example, the deployment configuration can make external traffic flow through a separate VNet, where network virtual appliances are deployed to provide a DMZ. This DMZ could manage Internet-based traffic prior to allowing access to the Unified Access Gateway appliances. This strategy follows the example described in the Microsoft document Hub-Spoke network topology in Azure.

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

The configurations depicted in the following diagrams show how you can deploy the components leveraging a separate subnet for network virtual appliances (NVAs), with a trusted connection to the Horizon Cloud on Microsoft Azure components.

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

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

Using a Separate VNet for User Workload Separation

You can choose to deploy user capacity workloads into a separate VNet to distinguish user workloads from each other within your pod’s subscription. There are some limitations to this configuration that are detailed in Overview of Using Multiple Tenant Subnets with Your Horizon Cloud Pod for Your Farms and VDI Assignments.

This can be useful if you need to build distinct environments to support separated testing environments, or secure access to other resources to individual VNets. Deploying assignments into separate VNets allows you more granular control of your deployment and enables you to use firewalls and other networking components to secure ingress and egress of the environment. If you leverage these features, you might need to set up VNet peerings to allow for communications between the pod management VNet or other VNets. To configure an assignment to use a separate VNet for user workloads, follow the guidelines in Overview of Using Multiple Tenant Subnets with Your Horizon Cloud Pod for Your Farms and VDI Assignments.

Figure 13: Using a separate VNet for user workload separation

Single-Site Design

Microsoft Azure is a cloud-based service platform that is deployed in many Azure data centers throughout the world, organized into regions. As the Microsoft Azure regions page states: “A region is a set of data centers deployed within a latency-defined perimeter and connected through a low-latency network.” 

It is good practice to select an Azure region near your primary user groups or applications to achieve low network latency between your users’ VDI desktops or RDSH server farms and the applications they use. Doing so will have a positive impact on your users’ experience with Horizon Cloud on Microsoft Azure. Also make sure that the region you select has access to all the Azure products and services you plan to use. Azure products are not distributed uniformly across all Azure regions. For example, some virtual machine types might not be available in any given region. See Products available by region.

Table 10: Implementation Strategy for Microsoft Azure Regions

You can deploy multiple Horizon Cloud on Microsoft Azure pods into a single Azure region. Doing so enables you to service more than 2,000 users in any given locality. To accomplish this, you must leverage multiple Azure subscriptions in the same region.

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

Multi-site Design

You can deploy Horizon Cloud pods to multiple Microsoft Azure regions and manage them all through the Horizon Cloud Administration Console. Each Horizon Cloud pod is a separate entity and is managed individually. VM golden images, assignments, and users must all be managed within each pod. No cross-pod entitlement or resource sharing is available.

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

Table 11: Implementation Strategy for Multi-site Deployments

Note: A Split-horizon DNS configuration might be required for a multi-site deployment, depending on how you want users to access the Horizon Cloud on Microsoft Azure environment. You can leverage both options to scale to multiple subscriptions in the same and other regions as required.

External Access

You can configure each pod to provide access to desktops and applications for end users located outside of your corporate network. By default, Horizon Cloud pods allow users to access the Horizon Cloud environment from the Internet. When the pod is deployed with this ability configured, the pod includes a load balancer and Unified Access Gateway instances to enable this access.

If you do not select Internet Enabled Desktops for your deployment, clients must connect directly to the pod and not through Unified Access Gateway. In this case, you must perform some post-deployment steps to create the proper internal network routing rules so that users on your corporate network have access to your Horizon Cloud environment.

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

Entitlement to Multiple Pods

Starting with the July 2020 release of Horizon Cloud on Microsoft Azure (Horizon Cloud Service on Microsoft Azure 3.1), you are able to entitle users across Horizon Cloud on Microsoft Azure pods.  While each Horizon Cloud pod is managed individually, and you can create Multi-Cloud Assignments to allow users to leverage resources in multiple Horizon Cloud on Microsoft Azure pods.

To be able to leverage Multi-Cloud Assignments, you must have selected Universal Broker as your broker type for your Horizon Cloud tenant account. For more details on Multi-Cloud Assignments and Universal broker and how they can be used to entitle users across Horizon Cloud on Microsoft Azure Pods, see First-Gen Horizon Control Plane Architecture.

You can also implement Workspace ONE Access to show all Horizon and Application entitlements to a given user.

App Volumes Packages in Horizon Cloud on Microsoft Azure

Currently, App Volumes with Horizon Cloud on Microsoft Azure applies to either Floating Assignments using Windows 10 within Horizon Cloud on Microsoft Azure or Session-Based Desktop Assignments using Windows 10 Multi-Session farms with Horizon Cloud on Microsoft Azure. Details on the types of configurations where App Volumes packages can be used with Horizon cloud on Microsoft Azure can be found in App Volumes Applications for Horizon Cloud on Microsoft Azure - Overview and Prerequisites.

Package Templates

By default, a single 20-GB package template is available with the App Volumes service. This template is automatically used during the packaging process to create packages in the VHD format.

Packages at Scale

Horizon Cloud on Azure currently supports up to 2000 concurrent users per pod. With Simplified Application Management (SAM), administrators can now record a single application in a package, there is no need to group them together. This approach simplifies the lifecycle management of an individual application but increases the number of packages that need to be delivered to the virtual desktop. The maximum number of App packages that can be mounted into a Windows desktop is bound by the limits in the Windows Operating system. Significantly increasing the number of App packages can impact the login time across users that are being serviced by a single pod only in certain cases.

In practice, the number of packages attached to a VM will likely be considerably lower than the maximum values.

Attaching packages involves the following processes:

• The disk mount (mounting the package VHD to the VM)
• The virtualization process applied to the content in the package (merging files and registry entries with the guest OS)

The time required to complete the virtualization process varies greatly, depending on the programs contained in a given package. The more packages that need to be attached, the longer this operation might take to complete.

Recommended Practices for Packaging Applications

Consider the following best practices when creating and packaging applications:

• The following characters cannot be used when naming packages: & “ ‘ < >
• The packaging process automatically creates packaging VMs based on an Image you create. Ensure the image selected contains the App Volumes agent, and that it resembles as closely as possible the target environment where the package is to be deployed. For example, the packaging VM and target should be at the same OS patch and service pack level and, if programs are included in the golden image, they should also be in the packaging VM image.
• Do not use a packaging machine where you have previously installed and then uninstalled any of the programs that you will capture. Uninstalling a program might not clean up all remnants of the software, and the subsequent App Volumes package capture might not be complete.

Recommended Practices for Updating and Assigning Updated Packages

App Volumes 4 introduced assignment types called marker and package to improve the administrative process of updating application packages. Using the current marker enables distribution of the current package to your end-user population, whereas using the package assignment type enables distribution of test versions to a subset of users for validation.

After a new package has been tested and approved, you can simply change the Current marker to point to the new package. As end users log out of their desktop sessions, the old version of the package is detached. When they log on again, the new version is attached.

The following illustration shows the Notepad++ application, which contains three packages with different versions of the software.

Figure 16: Portion of the Application Detailing the Three Packages and Current Marker

Notepad++ v7 has the Current marker, so it is distributed to the general population of end users. Notepad++ version 7.87 is an updated package that contains a newer version of the Notepad++ program.

Figure 17: Portion of the Application Assignment Detailing the Assignment Options

Notepad++ version 7.8.7 is using a package assignment type to directly assign that specific package to a group of test users for validation.

To learn more about assignment types, refer to Assign Application Package in App Volumes 4 Feature Review.

To initiate an update to programs in an existing package, use the App Volumes Manager console to invoke the update process. This process clones the original package for you to work with and apply updates. End users continue to work from the original package to prevent user downtime. The new package with the updated programs is distributed by simply moving the Current marker once it has been approved.

Consider the following best practices when updating and assigning updated packages:

• When creating and updating packages, use the Stage drop-down list to select an appropriate value. This makes it easy for you and other App Volumes admins to manage the lifecycle of the package.

Figure 18: List of Available Package Stages

• Use the marker assignment type to simplify updates for your general population of users.
• Use the package assignment type for one-off, explicit assignments of a specific version.

Performance Testing for Packages

Test packages immediately after packaging to determine their overall performance. Using a performance analytics tool, to gather relevant performance information for use when packages are operated on a larger scale. Do not neglect user feedback, which can be extremely useful for assessing the overall performance of an application.

This evaluation can be time-consuming for the administrator, but it is necessary for any desktop- transformation technology or initiative.

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

ThinApp Integration with Packages

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

Microsoft Office Application Packages

For deploying Microsoft Office applications through App Volumes, see the Knowledge Base article Installing and using Microsoft Office Products with App Volumes 2.x/4.x.

 Office Plug-Ins and Add-Ons

The most straightforward method is to include Microsoft Office plug-ins or add-ons in the same package as the Microsoft Office installation.

However, if necessary, you can include plug-ins or add-ons in packages that are separate from the packages that contain the Microsoft applications to which they apply. Before packaging the plug-in or add-on, install the primary application natively in the OS of the packaging VM.

Note: Ensure the plug-in or add-on is at the same version as the Microsoft Office application in the package. This includes any patches or updates.

 Recommended Practices for Installing Office

It is recommended that you install core Microsoft Office applications in the base virtual desktop image, and create one package for non-core Microsoft Office applications, such as Visio, Project, or Visio and Project together.

To create the package with Visio and Project, use a packaging machine with the same core Microsoft Office applications as on the base image. After the package is created, you can assign the package to only the users who require these non-core Microsoft Office applications.

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

More Guidance and Considerations on Packages

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

Summary and Additional Resources

Now that you have come to the end of this design chapter on Omnissa Horizon Cloud on Microsoft Azure – first-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 on Microsoft Azure – first-gen, you can explore the following resources:

• Horizon Cloud Service - first-gen documentation

• Knowledge Base

Changelog

The following updates were made to this guide:

Author and Contributors

This chapter was written by:

• Rick Terlep,  Staff Architect, Omnissa.

Contributors:

• Graeme Gordon, Senior Staff 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.