It has been awhile since we covered the topic of hybrid cloud models with Citrix as the hub. Several years ago, we spoke about this model when we first introduced native provisioning to AWS. I figured it was time to tackle this topic, but from the approach of leveraging our Apps and Desktop service in Citrix Workspace Cloud management solution, and Azure.
Recently, Prasanna Padmanabhan wrote a blog post about the latest Citrix addition to the Azure Marketplace. You can deploy an entire XenApp infrastructure into Azure in a few easy steps. His blog can be found here.
This blog will focus on the creation of a resource zone in Azure and tying that into an on-premise datacenter and domain. Below is a high-level architecture view for the solution. Leveraging the Apps and Desktop services in Workspace Cloud, the main XenApp/XenDesktop farm components are in the cloud, while the resources reside in Azure and on-premise.
It should be noted that I started with an existing Workspace Cloud environment already tied into your on-premise domain.
I am leveraging an on-premise Active Directory for this deployment. All AD communications are sent across the VPN link. The machines can participate in all AD activities. There are other ways to deal with Active Directory and a VPN connection.
- The way I just described. Domain joining all Azure resources.
- You can also deploy a domain controller in Azure as a separate AD site for your on-premise domain.
- Deploy a separate Active Directory in Azure, and establish a trust with your on-premise domain.
The Setup
The first step is to build a site-to-site VPN connection between Azure and your on-premise datacenter. NetScaler can be used to establish this connection. One of your famous CTPs, Stephane Thirion (@archynet) has laid out the necessary steps; first he shows you the Azure steps, followed by the necessary steps on the NetScaler. His post can be found at this link.
When I setup my environment, I leveraged the latest NetScaler build (at the time of this post) in 11.0.65.31.nc. here are some additional environment details around the environment I used for the purpose of this blog
- On-Premise NetScaler 11.0.65.31 connecting to my Azure account
- My on-premise network is 192.168.0.0.
- My Azure environment is based on a 10.20.0.0 address scheme.
- All machines were created in the Central region with the “Classic” method via the web portal.
- I created a bastion or jump server in Azure to perform my configuration work. This server had a public IP and the port for RDP (3389) was open via Endpoints. He was placed in the subnet of 10.20.20.0.
- The server that has the Cloud Connector and the VDA installed are part of the 10.20.30.0 subnet.
- I have a Workspace Cloud account with 2 resource locations; 1 for my on-premise and 1 for Azure
- All resources in Azure are domain joined thanks to the VPN connection.
- All resource zone servers are secured by leveraging Network Security groups (NSGs) within Azure
Let’s Get Started!
After you follow the steps that Stephane laid out, a PBR (Policy Base Route) with appear in your NetScaler configuration. Below is a picture of mine.
This allows for all traffic destined for my 10.20.0.0 subnet to be properly routed through the Azure connector that I created.
On To Resource Creation!
If are familiar with the Azure portal, you see two options when creating VMs: Classic or Resource manager. At the time of this blog, Citrix support native provisioning to “Classic” Azure. All of my resources were created in the Azure Central Region data center as it still supports the Classic method.
The first server to create was my Bastion or “jump” server. This server will be my entry point into the subnet for which I will be creating other images to work from. This was a basic “Basic A1” server. Not a lot of resources here, but enough to get the job done. For a full list of available VM sizes, please see the Azure Marketplace.
My next step was to create a Network Security group. The NSG I created, was applied to my resources subnets. This allow for bulk assignment of any resources to the necessary subnet to automatically fall within the rules of the assigned NSG. Below is a screen capture showing a partial list of the ports I opened. As always, when opening ports and separate resources, do so in the best interest of your solution and security of your company.
There are many resources that cover NSG and their creation and architectures. Here are three to get you started. Many more pages like these are just a keyword search away.
- Build a simple DMZ with NSGs
- Build a DMZ to protect application with a Firewall and NSGs
- Secure Azure Virtual Network and create DMZ on Azure VNET using Network Security Groups
You can assign NSG to VMs as well. I chose to stick with a subnet so that all future provisioned machines will get the same assigned.
The Second Server: The Workspace Cloud Connector!
Next on my list was the Workspace Cloud connector server. When selecting your VM size, do so within the parameters and load that you feel is the best match. For the purpose of this blog, I selected a “Standard A1” server.
As I was creating this server, I made sure to place this within the 10.20.30.0 subnet. This allows me to segment my traffic and potentially apply a different NSG to the subnet should that become necessary. This server is a manual creation either by PowerShell or the portal. I chose the portal.
I also removed the default Endpoints that Azure assigns to the VM, WinRM and RDP. I’ll let my NSG take care of access to the VMs. Leveraging my jump server, I will use that for RDP access, rather can directly to the gold image over the internet. I also removed the public IP address for this server.
Once the Connector VM was added to my on-premise domain, I setup a new zone in my Workspace Cloud environment, downloaded and installed the connector.
First, create the Resource location in your Workspace Cloud environment. Download the Connector and install it on the Azure Connector machine. During the installation, you will be prompted to login and apply this connect to your companies site.
Once the install is complete, your new connector will appear in your resource area of your Workspace Cloud web console. As a best practice, have a minimal of 2 connectors per resource zone.
You can now create your zone within Workspace Cloud Studio to aid in properly assigning published resources.
Great, this concludes the Connector setup, not much to it.
The Azure VM Resource
I created another VM that will become the “gold” image for my hosted shared environment in Azure. Same build process as before. I leveraged the Azure Portal to manually create the VM, making sure to place this in the proper subnet I am using for these resources.
During the installation of the VDA when prompted for your DDC, put in the FQDN of the Connector that you created. The VDA will use the Connector to communicate with the Workspace Cloud environment over SSL as a secure proxy for this communication. During the installation of the VDA, I opted to have Receiver installed. I pointed Receiver to my on-premise StoreFront to help aid in the delivery of additional applications.
Once your image is to your liking, it is time to take a capture. It is recommended that the VM is in an off state when you take your initial capture. During the process, there is no need to check the SysPrep box on machines running VDA version 7.7, or higher. Images can be viewed in the classic web UI for Azure, https://manage.windowsazure.com.
Delivering the Goods
If you have not done so already, configure Azure to be a Hosting platform in the Apps and Desktop service Workspace Cloud management console.
Copy and paste your publishing file contents into the “import” section. Then, follow the remaining windows with selecting your datacenter and your network of choice.
Once that is complete, configure your machine catalog.
Once this is complete, we can move onto the delivery group creation. For image selection, you will have a list of all “captured” machines. Select the appropriate gold image.
Make sure to allow Workspace Cloud to manage access to this delivery group to have it fit into the subscription model. You will see the Studio prompt pictured below. After the delivery group has been successfully added, you can add them to the published subscription, pictured after.
After you have completed the creation of the Delivery group, the Azure console will show your VMs in a stopped state. This is nice, as you won’t incur any unnecessary charges.
Time to start a VM and test your deployment. The Apps and Desktop service Workspace Cloud StoreFront site provided to your company will follow the URL of https://<your company.xendesktop.net/. Login with the appropriate user credentials for your domain and launch.
Items to be aware of
- Change your time zone in your Azure VM! Double check the time zone for your VMs.
- The NSGs I created in this blog are very open. It would always be a best practice to make these as secure as necessary.
- PowerShell offers a robust set of tools that the webUI does not fully expose.
Happy Hybrid cloud-ing!
