First-Gen Tenants - Things to Know About Horizon Cloud and the Horizon Control-Plane Services

Use the following information and the linked-to articles when preparing to use first-gen Horizon Cloud or first-gen Horizon control-plane services, while onboarding your pods, and during day-to-day use.

Important: Use this page solely when you have access to a first-gen tenant environment in the first-gen control plane. As described in KB-92424, the first-gen control plane has reached end of availability (EOA). See that article for details.

Set-Up Prerequisites, Software Downloads, User Settings Persistence, Product Documentation, and Additional Helpful Resources

• Set-up prerequisites

  For Microsoft Azure deployments, review the set-up prerequisites before you start deploying.

  • Horizon Cloud on Microsoft Azure Requirements Checklist
  • First-Gen Tenants - Preparing to Deploy a First-Gen Horizon Cloud Pod on Microsoft Azure

  For onboarding your Horizon pods for cloud-plane services including the license service, review the descriptions of the type of deployment architecture your pod is using and the onboarding guidance. Refer to the information in the following locations:

  • First-Gen Tenants - Onboarding a Horizon Pod to Use First-Gen Horizon Control Plane Services with That Pod - for onboarding Horizon pods to the cloud plane.
  • Tech Zone's Horizon 8 Reference Architecture information.
  • Horizon 8 Installation and Release Notes documentation, located at Horizon 8 Documentation.

• Software downloads

  Review the software downloads you might want for your environment from Customer Connect.

  Even though these downloads might be optional to have before you get started with your particular deployment, depending on your use case scenario, you might want to review them prior to deploying.

  In Customer Connect Downloads area, locate the Horizon Service row and view its download components. Within that page you'll see the Horizon Cloud Connector row and can click on its Go to Downloads to obtain the latest versions of both the Horizon Cloud Connector and Universal Broker Plugin installer.

  For a table of which version of Universal Broker Plugin Installer goes with which Horizon Connection Server, see the table in the topic Horizon Pods - Install the Universal Broker Plugin on the Connection Server.

• User settings persistence

  For all Microsoft Azure deployments, you can provide persistence of user profiles using Dynamic Environment Manager™ with folder redirection. You can download the Dynamic Environment Manager software that is supported for use with this release from within Customer Connect. Within Customer Connect, navigate to the Downloads area, locate the Horizon Service entry and view its download components. Within that page you'll see the Horizon Cloud on Microsoft Azure row and can click on its Go to Downloads to locate the Dynamic Environment Manager software for this release.

• Product documentation and additional helpful resources

  To access all of the product documentation for the various deployment models, see the First-Gen Horizon Cloud documentation page.

  Visit the Horizon Cloud community within the Omnissa community site for helpful tips and to ask any questions.

Useful Day-0 Facts to Know

• Before doing any deployment type

  • Login authentication into the first-gen console relies on authenticating account credentials with the Cloud services platform. If that service is unable to complete the necessary authentication requests, logging into the console fails. If you encounter issues logging in to the console's first login screen, check the status page to see the latest system status. On that page, you can also subscribe to receive updates.
  • When deploying a pod using the console's pod deployer wizard and when connecting a Horizon pod using Horizon Cloud Connector, specific DNS names must be reachable and specific ports and protocols must be allowed. See First-Gen Tenants - DNS, Ports, and Protocols Requirements When Using Horizon Cloud Connector and a Horizon Pod, First-Gen Tenants - Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names, and First-Gen Tenants - Horizon Cloud Pod - Ports and Protocols Requirements for the connectivity requirements.
  • Each of the pods paired with the Horizon Cloud control plane and associated with the same customer account must have line of sight to the Active Directory domains connected to those pods and have one-way or two-way trust configured along with that line of sight. For example, when you have three pods where one pod is in Microsoft Azure, one pod is on-premises, and one pod in VMC on AWS, each of those pods must have line of sight and one-way or two-way trust configured to the same set of Active Directory domains.

