Monday, September 30, 2013

KB: Connection hangs after you import virtual machines into Windows Server 2012 Remote Desktop Services Unmanaged Pool

New KB article (2891541) related to migrating Windows Server 2008 (R2) VDI VM’s to Windows Server 2012.

“…Consider the following scenario:

  • You have a Virtual Device Interface (VDI) infrastructure that is configured on a server that is running Windows Server 2008 or Windows Server 2008 R2.
  • You have another Windows Server 2012 VDI environment.
  • You migrate virtual machines from Windows Server 2008 or Windows Server 2008 R2 to the Windows Server 2012 VDI environment.
  • You import the virtual machines into Windows Server 2012 Remote Desktop Services Unmanaged Pool.
In this scenario, if you try to connect to a virtual machine from Remote Desktop Web Access (RD Web) or Remote Desktop Protocol (RDP), the connection stops responding (hangs) at the "Loading the virtual machine" state. Additionally, the connection may time out, and you receive the following error message:

Connection processing has been canceled. Try connecting again, or contact your network administrator…”

“…The problem occurs because Windows Server 2012 VDI virtual machines add a Remote Desktop Virtualization (RDV) device that does not exist in virtual machines that are not created by using Windows Server 2012. Without this device, the VDI RDP client cannot connect to the virtual machines, and the connections hangs…”

“…To work around this problem, re-create the virtual machines in Windows Server 2012 and copy over the Virtual Hard Disk (VHD) instead of exporting and importing the virtual machines…”

Source: http://support.microsoft.com/kb/2891541/en-us?sd=rss&spid=16526

Tuesday, September 24, 2013

Download: Windows Azure Desktop Hosting Reference Architecture Guide

Microsoft put out a new Reference Architecture Guide on running RDS (Session-Based) in Windows Azure. Download it here!

Also see my earlier posts on RDS in Azure related to this Reference Architecture Guide:

Running Dell vWorkspace in Windows Azure
and
Load balancing Remote Desktop Services Web Access & Gateway with KEMP Load Master for Azure

“…Summary: This document defines a set of architectural blocks for using Windows Azure Virtual Machines to create multitenant, hosted Windows desktop and application services, referred to in this document as “desktop hosting.” The primary goal is to enable hosting providers to create secure, scalable, and reliable desktop hosting solution offers for small- and medium-sized organizations with up to 1,500 users. The intended audience for this reference architecture is hosting providers who want to leverage Windows Azure infrastructure services to deliver desktop hosting services and Subscriber Access Licenses (SALs) to multiple tenants via the Microsoft Service Provider Licensing Agreement (SPLA) program. To deliver a desktop hosting solution via Microsoft’s SPLA program, hosting partners leverage Windows Server and the Windows Desktop Experience feature to deliver Windows users an application experience that is familiar to business users and consumers. Although Windows 8, Windows 7, and earlier Windows client versions are not licensed for SPLA, the Desktop Experience feature in Windows Server 2012 provides a similar user experience and application support.

Source: http://msdn.microsoft.com/en-us/library/windowsazure/dn451351.aspx

Friday, September 20, 2013

Dell / Wyse ThinOS version 8 and the RD Connection Broker in Windows Server 2012

HomeAs you might know connecting to a RDS environment running on Windows Server 2012 (R2) requires users to always connect to the (farm of) RD Connection Broker Servers initially, from where they will be redirected to a RD Session Host in a farm. In order for the RD Connection Broker to be able to redirect the session to the correct RD Session Host farm it needs to be aware of the Session Collection. More info, also sees RD Connection Broker HA and the RDP properties on the client.

DellWyse ThinOS version 8 comes with a full featured RDP8 client and supports the RD Connection Broker 2012. To connect ThinOS8 to a Windows Server 2012 RDS environment you can specify the following .ini parameters;

VDIBroker=https://rds.domain.com AutoConnectList="Full Desktop"
ConnectionBroker=Microsoft
SignOn=Yes

The parameter VDIBroker should point to your RD Connection Broker Server(s) and optionally you can use AutoConnectList to auto run a certain Remote App or Full Desktop. The parameter ConnectionBroker specifies that the broker is a Microsoft RD Connection Broker. Setting the parameter SignOn to Yes allows Thin OS to pass the login credentials, entered when logging on the Thin Client, to the RD Connection Broker

If a user is authorized for multiple Session Collections within a single deployment ThinOS8 will retrieve and show all authorized Remote Apps and Desktops from all Session Collections combined together.

More info: http://www.wyse.com/products/cloud-clients/firmware/Wyse-Zero-and-Wyse-ThinOS

Wednesday, September 11, 2013

Using User Profile Disks (UPD) in combination with predefining the Modern UI Start Screen on RDS 2012 (appsfolder.itemdata-ms)

I was recently contacted by someone regarding one of my previous blog posts called Predefining and customizing the Modern UI Start Screen on RDS 2012 where I describe a way to create a predefined Start Screen layout for Remote Desktop Sessions running on Windows Server 2012 and still allow users to modify that predefined Start Screen to their needs.He was wondering how this method would work in combination with using User Profile Disks. I’ve also seen similar comments on that blog post in regards to that combination. Enough reason to test this combination in my lab and I hereby want to share the results with you.

If you’ve read my blog post you’ll know that the items on your Start Screen are not stored in a folder within your profile but are in fact stored in a binary file called appsfolder.itemdata-ms which is stored in %USERPROFILE%\appdata\local\microsoft\windows\.

With Use Profile Disks (UPD) you no longer use a (cached copy of) roaming profile. In stead, your profile is stored in a .VHDX file specific to your account which is placed on a central share. Upon logon a mount path is created under C:\Users\<username> that points to that .VHDX file on the share. This makes the solution fully transparent to the Operating System and applications. If you’ve used UPD before you will have noticed that the filenames of the .VHDX files hold the users SID, not the account name. To get a quick overview of what account name is coupled to what .VHDX file check out my script Retrieve usernames for a User Profile Disks (UPD) share in VDI environment on Microsoft TechNet Gallery.

Part of the configuration of UPD is to configure what folders of the profile you want to be part of UPD. In order to do so, open the RDMS as part of the Server Managed Console en edit the properties of your Session Collection.

image

Choosing the option “Store all user settings and data in the user profile disk” would obviously capture everything normally stored under C:\users\<username> and add that to the UPD. That will obviously also include the path of the appsfolder.itemdata-ms file (\appdata\local\microsoft\windows\). However in most cases you would want a more granular control of what’s going to be stored in the UPD. To do so you select the option “Store only the following folders on the User Profile Disk”. After that you can make a selection based on the most common folders. Notice however that you can only select the roaming part of your user profile data. This means that \appdata\local\ will be excluded, and thus so will the appsfolder.itemdata-ms file.

However, besides being able to select the most common folders you can also add additional files & folders as desired. To test this we add the following, which is a relative path to the file where the Start Screen is stored.

image

When we configure this (in combination with the configuration I refered to earlier) and log on with a test user, a UPD file is created successfully.

image

And the user seems to get the Start Screen Layout as pre configured.

image

However, when we look at the system drive of the RD Session Host Server we notice that a temperately profile has been created where we would have expected a mount point to the UPD file.

image

Upon logging off the user, the temp profile folder is obviously gone, but when we try to mount the UPD file we are presented with the following error:

image

Apparently in this scenario the .VHDX file doesn’t get detached properly. We manually detach the VHDX using Disk Management

image

We are now able to mount the .VHDX and check what’s inside and notice that the file we specified is not in there. (only the roaming part of the User Profile Data).

image

So apparently the method of selecting the file as an additional file does not work and causes the UPD to not be able to detach properly.

Does this mean that the combination with UPD simply does not work properly for this scenario? Upon some further testing  I discovered a workaround to make this work.

After removing the UPD file of the test user, in stead of adding the file inside the UPD configuration, we add the folder where the file resides.

image

Upon log on, again a VHDX file is successfully created and user is represented with the pre-defined Start Screen.

image

This time however we notice that that on the RD Session Host server the mount to the UPD file is successfully created (and no TEMP profile is showing).

image

When we do a drilldown inside this folder we see the desired behavior. The Windows Folder is a mounted folder.

image

Upon logging of the user, the UPD file is correctly detached, and when mounting the UPD file as an administrator we see that the folder \appdata\local\microsoft\windows is now part of the UPD file.

image

And so is the appsfolder.itemdata-ms file and as a result customization to the layout of the Start Screen can now be roamed to other servers within the Session Collection!

image

Final remarks: The ability to pre define the Start Screen has been improved in the R2 release of Windows Server 2012 and has become configurable using a GPO. More details on that: Predefining and customizing the Modern UI Start Screen on RDS 2012 R2

KB: The size of the "HKEY_USERS\.DEFAULT" registry hive continuously increases on a Windows Server 2008 R2 SP1-based server

A new KB article (2871131) in regards to an increasing KEY_USERS\.DEFAULT key related to printer settings never being deleted in the DevModes2 key. I’ve seen this issue in several environments, but there is a fix now!

“…Assume that you have a server that is running Windows Server 2008 R2 Service Pack 1 (SP1). Many users connect to the server by using a certain remote desktop application. In this situation, the size of the following registry hive may exceed the limit: KEY_USERS\.DEFAULT

