Introduction
As you might now, as of July 1st 2013, Microsoft has started to allow running Remote Desktop Services (Session-based Desktop deployments) in Windows Azure. In order to achieve this Microsoft changed the Product Use Rights (PUR) to be allow to license RDS via SPLA (Microsoft Services Provider License Agreement).
In a previous blog post I have described performance testing results running RDS (Session-Based Desktop deployment) on Azure. In this blog post, I will walk through the LAB I build running Dell vWorkspace on top a RDS environment in Windows Azure. Dell vWorkspace (previously Quest) is a Desktop Virtualization Management tool which simplifies the deployment and management of desktop virtualization & VDI technologies. Dell vWorkspace also offers RDP protocol optimizations and a client for almost any endpoint device.
Basic setup
The diagram below shows the environment I have set up in Windows Azure. It consists of two servers running both the vWorkspace Secure Gateway and vWorkspace Web Access role, one server running the vWorkspace Connection Broker role, two servers running the Session Host role and one server running SQL Server and File Services. All servers have been added to Active Directory.
Important to note here is that the above architecture is a Proof Of Concept (POC) environment. In an actual production environment you need to deploy two or more role instances in different fault and upgrade domains to allow for external connectivity of at least 99.95% uptime for compute (there is a different SLA for storage). For more information also see the Windows Azure SLA.
All servers in this deployment are running Windows Server 2012 R2 (Preview). Before deploying the Virtual Machines in Azure I have created a Virtual Network to allow all Virtual Machines to be able to communicate with each other. I selected this Virtual Network during the creation of every new Virtual Machine.
Since we need to do some form of load balancing for Secure Gateway and Web Access services, these two Virtual Machines need to be configured a specific way. For more details see the “Publishing vWorkspace in Windows Azure” section.
The first step would obviously be to setup Active Directory Domain Services (ADDS) and install SQL Server. I won’t walk through those installations here. If you need guidance, there are many good resources available online. From this point on I’m assuming that ADDS is properly installed and SQL Server is also running and available. In my lab I used SQL Server 2012.
In this lab we are using vWorkspace 8.0 x64. Dell offers a free vWorkspace trial to test with.
The main goal of this blog post is not to show you in detail how to install and configure vWorkspace. There are many tutorials online that describe the installation of vWorkspace in great detail. The main goal of this blog is to show you what needs to be done in Azure to get vWorkspace up and running and available to your end users. That being said, in order to create some background information, we will start with a little overview on the way I’ve deployed the various vWorkspace roles.
Installing the vWorkspace Connection Broker
After starting the setup on the Connection Broker server and accepting the agreement we choose the advanced setup, which allows us to select which roles we want to install.
Since we will also be using this server as a management console we select the roles as shown below.
We configure to use our existing SQL server and let the setup create a new vWorkspace database and follow the rest of the setup by selecting the defaults.
Installing the vWorkspace Web Access & Secure Gateway
As mentioned before, for this lab we will be running two servers with both the Web Access and the Secure Gateway role. In order to do so, we run the vWorkspace 8.0 setup on both servers and select the roles as shown below. We leave the option to create a web site blank; we will be creating this later on in the process.
Installing the RD Session Host servers
Prior to launching the vWorkspace setup to install the vWorkspace Session Host roles required, we need to install the Microsoft RD Session Host role.
In order to do so we use the Server Manager on those servers, perform a Role Based Installation and install the Remote Desktop Session Host Role. Note that we do not perform a Scenario Based installation of Remote Desktop Services since that would result in a RD Connection Broker and RD Web Access role as well. Since we’re setting up vWorkspace, we will be using the vWorkspace equivalents of those two roles.
Note that there have been issues with the Windows Server 2012 (non R2) image in Azure when trying to install RDS roles. Specifically the KB article KB2821895 was (at least one) of the causes that resulted in a failure when trying to install any RDS role. The Azure image version that had this issue was dated 5/17/2013. I’m assuming that this has been fixed in the most current version 8/6/2013.
After installing this role (and performing the necessary reboot) we are ready to start installing the vWorkspace RD Session Host role. In order to do so we run the vWorkspace 8.0 setup and select the role as shown below.
We select the option to use the existing database and provide the necessary information to connect to SQL Server.
This finishes the basic deployment of the vWorkspace roles and we can move on to configuring the deployment.
Configuring the vWorkspace deployment
Now that we have installed the basic vWorkspace roles we can configure the deployment. Configuration can be done manually, but in this case we choose to use the Quick Start Wizard.
Since we are doing a Session-Based Desktop deployment we select the option Remote Desktop Session Host.
We need to specify our Connection Broker server and select the server we previously provided with that role.
Next we specify what RD Session Host servers we want to add, we select both servers we previously provided with the RD Session Host role.
Next, we need to specify the Managed Applications (application we want to publish to our users. We use the wizard (by clicking New) to add 7 Remote app (application type: Program) and 1 full desktop (application type: Desktop).
We will leave the Optional Steps in their default values and finish the wizard. We now have a deployment consisting of Session Host Servers and several managed applications managed by vWorkspace Connection Broker. The vWorkspace Management Console should now look something like below.
And the Managed Applications section now shows the applications and desktops we chose earlier. Note that for this lab we explicitly chose to publish some applications on all Session Host Servers and some on just one.
We can now further configure the environment by adding the Web Access and Secure Gateway servers to the deployment.
Configruring Secure Gateway
Next we will configure the Secure Gateway roles. We launch the Secure IT tool on both the Secure Gateway servers itself. We configure Secure IT with a basic configuration by just configuring a proxy for RDP traffic and Connection Broker Traffic on port 443 and provide a wildcard certificate that matches the FQDN we’ll use to access the Secure Gateway from the outside.
Note that sometimes the Certificate Name appearing here does not match the actual name of the certificate (especially in case if Wild Card Certificates). This causes connection to the Secure Gateway not to come through. In that case use the certificates.msc snap-in to actually edit the friendly name of the certificate, and reboot the Quest Secure Gateway service after that.
Configuring Web Access
We can now start configuring our Web Access component, we launch the Web Access Site Manager and Choose New and provide “demo” as the friendly and Virtual Directory name.
After the creation finishes, we can quickly check if the site was created successfully by browsing to http://localhost/demo, which should result in the screen shown below.
We are now ready to add the Web Access servers to our deployment. Inside the vWorkspace management console, we choose Websites and then New.
In the New Website section we provide a name, and the full URL.
For the default rule we select vWorkspace Secure Gateway
In the Secure Gateway section we provide the configuration of the Secure Gateway server. Within this deployment we use the public DNS name, which we will later point to our Secure Gateway servers, and configure port 443.
To allow users not having to provide a domain name when logging on, we configure to domain automatically in the User Domains section.
To allow users to be able to easily install the required vWorkspace client, we configure vWorkspace Connectors section as follows.
To show you some of the customization options of Web Access we created a new theme in the Themes Section.
All other options in this wizard have been left as default. After the wizard finishes we perform the same steps for the other server running Web Access. After finishing that wizard, the Web Access section in the vWorkspace Management Console looks like below.
This concludes the basic setup of vWorkspace. We now have a deployment running in which we publish Remote Apps and Desktops on a RD Session Host farm using Web Access where we proxy both RDP traffic and Connection Broker traffic through the Secure Gateway.
Publishing vWorkspace in Windows Azure
Now that we have finished the basic vWorkspace setup we can start publishing the vWorkspace environment to the outside to allow users to connect to it.
Since we have built lab with two instances (to also comply to the Windows Azure SLA) of both the Web Access and the Secure Gateway role, we need to use some form of load balancing to spread the load over the two instances and allow for some form of High Availability (HA). With Windows Azure there are several ways to accomplish this which we will discuss in the upcoming paragraphs.
For this POC I have tested three different methods to perform load balancing.
1. Load balancing using Azure Load Balanced Sets
2. Load Balancing using Windows Azure Traffic Manager
3. Load balancing using KEMP Load Master for Azure
In the upcoming paragraphs we’ll discuss these three methods and investigate what method would suit best for vWorkspace in Windows Azure.
Option 1. Load balancing using Azure Load Balanced Sets
The first option is to use a Load Balanced Set in Windows Azure. In order to achieve this, make sure that when creating the Virtual Machine for the second Gateway/Web Access server, you select the same cloud service you used for the first Gateway/Web Access server, as shown below.
This results in a Cloud Service running two instances.
When we open up the Endpoints section of the first Secure Gateway/Web Access server we will see the endpoints configured by default. We can choose Add, to add our desired End ports.
Since we want to publish both Web Access (running on port 80) and Secure Gateway (running on port 443) we add two new endpoints on the first Secure Gateway/Web Access server, configured as shown below. (Make sure Create Load Balanced Set is selected)
The first Secure Gateway endpoint:
The first Web Access endpoint:
After that, we also create two new endpoints on the second Secure Gateway/Web Access server, however, this time we select “Add endpoint to an existing load-balanced set”.
The second Secure Gateway endpoint:
The second Web Access endpoint:
That finishes the publication of vWorkspace. For this lab we created the public DNS name azurevworkspace.wortell.nl, pointing to the IP address of the Cloud Service. You can grab the IP address by looking at the Cloud Service inside the Windows Azure Portal.
If we open up a web browser and browse to http://azurevworkspace.wortell.nl, we automatically get redirected to the /demo site and are presented with the Web Access logon screen.
When logging in with one of our test account we should be presented with the set of Remote Apps and Desktops we are authorized for.
However, some of the icons of the Remote Apps seem to missing. The missing icons appear and disappear at random upon refreshing the web page. When we try to launch a Remote App we’re periodically presented with the dialog below. “Your active session has expired. Please log in again to continue.”
And the error below occurs periodically as well “The farm is no longer part of your session”
What is causing this? In this case we are using load balancing based on Windows Azure Load Balanced Sets. This load balancing mechanism is based on Round Robin, which means that a user can end up on different Web Access and Secure Gateway servers during a single session. In other words, Windows Azure Load Balanced Sets does not work with Session Affinity. Dell / Quest states “vWorkspace connection is a multi-step process so user should be directed to the same server (Secure-IT and/or Web-IT) while establishing a session”. Also see their vWorkspace Knowledge Article 99163.
We can easily test this by removing the endpoints from the second Secure Gateway / Web Access server, we can then connect without any issues and start our vWorkspace Remote App running in Windows Azure!
The conclusion here, the way Windows Azure Load Balanced Sets currently works, prevents us to use it with vWorkspace, because it leads to unstable and unpredictable operation.
Option 2. Load Balancing using Windows Azure Traffic Manager
A new feature has been added to Windows Azure recently called Traffic Manager. This feature is currently in preview in Windows Azure and allows taking more control over the load balancing. With Windows Azure Traffic Manager you can choose between different load balancing mechanisms like Round Robin, Performance and Failover. No actual service traffic routes through Windows Azure Traffic Manager. In case of Round Robin, the user’s computer calls the cloud service directly and Windows Azure Traffic Manager resolves the DNS entry for the company domain to the IP address of the cloud service. The performance method locates the origin of the traffic and routes it to the closest cloud service. “Closeness” is determined by a network performance. Both scenarios are based on a DNS Time-to-Live (TTL), clients will continue to use a given cloud service until its local DNS cache expires. Therefor there is not real Session Affinity, other than to rely on the DNS TTL (which you could of course set to i.e. 24 hours). Although for this scenario we are going to use Azure Traffic Manager for load balancing, Azure Traffic Manager is actually designed to direct traffic to the “best data center”. Microsoft describes Traffic Manager as “Traffic Manager applies an intelligent policy engine to the DNS queries on your domain names so that you can send traffic to the best data center for performance, business continuity, price, compliance, legal, or tax purposes.”
To configure this we first need to create Endpoints to both Secure Gateway / Web Access servers. The same steps can be followed as outlined in the previous section, this time however we don’t use the “Load Balanced Set” option. Instead, we configure them as separate Endpoints. Note that the two servers this time cannot be inside the same Cloud Service, because the public ports are configured on the Cloud Service, therefor port 80 and port 443 can only be configured once. This means we need to have two servers running in separate Cloud Services.
Next, we create a new Azure Traffic Manager object with the properties shown below.
For the DNS name we provide azurevworkspace.trafficmanager.net, choose the Performance option, and select our two Secure Gateway / Web Access servers as endpoints.
When the Traffic Manager object is created we are able to edit it and provide more advanced features. We are for example able to configure the DNS TTL used; we could raise this to allow users to connect to the same Secure Gateway / Web Access server during a longer period of time. We can also change the monitor settings. The protocol and port specified here are used to probe if an end point is available. Note that since we are running Secure Gateway and Web Access on (two) single servers, using Traffic Manager, we could be directed for Secure Gateway Access to a server where port 443 is down (because we can only probe a single port per Traffic Manager object. In scenario’s where Secure Gateway and Web Access are deployed on separate (dedicated) servers this of course would not be an issue.
In order for our published Remote Apps and Full Desktops to start using the Traffic Manager, we make the following change inside the vWorkspace Management console.
Upon trying to access vWorkspace using http://azurevworkspace.trafficmanager.net/demo we can successfully log in and we don’t run into the issues as described in the previous scenario. However, when we try to launch a Remote App, we are presented with the following error:
This is obviously because the certificate we used earlier does not match the DNS name we use for the Secure Gateway. Currently it is not possible to use a different DNS name for Azure Traffic Manager, and I have not seen any announcements that Microsoft will add this feature will be added in the future. So unless we get a valid certificate for the trafficmanager.net domain, or create a self-signed certificate for trafficmanager.net (and have that trusted on clients), using Azure Traffic Manager with vWorkspace Secure Gateway is not going to work, or is at least not an ideal solution.
Option 3. Load balancing using KEMP Load Master for Azure
Recently, Kemp Technologies has released the KEMP Load Master for Azure which they offer for free. KEMP Load Master for Azure is a linux based load balancer which you can download in a .vhd template format and publish that to your Azure Subscription. I recently wrote a detailed article on that, which was also published on the KEMP Technologies blog. I won’t repeat the details on how to get the .vhd template in Azure and how to create a new VM from that, please check my blog post if you’re interested in those steps.
For now I will assume that the KEMP Load Master VM is successfully deployed and available.
On the two Secure Gateway / Web Access servers themselves we don’t need the Endpoints for port 80 and 443 to be published since all traffic will go through the KEMP Load Master. Be sure to remove those Endpoints if currently in place.
As mentioned, with the Load Master all traffic will go through the Load Master itself. Therefore, we need to configure the two Endpoint (port 80 and 443) on that Load Master VM. For the instructions see the previous paragraphs. The configuration should look like something below.
For the load balancing to work for both port 80 and port 443, we need to create two separate Virtual Services in Load Master.
From the within Virtual Services section inside the Load Master web interface menu, we choose Add new and specify the IP address of the Load Master VM and a descriptive name.
In the Standard Options section we configure the desired persistence options, In this case based on source IP with a timeout of 1 day. We set the scheduling method to least connection and disable transparency.
In the Real Server section we add both our Web Access servers (based on their local IP address).
We then create the second Virtual Service, this time for load balancing the Secure Gateway
The settings in the Standard Options section are the same as with the previous Virtual Service, based on source IP with a timeout of 1 day. We set the scheduling method to least connection and disable transparency.
The key difference to make Secure Gateway work with KEMP is to use TCP instead of HTTPS for monitoring
And again, we add both the Secure Gateway servers as Real Servers.
The final results should look like below, and indicates that we’re ready to go!
For our test we again browse to https://azurevworkspace.wortell.nl (which now points to the KEMP Load Master). We are presented with a logon screen, and after logon we’re able to successfully launch Remote Apps and Desktops, all running through the load balancer.
The KEMP Load Master web interface shows us some nice statistics on session activity and network metrics.
Conclusion
What started as a little test ended out to be an interesting journey through Azure! If you’ve managed to read the blog post up to this conclusion, well done! You’ve read over 3500 words! Sorry about that! :) The conclusion here, setting up vWorkspace in Azure is not that different than setting it up in any other on premises or hosted environment. It does become interesting however, when we expand the basic setup to allow load balancing and High Availability (again, to also meet the Windows Azure SLA requirements). It turns out that the default methods for load balancing in Windows Azure are not fully compatible (yet) with the vWorkspace Secure Gateway and Web Access services, mainly because of Session Affinity. However, load balancing solutions like the KEMP Load Master for Azure close the gaps and even provide more control, flexibility and statistics on your load balancing solution. Does Windows Azure today provide enough resources against a reasonable price to make the move of RDS to Azure worthwhile? That highly depends on the specific Use Case, your requirements and the resources you need per user. This blog post shows it’s technically already possible today. To provide more guidance and insight you can expect a follow up blog post discussing an actual business case. It’s all about finding a balance between costs & required resources. Back in July 2013, I performed a performance test running RDS on Azure, which resulted in CPU being the bottleneck. However the Azure platform is innovating fast, new features and possibilities are added rapidly. So will more Use Cases arise in the future? Absolutely! Cloud is the future, and Azure will play a big part in it!
Finally, I would like to thank my Wortell colleague Rick Slager and Michel Roth (Dell Senior Product Manager for Desktop Virtualization), who were willing to review this huge blog post and provide feedback and insight! (next time I will provide popcorn to you guys!)
