Use the following information and the linked-to articles when preparing to use Horizon Cloud and during your use. Refer back to this information throughout your journey using Horizon Cloud.

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.

For connections to your Horizon pods, review the set-up prerequisites before you start. See the following documents:

Software downloads
Review the software downloads you might want for your environment from My VMware ®. 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. See the VMware Horizon Cloud Service download page, locate the most recent service release date, and navigate to its downloads link. Within that same page, you will 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 VMware Universal Broker Plugin installer. For a table of which version of VMware 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 VMware Dynamic Environment Manager™ with folder redirection. You can download the Dynamic Environment Manager software that is supported for use with this release from the VMware Horizon Cloud Service download page and navigate the downloads link for this specific release.
Product documentation and additional helpful resources

To access all of the product documentation for the various deployment models of Horizon Cloud, see the VMware Horizon Cloud Service documentation landing page.

Visit the community site for helpful tips and to ask any questions. Technical papers are also available in the Resources section of the Horizon Cloud product page.

Useful Facts to Know Before Using Horizon Cloud

Before doing any deployment type
  • When your Horizon Cloud environment is not integrated with your Workspace ONE environment, login authentication into the cloud-based console relies on My VMware account credentials. If the My VMware account system is experiencing a system outage and cannot take authentication requests, you will not be able to log in to the console during that time period. If you encounter issues logging in to the console's first login screen, check the Horizon Cloud System Status page at https://status.horizon.vmware.com 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 DNS, Ports, and Protocols Requirements When Using Horizon Cloud Connector and a Horizon Pod, DNS Requirements for a Horizon Cloud Pod in Microsoft and Related Service Features, and Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later 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 VMware Cloud 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) that is connected to the node's temporary jump box VM and pod manager VM (or plural VMs for the case where high availability is enabled on the pod). Proxy-based authentication is supported in this release. 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 DNS Requirements for a Horizon Cloud Pod in Microsoft and Related Service Features 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
  • If your Horizon Cloud tenant account was created on or after March 17, 2020 in one of the following regions: US-2, Europe-2, Australia-2 (also formerly known as PROD1_NORTHCENTRALUS2_CP1, PROD1_NORTHEUROPE_CP1, PROD1_AUSTRALIAEAST_CP1), you must use Horizon Cloud Connector version 1.6 or later to connect those pods to Horizon Cloud. The date on your Welcome to Horizon Cloud Service email is the date to use to determine if your tenant account was created after March 17, 2020. The email also states the region in which your account is created. Earlier versions of the Cloud Connector will have compatibility issues when used with tenant accounts created on or after March 17, 2020 in those regions.
  • 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 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 VMware Cloud 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 VMware Cloud 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 VMware customer account representative, some of the system's operational emails will by default include the email addresses of those designated VMware customer account representatives in the BCC field. The purpose for including the VMware customer account representatives in these emails' BCC field is to ensure better onboarding and business continuity.

The operational emails that will include the VMware 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.