Home > Uncategorized > Delivering Web Applications with Hyper-V hosted RD Session Host VMs and Quest Workspace Desktop Virtualization

Delivering Web Applications with Hyper-V hosted RD Session Host VMs and Quest Workspace Desktop Virtualization

Today I finished a large RD Session Host deployment using Quest Workspace Desktop Virtualization.

The deployment consisted of 8 Hyper-V Servers, each hosting 7 RD Session Host VMs.  The 56 VMs serve up seamless RemoteApps for a few web applications.

One of the requirements was to limit users web browsing to the websites that the customer needed published.  There are several ways this could be accomplished, like host files, proxy filtering, web filtering applications and probably some I haven’t thought of.

They way we chose to accomplish this was via Quest Workspace Desktop Virtualization’s URL Redirection feature.  In a nutshell we placed the VMs in an OU and linked a GPO to this OU where the Quest URL Redirection ADMX template was loaded.  In the template we specified which URL strings were allowed on the RD Session Hosts, and any other URLs that hit the hosted IE Browser got redirected back to the client device’s Internet Browser.

The customer did not mention this as a requirement when they purchased Quest Workspace Desktop Virtualization and Quest Defender to secure their applications for use by remote contractors, but it was very easy to implement.  It was nice to be able to meet a customer’s requirements on the fly, without having to scramble to figure out how.  It was simply, we can do that….

Updates to the allowed URLs can be made on the fly via GPO, and updates to the VM configuration or installed applications on the RD Session Hosts can be made to all 56 VMs in about 10 minutes by updating the template VM and reprovisioning the 56 child VMs.  Quest Workspace Desktop Virtualization automatically and instantly replicates the update VM template to all 8 Hyper-V servers, and using our Hyper-V Catalyst Components, the instant the first block of data from the VM template is replicated to each Hyper-V Server, the VMs can be rebuilt.  They will retain their MAC address, IP address, FQDN, Domain Membership, VM configuration (NIC, Memory, CPU, VLAN tags…) and of course any settings from Quest Workspace Desktop Virtualization, like applications being published.

Another thing we did that one cannot do with the in box functionality of Microsoft’s RD Broker is publish different applications on different RD Session Hosts.  This is commonly referred to as “Application Siloing”.  We had to do this because one application had different security requirements than the others.

Other components of the architecture included a set of 2 Quest Web Access and Secure Gateway VMs that were load balanced by F5 Big IP LTMs and front ended by Microsoft ISA server.  ISA Server was not a technical requirement, but the customer’s security team required all access to go thru their ISA servers.

Quest’s brokers not only load balance the RD Session Host connections, but also the placement of the VMs across Hyper-V Servers.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: