This is a high-level list of the steps when you are arriving at your very first cloud-connected pod by running the pod deployer to deploy a pod-manager-based pod into your Microsoft Azure subscription. This pod type is based on the VMware Horizon Cloud pod-manager technology (in contrast to a Horizon pod which is based on Horizon Connection Server software components). After that first cloud-connected pod is fully deployed and you have completed the steps to register Horizon Cloud with the pod's intended Active Directory domain, you can use all the features provided Horizon Cloud, especially for provisioning single-session VDI desktops, multi-session desktops, RDSH-based session desktops, or remote applications to your end users from that pod. When your customer account is configured to use App Volumes features with your pods in Microsoft Azure, you can also provision applications from those App Volumes features and entitle those to your end users.

Note: This workflow is specifically for deploying a Horizon Cloud pod into Microsoft Azure, and not about deploying a Horizon pod in Azure VMware Solution (AVS), which uses the 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.

Perform the following steps when you are deploying your very first cloud-connected pod and you are using the pod deployment wizard in the Horizon Universal Console to deploy the pod into Microsoft Azure.

  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. Verify you 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. Deploy the pod.
  5. Register your Active Directory domain with the deployed pod, 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. In the rare, atypical situation where your tenant environment already has Horizon Cloud pods in Microsoft Azure that are running manifests older than manifest 1600.0, you must give the Horizon Cloud Super Administrators role to an Active Directory group that includes the domain join account as a member. See the topic Assign Horizon Cloud Administrative Roles to Active Directory Groups in the Administration Guide.
  8. Select the type of brokering you want your tenant's pods to use when brokering pod-provisioned resources to your end users. See the topic Introduction to Universal Broker and Single-Pod Brokering and its related topics and subtopics.
    Attention: Completing this brokering selection step before deploying additional pods into Microsoft Azure is a best practice.
  9. Create the required CNAME records in your DNS server. For information about the purpose of these CNAMEs, see How to Obtain the Horizon Cloud Pod Gateway's Load Balancer Information to Map in Your DNS Server. When your tenant is configured with Universal Broker, see also the CNAME record requirements included in 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 Horizon Cloud control plane must be able to communicate with the FQDN specified for the external gateway.
  10. Related to the preceding step, if you select the single-pod broker configuration in that previous step and you plan to use Workspace ONE Access with the pod, then perform these steps:
    • In your DNS server, map a fully qualified domain name (FQDN) to the pod manager's Microsoft Azure load balancer IP address
    • Obtain an SSL certificate based on that mapped FQDN

    You will upload an SSL certificate to the pod that is based on the FQDN that you've mapped to the pod manager's Microsoft Azure load balancer IP address in your DNS so that connections that go to the pod manager VMs will make trusted connections. The Workspace ONE Access Connector that is used when you integrate Workspace ONE Access with the pod in a single-pod-broker configuration must make such a trusted connection. The Workspace ONE Access Connector must connect to the pod using an FQDN that is mapped to the pod manager's Microsoft Azure load balancer IP address.

    Attention: When your environment is configured for single-pod brokering and you are integrating Workspace ONE Access with the pod, you must upload an SSL certificate to the pod and configure your Workspace ONE Access Connector to point to the pod, not to the pod's Unified Gateway Access configurations.

    However, bear in mind that when you have uploaded an SSL certificate based on your DNS-mapped FQDN, if you try to connect by directly typing that FQDN into a browser — not going through a properly configured Workspace ONE Access — that pure FQDN use will appear as untrusted connections to the browser. The reason is because simply loading that FQDN into a browser is a connection using HTML Access (Blast), and that is how HTML Access (Blast) behaves. As a result, when you load that FQDN into a browser, it displays the typical untrusted certificate error.

    In the absence of having Workspace ONE Access in this type of configuration, to have connections using HTML Access (Blast) — using a browser basically — avoid the displayed untrusted certificate error, you must put a gateway configuration on the pod and have those connections use the load balancer and Unified Access Gateway instances from that gateway configuration. If you do not want to expose your FQDN to the Internet, you can deploy an internal Unified Access Gateway configuration. This internal Unified Access Gateway configuration uses a Microsoft Azure internal load balancer to which end users who are internal to your corporate network can make their connections.

  11. Upload an SSL certificate to the pod directly, using the pod's summary page in the administrative console, if you plan to have one or both of the use cases described in the preceding step. See Configure SSL Certificates on the Horizon Cloud Pod's Manager VMs.
    Tip: If the only access use case you will ever want to support is where connections will go to the pod's Unified Access Gateway instances through the load balancer connected to those instances, then uploading the SSL certificate to the pod directly is superfluous. Still, performing the immediately preceding step above and this step here is a recommended practice, because it ensures that if you do one day give out that FQDN to users to enter in their Horizon Clients, those clients can have trusted connections. Performing the immediately preceding step and this one here also provides you the ability to one day more quickly integrate the pod in a single-pod-broker environment with Workspace ONE Access because you would have the FQDN mapped and the SSL certificate already in place on the pod.
  12. Optional: If your Horizon Cloud tenant account is not already onboarded with the VMware Cloud Services Engagement Platform, consider onboarding it now. Onboarding to the VMware Cloud Services Engagement Platform is a prerequisite to activating the Horizon Infrastructure Monitoring features for your pods deployed in Microsoft Azure. See Onboard Your Horizon Cloud Tenant to VMware Cloud Services Engagement Platform Using the Cloud-Based Console.
  13. Optional: Activate Horizon Infrastructure Monitoring. A prerequisite to this activation is that your Horizon Cloud tenant must be onboarded to the VMware Cloud Services Engagement Platform. See Horizon Infrastructure Monitoring and the Pods in Your Horizon Cloud Environment.
  14. 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.
  15. Depending on the type of end-user assignment the image is ultimately intended for, perform one or more of the following steps as appropriate.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. When a pod is deployed to have RADIUS two-factor authentication for the pod's gateways, you must complete the following tasks:
    • If you configured an external gateway with RADIUS settings and that RADIUS server is not reachable within the same VNet as used by the pod, or within the peered VNet topology if you deployed the external gateway into its own VNet, verify, configure that RADIUS server to allow client connections from the IP address of the external gateway's load balancer. In an external gateway configuration, the Unified Access Gateway instances attempt contact with the RADIUS server using that load balancer address. To allow the connections, ensure the load balancer resource's IP address that is in that external gateway's resource group is specified as a client in your RADIUS server configuration.
    • If you configured an internal gateway, or an external gateway and your RADIUS server is reachable within the same VNet as used by the pod, configure the RADIUS server to allow connections from the appropriate NICs that were created in the gateway's resource group in Microsoft Azure that must communicate with the RADIUS server. Your network administrator determines the RADIUS server's network visibility to the pod's Azure Virtual Network and subnets. Your RADIUS server must allow client connections from the IP addresses of those gateway NICs that correspond to the subnet for which your network administrator has given network visibility to the RADIUS 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 goes through an update. To support connectivity between the gateway and the RADIUS server both for ongoing pod operations and after each pod update, ensure the IP addresses of those four NICs are specified as clients in the RADIUS server configuration.

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

After the above workflow steps are completed, your end users can use the Horizon Client or Horizon HTML Access (the web client) to launch their entitled desktops and remote applications:

  • In an environment configured with Universal Broker, by using your Universal Broker brokering FQDN in their client.
  • In an environment configured with single-pod brokering, by using your FQDN in their client, the one you mapped using the CNAME records in your DNS.

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