Tuesday, December 17, 2013

RDV Team: Resolution and Scaling Level Updates in RDP 8.1

A new blog post was posted yesterday by David BĂ©langer, a program manager on the Remote Desktop team. He discusses the improvements made to dynamically update the resolution and scaling level from the local system to the remote session and how this impacts your remote desktop experience.

Some of the topics are Dynamic resolution update, Dynamic scaling level update, Multi-Monitor and RemoteApp programs on high DPI devices.

The blog post is a great summary of the improvements in 8.1!

“…Windows 8.1 and Windows Server 2012 R2 provide improved remote desktop and RemoteApp experiences by dynamically updating the remote resolution and remote scale factor based on changes made locally (on the client PC), without the need to reconnect to the session. These features are enabled by default if both the client and the host are running Windows 8.1 or Windows Server 2012 R2. Dynamically updating the remote resolution is also available on Windows 7 clients connecting to Windows 8.1 or Windows Server 2012 R2 hosts with the Remote Desktop Protocol 8.1 Update for Windows 7 SP1 installed on the client…"

For the full article see: Resolution and Scaling Level Updates in RDP 8.1

Thursday, December 12, 2013

KB: Users who have the remote audio setting enabled cause the RD Session Host Servers to hang intermittently in Windows Server 2008 R2 SP1

Microsoft has released a new KB article (2895698) regarding a serious issue when using the remote audio setting on a Windows Server 2008 R2 SP1 RDSG farm! The RD Session Host could in the scenario described below. A hotfix is provided to fix the issue.

“…Consider the following scenario:

  • You set up a Remote Desktop Connection Broker (RD Connection Broker) and create a load-balanced Remote Desktop (RD) Session Host server farm. The servers in the farm are installed with Windows Server 2008 R2 Service Pack 1 (SP1).
  • You configure Audio and Video Playback on the RD Session Host Servers.
  • Users connect to the RD Session Host Servers and have the remote audio setting enabled.

In this situation, the RD Session Host Servers hang intermittently..”

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

KB: RD Virtualization Host crashes when you use patch schedule to update personal virtual desktop on Windows Server 2012

Microsoft has released a new Kb Article (2896325) regarding an issue when setting up a patch schedule on VM-Based Desktop Deployments in Windows Server 2012, in which case the Remote Desktop Virtualization Host Agent service might terminate unexpectedly.

“…Consider the following scenario:

  • You have computers that run Windows Server 2012.
  • You deploy Virtual Desktop Infrastructure (VDI) in your environment.
  • You install and configure the Remote Desktop Virtualization Host (RD Virtualization Host), the Remote Desktop Connection Broker (RD Connection Broker), and the Remote Desktop Web Access (RD Web Access) role services on the computer(s).
  • You create a patch schedule for a personal virtual desktop.

In this situation, the Remote Desktop Virtualization Host Agent service might terminate unexpectedly…”

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

Wednesday, December 11, 2013

Availability of the Remote Desktop Protocol (RDP) Patent License for RDP 8.0.

Just announced on the Microsoft RDV team blog:

“…Microsoft is pleased to announce the availability of the Remote Desktop Protocol (RDP) Patent License for RDP 8.0.

Today, partners are developing a variety of different solutions that utilize RDP. Examples of these solutions include:

  • Non-Windows thin client devices
  • RDP client and server software
  • Third-party collaboration software that consumes the RDP stream

Documentation describing the RDP feature set is available for free on the Microsoft Developers Network (MSDN) website.

Microsoft requires RDP implementers to obtain a patent license for RDP and recently made it easier to obtain the required patent license by using a fixed fee agreement. Pursuant to the fixed fee agreement, an RDP implementer receives a patent license to use the RDP 8.0 feature set to interact with the appropriately licensed Windows Remote Desktop clients and servers and any new versions of the RDP feature set released during the term of the agreement.

