Quick Links

Part 1 – Azure Environment Preparation

Part 2 – Deploy Horizon Cloud Infrastructure (This Post)

Part 3 – Configure General Settings

Part 4 – Deploy Windows 10 Multi-Session Host Image

Background

Following on from Part 1, Azure Environment Preparation, I take a look at the steps required to deploy the Horizon Cloud Infrastructure into Azure.

It is worth noting that to have access to the Horizon Cloud services, you need to have a Horizon Universal License. This gives you the flexibility to run Horizon in any supported environment. Be that Horizon on Azure, AWS, IBM cloud, or running Horizon on-premises with an existing VMware vSphere environment. The beauty of this is that with the single license, you can run workloads in all locations simultaneously if you wish, as long as the number of users accessing the platform is covered by the license. The universal license provides a lot of the functionality available in Enterprise licensing and more. Check out what is available here. Dynamic Environment Manager for profile management and App Volumes for dynamic application delivery are still included.

Deployment

When you purchase universal licenses, access to the Horizon Cloud portal will be created as part of the procurement process. Once logged in, we need to follow the steps below to deploy a Horizon environment on Azure.

What is deployed?

If you check out the following link, there is an extract that details the minimum required components to be deployed.

Minimum Microsoft Azure capacity available for Horizon Cloud infrastructure in addition to the expected desktop and app workload. Note that as long as this capacity is made available, Horizon Cloud will automatically deploy these VMs and no manual installation is required.

• Pod Deployment Engine, also known as the Jump Box (transient) — 1 x Standard_F2
• Pod/Pod Manager with High Availability enabled — 2 x Standard_D4_v3 (if no Standard_D4_v3 in the region, 2 x Standard_D3_v2)
• Pod/Pod Manager without High Availability enabled — 1 x Standard_D4_v3 (if no Standard_D4_v3 in the region, 1 x Standard_D3_v2)
• Microsoft Azure Database for PostgreSQL Service — Generation 5, Memory Optimized, 2 vCores, 10 GB Storage
• External Unified Access Gateway (optional, unless no internal gateway is specified) — 2 x Standard_A4_v2 or 2 x Standard_F8s_v2
• Internal Unified Access Gateway (optional, unless no external gateway is specified) — 2 x Standard_A4_v2 or 2 x Standard_F8s_v2

Armed with the information above, you can work out roughly how much the service will cost to run by using the Azure Cost Calculator.

For this deployment, we will be using the Deployment Engine, Pod Manager with HA, PostgresSQL service, and External Unified Access Gateway x 2.

Deployment process

Once logged into the Horizon Cloud Portal, click to add cloud capacity.

Choose Microsoft Azure.

Now we need to add Azure Capacity. If part 1 of this blog series, we ran through creating the Azure Subscription, service principal account etc and I said make a note of the long GUID that is created for each item. They are required here. Give the subscription a name to identify it in the Horizon Cloud Portal, choose the appropriate Azure environment. Azure China and Azure DOD are options as well.

If you would like to the external UAG devices can decide in a separate Azure subscription. You may wish to do this for complete separation.

Once we are hooked into the Azure subscription, let’s create a new Horizon POD. The main thing to watch out for in step 1 here is to ensure that the Azure region is set the same as the resources that were configured in part 1, otherwise, the VNET and subnets will not show up for use.

Leaving High Availability enabled will deploy two pod managers and make use of Azure Availability Sets to ensure HA within the region. So Horizon should not go down if one datacentre goes down for any reason within an Azure zone.

In step 2 below, choose the correct VNET and then choose to use an existing subnet. Select the infrastructure and Desktop subnets as defined previously.

Finally, in step 3, choose an NTP server that makes sense to you.

Now to configure the Unified Access gateways. Create an FQDN that the company will use to access this service. The FQDN has to match the certificate that will be added in step 2. Later on if the setup process we will create a broker URL. Ensure the FQDN defined here is not the same as the broker URL.

In part 3 of the blog series, I will cover how to map the FQDN to the IP address to allow external access to the service.

The certificate has to be in PEM format and it can not be password protected. It should contain the full certificate chain. I used a wild card certificate without any issues.

In step 3, use the DMZ subnet we defined earlier.

What I did find a little disappointing is the two-factor authentication only supported RADIUS or VMware Identity Manager integration. I did not see any native SAML V2 integration. Something to investigate further.

Once the setup has passed the validation step, verify everything looks correct and click submit.

This will take you back to the main page and show that the pod is deploying on Azure.

If you switch to Azure, the jump box is the first resource deployed. This is a transient VM and only exists during the initial deployment or update process of the Horizon environment.

Once the deployment is complete, the two UAG servers and the pod management servers will be deployed along with all the other associated components such as preconfigured network security groups, key vaults etc.

The availability set rules are shown below for the pod managers.

Everything should show as complete when done.

In part 3, I will look at integrating the Horizon environment with Active Directory in readiness for deploying a Windows 10 multi-session host.

Further Reading

Part 1 – Azure Environment Preparation

Part 2 – Deploy Horizon Cloud Infrastructure (This Post)

Part 3 – Configure General Settings

Part 4 – Deploy Windows 10 Multi-Session Host Image