by David Brett, CTP
If, like me you have a home lab set up to test and learn then you will have probably been in the situation where you run out of compute. You then start looking at what you can shut down, delete or de-commission. This can be a massive pain, and whilst I know I need to buy some more hardware I currently can’t justify that to the boss at home so I started to think of other ways to get a larger home lab.
Enter Microsoft Azure. I have an active MSDN subscription with Microsoft and as part of that I get £95 per month of free compute in the Azure Cloud. This is great but instead of running 2 domains – 1 in my house and one in the cloud I started to look at options of linking the 2 and running a larger hybrid cloud lab. This is good in many ways as some workloads will need to be done on physical hypervisors (Citrix PVS for the moment) and some are perfectly suited to be run in the cloud (AppDNA).
So, lets get going.
Current Setup
At home I have 2 servers, 1 on VMware running my infrastructure and 1 on XenServer for my Citrix Workloads. I have a single public IP Address and a standard broadband set-up with Sky in the UK. My internal network range is 192.168.0.0/24
Desired Setup
As existing internally however the ability to add machines from Citrix Studio directly into Microsoft Azure. 2 available networks in Azure 10.20.1.0/24 for infrastructure and 10.20.2.0/24 for Citrix Workloads. Communication to be seamless between the 2 locations and the ability to use the £95 per month for more intense workloads that are more suited to run in the cloud.
First navigate to Networks
From the menu at the bottom click New, Virtual Network and Custom Create. We will now define our network setup for the machines hosted in Azure to use
Give your new network a name and pick the region that you want to run the network in
Define the DNS Servers that you want to assign to the machines you build and attach to this network.
NOTE: I have specified my internal dns server running on my internal servers. This is certainly not the best practice but to save on money spent in my subscription I don’t want to put out server just to run domain and dns services. It is also important to save name resolution for XenDesktop to work therefore you will need at least one dns server from your domain.
Leave the Configure Site to Site vpn option for now – we will configure this later on
Define your network addressing. I have specified 10.20.0.0/16 as the available address range. 10.20.1.0/24 as a subnet for infrastructure and 10.20.2.0/24 as a subnet for Citrix workloads
Click the tick and wait for the network to finish creating
Once your main vNet is created click the local networks tab
Click New, Network Services, Virtual Network and Add Local Network
Here we are going to specify our local network so we can link our Azure vNet and out Local network. Earlier I said that my local network is 192.168.0.0/24 and I only have a single subnet. Therefore this step is pretty simple.
First give your local network a name and put in the external IP Address assigned to your router at home
Next specify the address space that your local network is running on. This is so that the Azure vNet knows to push traffic down the vpn if it resides in the local subnet
Click the tick and wait for the local network to finish creating
Next we need to configure the Site to Site connectivity. Open your Azure vNet and select the configure tab. Put a tick in the site-to-site connectivity and put a tick in the Connect to the local network. Then select the local network you created from the drop down list provided
Click Save and your virtual network will show that a site to site vpn has been set up but no gateway has currently been configured
From the menu at the bottom click Create Gateway and select dynamic routing from the options.
Your status of the gateway will change to creating – be aware that this process may take up to 15 minutes to complete
While the gateway is creating switch back to your in-house hypervisors. You will need to build a Windows 2012 R2 Server to act as a Routing and Remote Access Server. This server does not need to be on the domain as it will only be used for routing and you don’t need to install the RRAS Role as this will be created later using an Azure-supplied script. You will need 2 network interfaces attached, one for the local access and one for DMZ.
Give them both static IP Addresses but don’t assign a gateway to the internal interface
And assign a gateway to the external interface
Once you have your 1012 R2 server set up you will need to add your firewall rules to allow access from Azure into your network for the VPN to be brought up. Below is a screen shot of the ports you will need to open up for the Azure site-to-site vpn. You will need to send all the vpn traffic to the external interface of your RRAS server
Once you have finished with your internal RRAS setup, switch back to your Azure portal and your gateway should (hopefully) have finished being created. It won’t show as connected as you have not finished the internal RRAS service
On the right click the Download VPN Device Script below the Quick Glance menu
When prompted set the Vendor to Microsoft Cooperation, the Platform for RRAS and the Operating System to Windows Server 2012 R2 and click the tick to download the script
Once downloaded rename the script extension from cfg to ps1 and execute the script as an administrator from your RRAS in Powershell
This may require your RRAS server to be restarted a couple of times. Let this happen and once back up log in and oprn up the Routing and Remote Access Admin portal
If you look at Network Adapters you should see a new adapter with the name of your external IP Address for your gateway in Azure. It will be of type demand dial and should show as connected
Move to static routes and you should see a new route to send traffic for the 10.20.0.0 subnet out of your demand dial interface
Switch to your Azure Portal and the Gateway should now show as connected
Traffic from Azure will now know how to route into your local network but you will need to add a static route to all your internal virtual machines to tell it how to get back to Azure. This can be done manually or using a startup script.
To manually add the route, log into each server internally and type in the following
route add -p 10.20.0.0 mask 255.255.0.0 192.168.0.240
You need to direct traffic for your Azure subnet to the internal interface of your RRAS server
Once added you can ping out to Azure from an internally hosted XenDesktop
Also you can ping inbound from an Azure hosted Server.
So, now we are ready to set up a machine catalog in XenDesktop to be run from Azure.
NOTE: You will need a classic mode image to use for provisioning. I have pre-built a Windows Server 2016 TP4 Server and installed the XenDesktop 7.8 Vda. I then shut down the server and captured an image of it using the Azure Management Portal
Add your new Azure Region into your hosting options withing XenDesktop. For a guide on doing this and instructions on how to get your publishsettings file look here:
and go to Step 11 – Adding Azure Hosting
Then click to create a new machine catalog
Click next for the welcome screen and select Server OS
Select your new Azure Region and click next
Select the image you prepared earlier
Select the number of machines you wish to create
Select the network you want the machines on
Select the OU you want the machines in and the naming convention
Give the new catalog a name
Click Finish and let Citrix Studio do its thing.
You will see Studio copying and creating your new machine catalog
After a while it will show as complete
Once done switch to Azure and select Virtual Machines. You should see your new machine listed
Click into the machine to view the configuration and you will see it’s on the right network that you defined during the creation wizard and can therefore speak to your internal network as it is aware of the routes needed.
That’s it, hopefully this will help some of you get some more use out of your lab environment and a little more compute power into your environment.
