Horizon Cloud Service - next-generation Network Ports Diagrams

Overview

This document provides port and protocol requirements for connectivity between the various components and servers in an Omnissa Horizon® Cloud Service™ next-generation deployment on a cloud-native infrastructure. This document is intended to be a companion to the Port and Protocol Requirements for Your Horizon Cloud Deployment in Microsoft Azure from the product documentation, which provides ports and protocols in tabular format. The tables tell you which ports must be opened for traffic from the end users' connections to reach their pod-provisioned virtual desktops and remote applications, as well as how to choose how your end users will connect.

This document leverages the Horizon Cloud Service product documentation for a tabular listing of all possible ports from a source component to destination components within a typical Horizon Cloud Service on cloud-native deployments. This does not mean that all these ports necessarily need to be open. If a component or protocol is not in use, then the ports associated with it can be ignored. For example:

• If you are not using Client Drive Redirection, you do not need to open the required ports.
• If you are not leveraging USB access, ports to and from it can be ignored.

Furthermore, this document does not list all possible ports for all possible integrations with third-party services. The document lists ports to third-party services that are critical to a functioning deployment.

Ports shown are destination ports. In the diagrams, arrows depict the direction of communication from source to destination and assume a stateful connection.

The Horizon Cloud tables and diagrams include connections to the following products, product families, and components:

• Horizon Client
• Unified Access Gateway
• Dynamic Environment Manager

Client Connections to Horizon Cloud Service next-generation on Microsoft Azure Infrastructure

Deploying Horizon Cloud Service next-generation on Microsoft Azure infrastructure is relatively straightforward. It is important to know that your Microsoft Azure infrastructure must be available and configured for basic networking functionality. This includes the ability to communicate with core infrastructure platform components such as DNS, Active Directory, and file shares.

You also need to make sure that you have properly configured a supported Identity Provider for both user identity (i.e., Workspace ONE Access, Azure Active Directory) and machine identity (Active Directory) and that the two directories are synchronizing correctly (via Azure Active Directory Domain Services or other methods). 

Note: The only display protocol that is allowed for use with Horizon Cloud Service – next-generation is Blast Extreme.

For details on the network ports required for a Horizon Cloud Service next-generation with Microsoft Azure infrastructure, see Port and Protocol Requirements for Your Horizon Cloud Deployment in Microsoft Azure in the Horizon Cloud Service - next-gen Product Documentation.

Note: This cloud service does change on a regular basis with regular updates to cloud-based components. If you have a deployment of Horizon Cloud Service next-generation with Microsoft Azure infrastructure based on a release different than what is documented for this document, assume that the details in the Horizon Cloud Service – next-gen Product Documentation are canonical.

Horizon Cloud Service – next-gen is primarily a cloud-based service designed to have a minimal footprint in the customer domain. Most of the service configuration is done through the Horizon Cloud Universal Console. A lightweight Horizon Edge Gateway is implemented in a customer-provided Microsoft Azure subscription.   For details on the deployment architecture of Horizon Cloud Service – next-generation, see the Horizon Cloud Service – next-generation Architecture.

To facilitate the functionality of Horizon Cloud Service – next-generation, the service requires connectivity or visibility to various cloud-based resources, in addition to the network ports requirements. These resources are documented in the DNS Requirements for a New Horizon Edge Gateway for Your Horizon Cloud Deployment in Microsoft Azure.

Details on the process or procedure for a user to log in to Horizon Cloud Service and attach to an assigned resource can be found in the Single Sign-on chapter of the Horizon Cloud Services – next-gen Architecture.

The following All Network Ports diagram is a combination of all options in a single diagram.

Figure 1: All network ports for a standard deployment of Horizon Edge Gateway component in a Provider

The All Network Ports diagram describes all supported connection and protocol types.

Client Connections to Horizon Cloud Service next-generation on Microsoft Azure Infrastructure leveraging Azure Private Link Service

You may optionally elect to use the Microsoft Azure Private Link Service to simplify network communications from your end-user resources. Choosing the option to use Azure Private Link Service during Horizon Edge deployment allows you to direct all Horizon desktop and RDS server resources to communicate to the Horizon Control Plane over Azure Private Link. 

Use of Azure Private Link will change the destination of MQTT traffic from the Horizon Agent to Horizon Control Plane. See Figure 2 for details.

Figure 2: All network ports for a standard deployment of Horizon Edge Gateway component in a Provider leveraging Microsoft Azure Private Link Service

The diagram in Figure 2 shows all supported connection and protocol types when using Azure Private Link Service.

Additional Resources

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

• Horizon Cloud Service – next-generation Product Documentation
•  Horizon Cloud Service – next-generation Architecture
• Horizon Support Center
• Omnissa Knowledge Base

Changelog

The following updates were made to this guide:

About the Author and Contributors

This guide was written by Rick Terlep, Staff EUC Technical Marketing Architect, Omnissa, with support and contributions from:

• Graeme Gordon, Senior Staff Architect, EUC Technical Marketing, Omnissa
• Gina Daly, Technical Marketing Manager, EUC Technical Marketing, Omnissa

Feedback

Your feedback is valuable.

To comment on this paper, contact End-User-Computing Technical Marketing at tech_content_feedback@omnissa.com.