Therefore, the users cannot connect to the server.

This issue occurs because of an error that occurs in the Print Spooler modules. When a user establishes a new remote desktop session to the server, the printer settings of the user are written in the following registry subkey: HKEY_USERS\.DEFAULT\Printers\DevModes2

However, the printer settings are never deleted. Therefore, the size of the following registry hive becomes larger and larger, and various problems are caused by this behavior:  HKEY_USERS\.DEFAULT…”

Source & download: http://support.microsoft.com/kb/2871131/en-us?sd=rss

KB: A memory leak in the WmiPrvSe.exe process occurs when you use the RDS WMI provider in Windows 7 SP1 or Windows Server 2008 R2 SP1

A new KB article (2876748) regarding a possible memory leak when using the RDS WMI provider in Windows Server 2008 R2 SP1.

“…When you use the Remote Desktop Services (RDS) Windows Management Instrumentation (WMI) provider in Windows 7 Service Pack 1 (SP1) or Windows Server 2008 R2 Service Pack 1 (SP1), you notice a memory leak in the WmiPrvSe.exe process. This may cause the WmiPrvSe.exe process to stop…”

Source & download: http://support.microsoft.com/kb/2876748/en-us?sd=rss

KB: Error when you try to change the properties of a published RemoteApp in Windows Server 2012

A new KB article (2862077) was released yesterday in regards to changing the properties of a Remote app inside the RDMS if this Remote App is installed on a non-system drive of the RD Session Host.

“…Consider the following scenario:

  • You deploy Remote Desktop Service on a Windows Server 2012-based computer.
  • A Remote Desktop Connection Broker is installed in the environment. The computer is joined in a session-based collection.
  • You install an application on a non-system drive of the computer.
  • You publish this application as a RemoteApp.
  • You try to use Remote Desktop Management Server (RDMS) UI to change and save the properties of the RemoteApp.
In this scenario, the operation fails, and you receive the following message:

Cannot bind argument to parameter 'VirtualPath' because it is an empty string

This issue occurs because the script that RDMS UI calls receives an empty parameter unexpectedly…”

“…To work around this issue, use the Set-RDRemoteApp cmdlet to change the properties of the RemoteApp…”

Source & download: http://support.microsoft.com/kb/2862077/en-us?sd=rss

Friday, September 6, 2013

Running Dell vWorkspace in Windows Azure

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.

image

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.

image

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.

clip_image006

Since we will also be using this server as a management console we select the roles as shown below.

clip_image008

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.

clip_image010

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.

clip_image012

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.

clip_image014

We select the option to use the existing database and provide the necessary information to connect to SQL Server.

clip_image016

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.

clip_image018

Since we are doing a Session-Based Desktop deployment we select the option Remote Desktop Session Host.

clip_image020

We need to specify our Connection Broker server and select the server we previously provided with that role.

clip_image022

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.

clip_image024

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).

clip_image026

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.

clip_image027

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.

clip_image029

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.

clip_image031

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.

clip_image033

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.

clip_image035

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.

clip_image037

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.

clip_image039

For the default rule we select vWorkspace Secure Gateway

clip_image041

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.

clip_image043

To allow users not having to provide a domain name when logging on, we configure to domain automatically in the User Domains section.

clip_image045

To allow users to be able to easily install the required vWorkspace client, we configure vWorkspace Connectors section as follows.

clip_image047

To show you some of the customization options of Web Access we created a new theme in the Themes Section.

clip_image049

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.

clip_image051

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.

clip_image053

This results in a Cloud Service running two instances.

clip_image055

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:

clip_image057

The first Web Access endpoint:

clip_image059

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:

clip_image061

The second Web Access endpoint:

clip_image063

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.

clip_image065

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.

clip_image067

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.

clip_image069

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.”

clip_image071

And the error below occurs periodically as well “The farm is no longer part of your session”

clip_image073

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!

clip_image075

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.

clip_image077

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.

clip_image079

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:

clip_image081

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.

clip_image083

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.

clip_image085

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.

clip_image087

In the Real Server section we add both our Web Access servers (based on their local IP address).

clip_image089

We then create the second Virtual Service, this time for load balancing the Secure Gateway

clip_image091

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.

clip_image093

The key difference to make Secure Gateway work with KEMP is to use TCP instead of HTTPS for monitoring

clip_image095

And again, we add both the Secure Gateway servers as Real Servers.

clip_image097

The final results should look like below, and indicates that we’re ready to go!

clip_image099

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.

clip_image101

The KEMP Load Master web interface shows us some nice statistics on session activity and network metrics.

clip_image103

clip_image105

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!)