by
Ron Oglesby
Since my last article on the Virtual Desktop Infrastructure (VDI) topic, I have received a number of e-mails. Some show interesting tips, some are just angry at life (and me specifically at the time of their writing), and some point out some interesting solutions that are trying to fill the ‘pie in the sky’ VDI solution I discussed last time.
Now personally, I haven’t seen a solution that makes me jump up and down saying “this is the end all be all for VDI!” However, I have seen some interesting takes on the problems I pointed out previously. Because of the e-mails and calls I received, I’ve decided to do a series of articles on the different VDI solutions available today. In this article I’ll discuss a solution (forthcoming) from Citrix for VDI implementations, and in future articles I’ll look at packages from Leostream, Propero, and any others I can get my hands on.
Before I get into the Citrix solution I need to qualify it some. First of all, the Citrix solution is not on the street yet (while the ones from Propero and Leostream are). Second, the Citrix solution I’m going to describe is a “stopgap” solution. Citrix is working on a full featured solution for release at some point in the future and is targeting a solution that covers most of what I described in the first article. The solution they are going to release now is a stopgap to help their existing customers with the VDI issues they face and is not meant as the end-game.
Okay, with the qualifications out of the way let’s talk about Citrix’s stopgap solution they’re calling the “Remote Desktop Broker” (or RDB). The concept with RDB is pretty simple; it’s an application that can feed parameters into the RDP client and provide you a way to manage connections and create resource pools of desktops (VMs, blades, etc.). The RDB application is installed on a Citrix Presentation Server and then published as an application. Users execute the application which then connects them to the type of desktop they (or the app) is configured for.
I’ll get into more detail on HOW it works in a second, but for now understand that it’s an application, not a server, and because of this is it uses a double-hop scenario with ICA connecting to the Presentation Server and then RDP connecting from the Presentation Server to the virtual desktop.
If you imagine an exiting Citrix environment (shown above) using an ICA client to connect to a Presentation Server, you’ll note that you have some of the items you need to provide a really solid VDI solution. You have a web interface that will allow for “publishing of the desktop,” you have the inherent SSL connectivity for remote users that Citrix already provides, and you have some session management and some tools to show connections and their status. So what’s missing? A way to pool desktop resources, handle peripherals, etc. Citrix’s RDB will handle some of this for you.
Citrix’s RDB will sit on top of your existing Citrix infrastructure. The concept is that the desktop broker application will be installed on your Presentation Servers. This application will communicate with an RDB database that will contain connection information for different pooled desktops. As pooled resources are used, they will be noted in this database so that the desktop is noted as “in use” and the next user will be routed to an unused desktop. If you look at the image above you’ll see that a connection will look something like this:
- User connects to a Citrix Web Interface server (or uses some other Citrix client)
- Based on the credentials, a published application is made available for that user (in this case the RDB application).
- The user launches the RDB application and is connected to the Presentation Server via ICA
- Once the application loads, the user is routed to virtual desktop based on information in the RDB application. This is basically passing parameters to the Microsoft RDP client on the Presentation Server to tell it what end desktop to connect to.
- During execution RDB is going to check its database to determine which desktop is available from the pool the user is connecting to.
- This information is passed to the RDB application which in-turn uses it to establish an RDP session to the Windows XP VM or blade.
- When the application is closed the desktop is released.
In looking at this you’ll notice right off that be that this is a “one session for the price of two sessions” deal. It’s a double hop. While it gets you to the desktop, its obviously not the most optimal configuration around. Citrix knows this, and this isn’t their long term design, but with this should come some cautions.
- Speed screen latency reduction features will not help here. Most functionality/assistance you get with speed screen latency reduction features focus on making the users think that latency is not effecting their ICA session. Basically it works by detecting the font and size and color of the text being typed in the Citrix session then instead of waiting for that text to appear on the client it shows it on the client before the round trip communication ever happens. In this case the RDP client is essentially an image or movie like application and typing within it is an image change, NOT text within a field or form on the Citrix server. (Check out this article for more details.)
- Not all features available in Citrix will be available in the RDP session. There will be some features (noted later in this article) that you are used to with Citrix, but since it is not ICA to the XP Pro, it will not be full featured.
I could put a third point here about it being a double hop, and the cost of a Citrix license without getting full features, etc., but I think that’s implied with these two other cautions.
In caution number two I noted that you won’t get all of the features (Speed screen, good printer redirects, driver replication, pure session mgmt in the XP pro desktop etc), but you will get some. Citrix plans to offer the following:
- Client Drives Access. Users can share drive mappings between their hosted desktop and server drives. I must note I had mixed results with Client drives mapped to the Citrix session then mapped to the XP Pro session, but server drives did show up in my XP Pro desktop.
- USB Key Drives. Users can access USB devices through their hosted desktops; however, the key must be connected prior to session startup.
- Audio. Users launching a hosted desktop the user can hear audio (for example, using Microsoft Media Player), though this may require some ICA channel reconfiguration if you use RDB on an existing application host.
- Single Sign On. When the user logs into the Citrix Web Interface and connects to the published hosted desktop, they can be automatically logged into their virtual desktop using Citrix Password Manager. This one was kind of a pain for me as I do NOT use password manager and I was required to sign into the Web Interface and then Sign in again to the Virtual Desktop. (Suggestion: Password Manager for free would be nice!)
- Printing. Users can print to locally installed printers as well as network printers. I had a couple of interesting issues with this that I believe are more related to the XP Pro desktop than the Citrix session. Again it leads back to not having a control agent with the XP Pro desktop and needing to do some manual configuration on the images used by the users.
The long and short of this solution is that it is a stop-gap. Basically it’s an application that will allow you to create pools of VMs or XP blades for your users, and use your Citrix servers as a proxy mechanism. Citrix is hoping that it can help its existing customers get over the big hurdles here by delivering a brokering mechanism and allowing them to leverage the existing Citrix tools to solve the other issues I’ve previously mentioned (secure remote access, web-based authentication, etc.).
The disappointment to me is that Citrix wasn’t out in front of this a long time ago. Last year at VMworld people were all over themselves talking about Citrix servers on VMs or about running VM workstation instances on Citrix (which, by the way, is a ridiculously stupid idea) instead of focusing on creating real VDI tools and solutions. Hopefully the time-to-market on this won’t be too long and the follow-on product that will solve most of this product’s issues will not be to long of a wait.
In my next article in the series I will take a look at Propero’s VDI solution. I was going to use Leostream’s solution first but had a slight issue with it during configuration that I will have to discuss during the article. As always, e-mail or post comments, I look forward to most of them. J