Welcome back to part 2 of my article series on how to master VMware Horizon Cloud on Azure. In the first part I gave a general overview on what the service actually represents and how it can be seen especially in the Azure Virtual Desktop ecosystem. Now we’re proceeding to a more technical blog, describing how to prepare our environment before we can start to create desktops.
There are actually quite a couple of things, that you need to ensure before we can start.
Table of Contents
Create a Horizon Cloud on Azure trial for 60 days
Before we dig deeper into the deployment of Azure resources, you should ensure to get a free 60-day trial which we offer to evaluate VMware Horizon with a Universal subscription. To get your trial, navigate to 60-Day Trial of Horizon Service (vmware.com)
And fill out the form at the end of the page.
Create an Azure subscription
As a starting point we need to ensure to have the credits in place to create virtual machine and build out our landing zone. To do so, we need to own an Azure subscription, which you need to organize prior to continue to build out the infrastructure.
If you don’t have an Azure subscription yet, Microsoft offers a credit of 200$ (approx. 175€) as a great way to start and evaluate the solution. In addition Microsoft offers popular services free for the first 12 months.
You can sign up for a trial subscription here: Create Your Azure Free Account Today | Microsoft Azure
Other than that, any type of Azure subscription (Pay-As-You-Go, CSP, Enterprise Agreement, Sponsorships) can be used to continue with the infrastructure.
Naming convention for your Azure resources
With full honesty, in my lab environments I sometimes don’t really take care of naming conventions, but this time we’ll do this different. For the infrastructure we will follow Microsoft’s best practices in terms of naming conventions.
Microsoft recommends the following definition of resources:
Which would mean, that for a virtual network, that we’re about to create, we introduce the following convention:
Tip! For smaller environments, like our dedicated Horizon Cloud environment, it might not bring any value mentioning the region in which the resources are deployed in, because that’s obvious from the Azure Portal or PowerShell. This is something you can also remove from the naming convention (e.g. vnet-dmz-prod-001).
As described earlier, we will follow the Microsoft standard as our infrastructure is hosted on Azure so I will follow the example stated below the picture. If you’re interested in learning more about naming conventions, check out this document: Define your naming convention – Cloud Adoption Framework | Microsoft Docs
Creation of the Virtual network/s
In order to prepare network communication within our new environment, we need to have at least one network in place. As we will deploy a single POD infrastructure in first sight, but want to keep the communication to the outside world as secure as possible, we will need to create two virtual networks, one acting as DMZ network for our UAGs and one for the Horizon Cloud infrastructure, Domain Controllers, virtual desktops. To establish a communication between the two mentioned networks, we need to peer them.
A schema of my infrastructure in this workshop can be found below:
To start with the connectivity resources, we will first navigate to Resource Groups in the Azure Portal to create a dedicated place for our virtual networks. This helps to keep a better structure of the components. To do so use the search bar in the Azure portal (https://portal.azure.com) and search for “Resource Groups“. The video below shows you how to create the RG with the correct naming.
As we will place both the DMZ and Internal Network into this RG we will call it: rg-vnet-prod-westeurope-001
Now we use the Azure Portal to navigate to our Virtual Networks to create the DMZ network with the following specifications:
Resource Group: rg-vnet-prod-westeurope-001
Region: West Europe
Proceed by clicking on Next: IP Addresses >
In here, we need to create our IPv4 address space for the overall VNET. We want to keep the network as small as possible, therefor we define a CIDR /26 network. If you might wonder, why I didn’t choose a smaller network, this is especially due to the VMware recommendations, that the DMZ subnet for UAGs shouldn’t be larger than /27. A /27 subnet allows for 32 IPs from which 5 are taken by Azure for reserved addresses.
IPv4 address space: 10.0.0.0/26
Subnet name: snet-dmz-prod-westeurope-001
Subnet address range: 10.0.0.0/27
When all settings are applied correctly, click on “Add” and continue on Next: Security.
This page allows for setting security options like enabling a Bastion Host network, DDoS protection or an Azure Firewall to be deployed. We don’t want this at that stage and continue to Next: Tags or directly to Review + Create if you don’t want to provide tags.
Lastly, we review the the settings and click on create to confirm the VNet creation.