In part 1 of this blog series, I introduced the Horizon Cloud Service on Microsoft Azure and covered many commonly used terms. In part 2 of the blog series, I will be walking through the steps that need to be performed in Microsoft Azure prior to connecting it to the VMware Horizon Cloud Service.
The process is pretty simple, but there are a few things that you need to do first in Microsoft Azure:
- Have an Active Microsoft Azure Subscription
- Create a Service Principle to allow Horizon Cloud Service to communicate with your Azure Subscription
- Configure the underlying networking in your Azure subscription (create VNet, DNS and AD).
Let’s look at these in turn;
Azure Subscription Cores/Capacity
You can use Horizon Cloud Service with an Enterprise-level Azure subscription, or a simple pay-as-you-go agreement. It really doesn’t matter what you use – however, what you do need is sufficient virtual machines (VMs) and VM cores of specific families to be available in the region(s) in which you want to deploy a Horizon Cloud Service Node.
In summary, you require:
- 1x F2 Standard (2 cores) for the jump box that helps build out the environment
- 2x D2v2 (2 cores each) for the node itself
- 4x A2v2 (2 cores each) for the Unified Access Gateway’s
- Additional Dv2 cores or NV cores as needed for desktop/server capacity
Providing that your subscription has the above cores available in the region(s) you wish to deploy, then the node buildout will be possible. See Microsoft Azure Virtual Machine Requirements for a Horizon Cloud Node for more details.
To check the cores that you have available, log in to your subscription and click the Subscriptions menu item; 
Select Subscriptions -> Select subscription -> Select Usage + Quotas
Then, on the resulting page, you can see all the items that are being used. This can be filtered to just show a specific region if required.
In the example below, you can see that Dv2, Av2 and F series VMs all have sufficient core capacity. VMs, virtual networks (VNet) and regional cores values all look good. So, this particular subscription can be used with Horizon Cloud Service.
If you need to extend the current cores count in your subscription, you can do so by clicking the Request Increase button in the upper right area of this screen:
Increasing the core count is usually pretty quick, but can take longer if you are asking for a significant size increase. For our testing in our development environments, we have typically seen the cores being increased within an hour or so.
Note that when you come to add the Horizon Cloud Service Node, the service will automatically check that the subscription has sufficient capacity available to deploy and will alert you if anything is insufficient to deploy.
Azure Service Principle
A service principle is used to allow Horizon Cloud Service to make API calls against Microsoft Azure to create and manage objects in Azure (e.g. create a VM). Once the service principle is created, the credentials are entered into Horizon Cloud Service to allow it to control this (see below).
This section of the user docs, Create the Required Service Principal by Creating an Application Registration, does a really good job of walking through the steps and only takes a couple of minutes to complete. For customers that I have helped in the last few months since the launch of the service, the most common mistake here has been to miss assigning the contributor permission to the service principle.
Once completed you will have four values. All of these are GUIDs (numbers/strings that look like this: e6a41e39-8d23-43c0-a187-0766fa50a202).
- Subscription ID
- Directory ID
- Application ID
- Application Secret
Keep these values handy, as you will need these later when you first start to use Horizon Cloud Service to connect it to your Azure subscription.
Azure Networking
Ensure a VNet exists in the region in which you are going to deploy the node, and that the VNet meets the requirements for a Horizon Cloud Node. If you do not have an existing VNet, create one that meets the requirements. See Configure the Required Virtual Network in Microsoft Azure for detailed steps.
One tip when creating the VNet is to ensure that you set the address space as large as possible. This helps avoid fragmented address spaces. Also, if you decide to peer your VNet with another, the address space cannot be extended once peered; so, it is much easier to get this right up front.
Next, you need to make sure that DNS is configured within your environment. To build out the node, you just need an externally accessible DNS (e.g. 8.8.8.8) since vmware.com and microsoft.com have to be resolved. However, once you start performing AD authentication, you will also need an internal DNS. As such, it is recommended that you create the DNS internally and make sure that it is accessible. Once deployed, add the DNS address to the VNet configuration.
This can be done from Azure portal by clicking Virtual Networks -> selecting your VNet (in the example below its vmw-hcs-vnet-eastus, but your VNet is likely called something else) -> DNS Servers -> add the IP of your DNS servers as required.
The image below shows two example DNSs being added: 192.168.0.15 and 8.8.8.8.
Note if you change the DNS Server configuration on a VNet, then any VMs connected to that VNet will need to be restarted before the new DNS servers added start being used.
The easiest way to test this is working is to deploy a Linux machine (e.g. Ubuntu) onto the VNet and check that you can resolve other machines on your network. For example, try:
(changing values to match your environment)
Also, at this time it is a good opportunity to check that outbound network access is available. From the same temporary machine, try:
If ping is blocked on your environment, you could use the dig command instead. e.g.:
The last thing to check at this stage is that you can access the required ports externally from the network. Horizon Cloud Service requires these ports to be opened externally; 80, 443 and 11371.
If you deployed a Linux test machine, an easy way to test this is to use the netcat ‘nc’ command. You can test like this and validate that each port can connect okay:
I have seen some customers with firewalls or Network Security Groups (NSGs) that are configured causing these ports to be blocked. If the ports are not opened, then deployment of the Horizon Cloud Node will not be possible.
Once DNS and networking are working, you will also need an Active Directory to be available on the networks. Technically you don’t need it at this stage, but the whole process will go much smoother if you can have it ready now. There are various options for building and using Horizon Cloud Service with Microsoft Azure. The simplest option can be to deploy an island Active Directory in Microsoft Azure – however, many organizations will want to connect (or sync) to an Active Directory running on-premises. For a really great in-depth look at the options available, check out my white paper here: Networking and Active Directory considerations on Microsoft Azure for use with VMware Horizon Cloud Service.
The above steps outline performance requirements in Microsoft Azure prior to being able to deploy the Horizon Cloud Service Node. These really don’t take much time to complete, but depending on the complexity of your organization’s networking rules for Microsoft Azure, you may need to spend some time to get this right – perhaps discussing with various teams within your organization. Once this is correct, adding the Horizon Cloud Service Node will be quick and simple. Check out the Getting Started Guide for more detail if required.
In the next part of this blog series, I will take you through the steps to get the Horizon Cloud Service Node deployed and up-and-running.
Stay tuned for updates on VMware Horizon Cloud by subscribing to our blog, and following us on Twitter and Facebook.