As an RDP implementer, you will enjoy:

  • Free documentation support via community forums
  • Invitations to protocol PlugFest events
  • Message Analyzer tool, a protocol analyzer that allows you to capture, view, and analyze network traffic
  • Test suites: Microsoft has begun releasing test suites for different protocols and will continue to roll them out over time
  • Reference source code: An optional addendum to the RDP license enables access to:
  • Source and more info: http://blogs.msdn.com/b/rds/archive/2013/12/11/remote-desktop-protocol-licensing-available-for-rdp-8-0.aspx

    Thursday, December 5, 2013

    RemoteFX vGPU Improvements in Windows Server 2012 R2

    The Microsoft RDV team have published a new blog post on RemoteFX vGPU improvements in the R2 release of Windows Server 2012.

    The blog post covers the following four improvements in great detail

    1. Improving DirectX API coverage

    2. Support for higher monitor resolutions and higher default monitor resolutions

    3. Exposing higher VRAM to RemoteFX vGPU-enabled virtual machines

    4. Higher scale by leveraging NUMA in Windows Server 2012 R2

    Source: http://blogs.msdn.com/b/rds/archive/2013/12/04/remotefx-vgpu-improvements-in-windows-server-2012-r2.aspx

    Thursday, November 28, 2013

    New article: Microsoft's non-Windows based RDP clients


    My new article “Microsoft's non-Windows based RDP clients” is now published on VirtualizationAdmin.com

    “…The Microsoft Remote Desktop Client (RDP Client) is used to connect to Remote Desktop Services (RDS) and Virtual Desktop Infrastructure (VDI) environments. Nowadays more referred to as Microsoft Virtual Desktop Infrastructure VM-based and Session Based. Traditionally, Microsoft only delivered RDP clients for Windows-based operating systems. This has recently changed and this article will talk about this change, and why this is important for the industry. It also covers an overview of one of the client’s capabilities…”

    Read the complete article here:

    Monday, November 25, 2013

    Microsoft RDV Team: RemoteApp improvements in Windows Server 2012 R2

    The Microsoft RDV team has released a new blog post discussing the Remote App Improvements in RDP 8.1 in more detail.

    Most of the info around Move/Resize and live thumbnails wad been previously published, but relatively new new is the GPO setting “Use advanced RemoteFX graphics for RemoteApp” which can be used to disable these improvements in case the impact on memory and bandwidth is more important.

    “…In some scenarios, for example if users keep multiple applications maximized that have continuous screen updates, the features mentioned in this blog could lead to an increase in memory and bandwidth usage, which could impact high scalability. If performance is more important than these improvements and this is a core scenario for your users, it is possible to disable these improvements by setting the following Group Policy setting to Disable:

    Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Remote Session Environment/Use advanced RemoteFX graphics for RemoteApp…”

    Source: http://blogs.msdn.com/b/rds/archive/2013/11/25/remoteapp-improvements-in-windows-server-2012-r2.aspx

    Thursday, November 21, 2013

    Update on Microsoft Remote Desktop Clients for iOS, Android and OS X

    Microsoft has released an update for their Remote Desktop Client for non-Windows based devices. Below the details;


    • Pinch to zoom support in Mouse Pointer mode
    • Performance improvements
    • iPhone 5 screen resolution fix
    • A number of bug fixes


    • Pinch-to-zoom support in Mouse Pointer mode
    • Performance improvements
    • Improved support for stylus input
    • A number of bug fixes

    OS X:

    • Improved full screen support for OS X 10.7 - 10.9
    • Performance improvements
    • A number of bug fixes

    Wednesday, November 13, 2013

    Remote Desktop Protocol 8.1 update for Windows 7 SP1 is now available !

    The Microsoft RDV team has announced that the Remote Desktop 8.1 update for Windows 7 SP1 is now available !

    “…With this update, users who use Windows 7 SP1 client devices will be able to connect to Windows Server 2012 R2 and Windows 8.1 remote computers and experience all the new features that the latest versions of these operating systems introduce, such as:

    · Support for faster reconnection times

    · RemoteApp experience improvements

    · Remote Desktop Gateway pluggable authentication and authorization

    This knowledge base article has more information on new features, setup instructions, and download locations. Head over there to download and install the update. Following are answers to some of the questions you might have about the update…”

    Source & more info: http://blogs.msdn.com/b/rds/archive/2013/11/12/remote-desktop-protocol-8-1-update-for-windows-7-sp1-released-to-web.aspx

    Tuesday, November 5, 2013

    GPU Requirements for RemoteFX on Windows Server 2012 R2

    The Microsoft RDV team posted a new blog on GPU requirements for Remote FX in Windows Server 2012 R2.

    “…In this blog post we’ll share our recommendations to help you understand the options available to you, and most importantly to help you make a decision on the cards that you can consider as you deploy a VDI solution with RemoteFX vGPU..”

    The reduces the complexity and provides guidance in selecting the right GPU component to address the appropriate experience for your end users.

    Source: http://blogs.msdn.com/b/rds/archive/2013/11/05/gpu-requirements-for-remotefx-on-windows-server-2012-r2.aspx

    Thursday, October 17, 2013

    Download links for Microsoft RDP client for iOS, MacOS and Android

    An overview with the download links for Microsoft's RDP clients for MacOS, iOS and Android:

    MacOS: https://t.co/NSHPFq5AgJ

    iOS: https://t.co/Gz6yvr3c16

    Android: https://t.co/FvwpdOPboo


    Microsoft's Remote Desktop Client for iOS is available!

    Last week Microsoft announced the upcoming RDP clients for iOS, OSX and android. Also see Microsoft to introduce Remote Desktop app for iOS, OS X and Android!

    The RDP client for iOS is now available and can be downloaded from the store. This blog post is a first glance at the client.


    A server URL can be specified

    image (4)

    And a RD gateway server can be specified as well

    image (5)

    The client can also be used to retrieve resources by specifying a URL, this the same (RD Web Access) url that is used by the Control Panel RADC applet as well as the Modern UI Remote Desktop client.

    image (6)

    After logging we have a RDP session available (in my case on an i-Phone)

    image (2)

    Which also contains a on screen keyboard

    image (8)

    I’ll write a more detailed blog post once I;ve had a chance to play with it some more. But so far, it looks great!

    Tuesday, October 8, 2013

    Microsoft to introduce Remote Desktop app for iOS, OS X and Android!

    Yesterday a big announcement has been made in the Microsoft Desktop Virtualization space! With the upcoming release of Windows Server 2012 R2, Microsoft will introduce their Remote Desktop Client for iOS, OS X and Android!

    In the past this has always been in the top 3 of subjects of discussion at every TechEd, MVP Summit etc. Before this announcement, Microsoft's answer has always been, we provide a great RDP client for the Windows platform and leave space for our partners to create RDP clients for other platforms. The ability to allow users to connect to your RDS environment with non-Windows clients has also been subject of discussion in every RDS project I perform for customers. To be able to allow non-Windows clients and still allow management (and not have to deal with dozens of different RDP clients) in some cases resulted in adding suites like vWorkspace, Citrix etc. to the RDS environment just to be able to have a managed RDP client for different platforms. As much as I agree that these suites add great value, some (smaller) environments simply didn’t need all that extra functionality and could easily run without it. This announcement is a big step to further allow a BYOD policy on Microsoft-only Desktop Virtualization solutions!  More info will follow soon!

    “…Further, with Windows Server 2012 R2 Microsoft is introducing the Microsoft Remote Desktop app, available for download in application stores later this month, to provide easy access to PCs and virtual desktops on a variety of devices and platforms, including Windows, Windows RT, iOS, OS X and Android…”

    Source: This announcement was part of the overall announcements you can read here:
    ”Microsoft unleashes fall wave of enterprise cloud solutions.”

    Tuesday, October 1, 2013

    My Microsoft MVP status is renewed!

    I received the email today, my MVP award in the category Remote Desktop Services is renewed for another year! 3rd MVP Award in a row, it’s an honor!

    Thanks Microsoft and everyone who made this possible!

    “…Dear Freek Berson,
    Congratulations! We are pleased to present you with the 2013 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Remote Desktop Services technical communities during the past year…”

    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
    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"

    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.


    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.


    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.


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


    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.


    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:


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


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


    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.


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


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


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


    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.


    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!


    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

    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.



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