• Before doing Microsoft Azure deployments

  • Subscriptions and Number of Pods: Be mindful about the number of pods you deploy into a single Microsoft Azure subscription, especially if you plan to have each pod running at a large scale. Even though multiple pods can be deployed into a single Microsoft Azure subscription, whether all into one region or spread across multiple regions, Microsoft Azure imposes certain limits within a single subscription. Because of those Microsoft Azure limits, deployment of many pods into a single subscription increases the likelihood of hitting those limits. Numerous variables, and combinations of those variables, are involved in reaching those limits, such as the number of pods, the number of farms and assignments within each pod, the number of servers within each pod, the number of desktops within each assignment, and so on. If you plan to have pods running at a large scale, consider adopting the approach of having multiple subscriptions with those multiple subscriptions under one Microsoft Azure account. Microsoft Azure customers can, and often prefer, this approach because it provides some benefits for ongoing management of the subscriptions. Using this approach, you would deploy a single pod per subscription, roll up those subscriptions in a single "primary account", and avoid the chances of hitting the Microsoft Azure limits that are imposed on a single subscription.
  • Outbound Internet access is required on the Microsoft Azure Virtual Network (VNet) used by the deployment's pod manager VMs. Proxy-based authentication is supported for a Horizon Cloud on Microsoft Azure deployment. You must provide your proxy details in the pod deployment wizard. For pod deployment, specific DNS names must be reachable and specific ports and protocols must be allowed. See First-Gen Tenants - Horizon Cloud on Microsoft Azure Deployments - Host Name Resolution Requirements, DNS Names for the connectivity requirements.
  • Subnet sizing: Expanding the size of the pod's subnets after the pod is deployed is not currently supported. As a result, for production environments, you should use subnet sizes that are large enough to accommodate the following requirements:
    • Management subnet: When deploying a pod, as of March 2019, the pod's management subnet is required to have a minimum of CIDR /27, where in previous releases a lower minimum CIDR of /28 was allowed. This change was made to reduce the occurrence of issues that can happen during pod updates due to lack of available IP addresses in the subnet. A CIDR of /27 provides for 32 IP addresses.
    • VM subnet - primary: Use a CIDR in a range that is large enough to accommodate attaching the VMs for your anticipated VDI desktops, the RDS images, and every VM in the pod's RDS farms. The pod manager VMs and the Unified Access Gateway VMs also need some IP addresses from this subnet (12 addresses total to accommodate the blue-green update of an HA-enabled pod with both types of gateways). Generally speaking, the range of /24 to /21 would provide for typical use cases. Note: At times, this VM subnet is referred to as the desktop subnet or the tenant subnet.
    • Starting with service release July 2020 and pod manifest 2298.0, a new feature provides for using additional tenant subnets for your VDI desktops and RDS farm VMs. Those additional subnets can be in the same VNet as the pod or in peered VNets. For a pod at manifest 2298.0 or later, you can edit the pod's configuration to include those additional subnets. Then you can specify use of those additional tenant subnets in the definitions of your farms and VDI desktop assignments instead of them using the primary VM subnet. Use of these secondary subnets for your farm VMs and VDI desktop VMs provides for simplified administration, because you can specify which farms and VDI desktop assignments are on which tenant subnet and VNet.
  • To leverage the feature to deploy the external gateway into its own VNet, the VNets must be peered. As a result, you must create the subnets manually in advance of running the deployment wizard. For the external gateway's VNet, its management subnet and back-end subnet must each adhere to the same minimum CIDR /27.

• Before connecting pods using Horizon Cloud Connector

  • New deployments should download and use the latest version of Horizon Cloud Connector that is available at Customer Connect and which is compatible with the pod's Horizon Connection Server software version. Using the latest version ensures you have the most recent fixes and improvements. For the compatibility matrix between Horizon Cloud Connector and Horizon Connection Server, visit Product Interoperability Matrix and check interoperability between the two solution names like Horizon Cloud Connector and Horizon.
  • Outbound Internet access is required for the Horizon Cloud Connector to communicate with the service's cloud plane, especially to receive the licensing details. Specific DNS names must be reachable and specific ports and protocols must be allowed. See First-Gen Tenants - DNS, Ports, and Protocols Requirements When Using Horizon Cloud Connector and a Horizon Pod for the connectivity requirements.
  • Before connecting a second Horizon pod to Horizon Cloud, you should log in to the Horizon Cloud administrative console and complete the Active Directory domain registration process after connecting your first Horizon pod using the Horizon Cloud Connector's onboarding process. If you pair multiple Horizon pods with Horizon Cloud before completing that Active Directory domain registration, unexpected results might occur when you eventually log in to the console to attempt the domain registration process.
  • Due to a known issue, when you are using an on-premises Active Directory domain to service a pod in VMC on AWS, slow access times might occur due to network latency or network congestion between that on-premises Active Directory domain and the pod in VMC on AWS which results in calls to the domain timing out. Symptoms of this latency typically include the Active Directory login screen failing to complete the login before timing out. If you experience such symptoms, configuring a writable domain controller in each in-cloud software-defined data center (SDDC) might help.

About Some of the Service's Operational Emails

Starting with the April 2021 service release, for every customer record that is associated with a designated Horizon Cloud customer account representative, some of the system's operational emails will by default include the email addresses of those designated customer account representatives in the BCC field. The purpose for including the Horizon Cloud customer account representatives in these emails' BCC field is to ensure better onboarding and business continuity.

The operational emails that will include the Horizon Cloud customer account representatives in the BCC field are:

• At the initial creation of your customer record for the service, a customer name and email address is specified as Owner in the newly created customer record. A welcome email is sent to the email address associated with that Owner customer name.
• When any updates occur related to that Owner — such an updated email address — a notification email is sent.
• When any updates occur related to the customer record's Horizon licenses, a notification email is sent.