This workflow describes the high-level sequence in the first-gen Horizon Universal Console starting from deploying a pod-manager-based pod to configuring virtual desktops and apps. The sequence ends with your end users launching their entitled virtual desktops and apps.

Important: This information applies 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.
Note: This workflow is specifically about a pod based on the pod-manager technology for Horizon Cloud on Microsoft Azure, and not about deploying a Horizon pod using Horizon Connection Server technology.
Important: The administrative console is dynamic and reflects what is available at the current service level. However, when you have cloud-connected pods that are not yet updated to the latest levels of the pod's software, the console does not display those features that depend on the latest pod software level. Also, in a particular release, Horizon Cloud might include separately licensed features or features that are only available for particular tenant account configurations. The console dynamically reflects the elements related to such features only when your license or tenant account configuration includes use of such features. For examples, see Tour of the Cloud-Based Console Used for Administrative Tasks in Horizon Cloud.

When you are expecting to see a feature in the administrative console and do not see it, contact your VMware account representative to verify whether your license and tenant account configuration entitles its usage.

  1. Fulfill the prerequisites. See VMware Horizon Cloud Service on Microsoft Azure Requirements Checklist For New Pod Deployments.
  2. Perform the preparatory tasks outside of Horizon Cloud. See Preparing to Deploy a Horizon Cloud Pod into Microsoft Azure.
  3. Meet the DNS, ports, and protocol requirements for deploying the pod. See DNS Requirements for a Horizon Cloud Pod in Microsoft Azure and Ports and Protocols Requirements for a Horizon Cloud Pod at the September 2019 Release's Manifest or Later.
  4. Log in to the Horizon Universal Console and run the wizard to deploy the pod.
  5. Register your Active Directory domain with the Horizon Control Plane, which includes providing the names of service accounts. Ensure these service accounts meet the requirements described in Service Accounts That Horizon Cloud Requires for its Operations
  6. Assign the appropriate roles to individuals in your organization for authenticating to and performing operations in the administrative console. There are two types of roles that are used in Horizon Cloud. See Best Practices about the Two Types of Roles You Give to People to Use the Cloud-Based Console to Work in Your Horizon Cloud Environment.
  7. Complete the Universal Broker configuration for your tenant. See Configure the Universal Broker Settings.
  8. Create the required CNAME records in your DNS server. For information about the purpose of these CNAMEs and CNAME record requirements for Universal Broker, see How to Obtain the Horizon Cloud Pod Gateway's Load Balancer Information to Map in Your DNS Server and Configure the Universal Broker Settings.
    Note: When you have the external gateway configuration using a private IP address for the configuration's Azure load balancer, then you must have a firewall or NAT managing Internet traffic to that private IP address, and that firewall or NAT must provide a public IP address and be configured such that the FQDN specified when deploying the external gateway configuration is publicly resolvable. The control plane must be able to communicate with the FQDN specified for the external gateway.
  9. Optional: If your Horizon Cloud tenant account is not already onboarded with the VMware Cloud services engagement platform, consider onboarding it now. See Onboard Your Horizon Cloud Tenant to VMware Cloud Services Engagement Platform Using the Cloud-Based Console.
  10. Create a golden image. Creating a golden image is a multi-step process. For a high-level overview of the various ways of creating a golden image that can be used in your Horizon Cloud tenant, see Creating Desktop Images for a Horizon Cloud Pod in Microsoft Azure. Creating a golden image starts with importing a base VM, which you then customize for your business and end-user needs.
  11. Depending on the type of end-user assignment for which the image is ultimately intended, perform one or more of the following steps as appropriate.
  12. Convert that image into an assignable image, also known as sealing or publishing the image. See Convert a Configured Virtual Machine to an Assignable Image.
  13. To provision session desktops and remote applications from a published multi-session image:
    1. Create a desktops farm to provide session desktops, and then create assignments to entitle end users to use those desktops. See Create a Farm and Create an RDSH Session Desktop Assignment.
    2. Create an applications farm to provide remote applications, add the applications to your application inventory, and then create assignments to entitle end users to use those remote applications. See Create a Farm, Import New Remote Applications from RDSH Farms, and Create a Remote Application Assignment.
  14. To provision single-session VDI desktops from a published single-session VDI desktop image, create a dedicated or floating VDI desktop assignment. See About Desktop Assignments for Your Horizon Cloud Environment's Pods in Microsoft Azure and its section about creating these desktop assignments.
  15. To provision App Volumes applications to your end users, add the App Volumes applications to your application inventory and create an application assignment to entitle end users to use those applications. Then create a desktop assignment entitle those end users to the base desktops in which they can use those applications. The application assignment entitles use of the user's entitled App Volumes applications within the Windows operating system of the user's entitled desktop. See App Volumes Applications - Overview and Prerequisites.
  16. When your deployment has a two-factor authentication configuration, you must complete the following tasks:
    • If the pod's external gateway has two-factor authentication configured and the two-factor authentication server is not reachable within the same VNet topology into which the gateway's Unified Access Gateway instances are deployed, configure that two-factor authentication server to allow communication from the IP address of the external gateway's load balancer.

      In this scenario where the two-factor authentication server is not reachable within the same VNet topology as the gateway deployment, the Unified Access Gateway instances attempt contact with that server using that load balancer address. To allow that communication traffic, ensure the load balancer resource's IP address that is in that external gateway's resource group is specified as a client or a registered agent in your two-factor authentication server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

    • If your two-factor authentication server is reachable within the same VNet topology, configure the two-factor authentication server to allow communication from the appropriate NICs that were created for the deployment's Unified Access Gateway instances in Microsoft Azure.

      Your network administrator determines the two-factor authentication server's network visibility to the Azure VNet topology and its subnets used for the deployment. The two-factor authentication server must allow communication from the IP addresses of the Unified Access Gateway instances' NICs that correspond to the subnet for which your network administrator has given network visibility to the two-factor authentication server.

      The gateway's resource group in Microsoft Azure has four NICs that correspond to that subnet, two that are currently active for the two Unified Access Gateway instances and two that are idle and will become the active ones after the pod and its gateways go through an update.

      To support communication traffic between the gateway and the two-factor authentication server both for ongoing pod operations and after each pod update, ensure the IP addresses of those four NICs are specified as clients or as registered agents in that server's configuration. Refer to the documentation for your two-factor authentication server for the specifics on how to allow that communication.

    For information on how to obtain those IP addresses, see Update Your Two-Factor Authentication System with the Required Horizon Cloud Pod Gateway Information.

After the above workflow steps are completed, give your Universal Broker brokering FQDN to your end users. They use that brokering FQDN in their Horizon Client or Horizon HTML Access (the web client) to launch their entitled desktops and remote applications.

You can find in-depth details on how to accomplish each workflow step in the topics that are linked from each step above.