XenDesktop Single User Server VDI

Using the Server VDI (Virtual Desktop Infrastructure) feature in XenDesktop 7 allows you to deliver a desktop from a server Operating System for a single user on a one to one basis. Now if you’re not quite sure what to make of this think back to Amazon’s big DaaS announcement just a few weeks ago. Remember how they got away with true one on one VDI based machines in the cloud? We all know that client based Operating System VDI’s aren’t allowed due to Microsoft’s, still limited, licensing structure, so how did they manage to get around this? Well, using the Server VDI feature is one way of doing it. I’ll try and provide you with, not only information on the Server VDI feature itself, but some general background information as well.

To start, why would we like to use this feature anyway? I mean, why not use a Hosted Shared Desktop solution instead? It’s way more cost effective and easier to set up (debatable, I know) and manage. A few weeks ago I wrote an article on Amazon’s new DaaS solution ‘Amazon WorkSpaces’ in which I also highlighted some reasons why you might need a ‘desktop per user’ solution, here they are:

  • Because your users may need to install their own updates & applications;
  • Your users, for whatever reason, need to able to modify specific system-level settings;
  • Perhaps in some cases (other than the above) administrative privileges are needed;
  • Certain users might need more processing power and memory than others, because of certain resource intensive applications they might use;
  • Dedicated / persistent storage might be needed.

Although most of the above is possible on a HSD environment as well, preferably not. Especially when the the system is being utilized by multiple users at the same time, which in a HSD world is often the case, these are configurations we would like to avoid. But what if we configure a HSD solution and assign it to just one user, wouldn’t that be the same? Yes and no. Before I continue have a look at this post as well, I found it a few days ago. It’s over five years old but gives a detailed explanation on XenDesktop’s PortICA, from where it all started. A bit outdated perhaps but valid nonetheless. A guy called Brian Madden wrote it by the way.

Some differences

I won’t repeat, and go into, all the details regarding single user machine connections, I’ll leave that to Brian, I just want to point out some of the options we have with Server VDI since I think this feature is relatively unknown by most. Do note that this feature was, or is, primarily intended for Service Providers enabling them to deliver dedicated Cloud based VDI desktops in a multi-tenant fashion bypassing Microsoft’s licensing restrictions. Of course that doesn’t mean we can’t use it within our own data centres as well. Here’s another article, taken from the Citrix Blog website, it’s about the general availability of Server VDI as officially stated by Citrix, have a look at the license requirements as well.

Back to my ‘yes and no’ comment earlier. Yes, you’ll have a single user desktop with both Server VDI and a HSD assigned to just one user, but no, they aren’t the same, and as always both have pros and cons. For example, with HSD you’ll still need to install RDS (Terminal Services), because it’s based on a multi user architecture, while with Server VDI you install a XenDesktop client VDA and you’re done (I’ll address this later on, you’ll need to use some specific parameters). Less (overhead) is better. Note that when setting up an HSD from XenDesktop 7 you’ll also need to install the VDA next to the RDS role. On the other hand, when using a Hosted Shared solution you can also publish / Host applications, this isn’t possible with Server VDI. I’ll address some more specific differences throughout the article.

Traditional licensing

When it comes to licensing not much has changed, for every user contacting your Windows Server you’ll need a separate user (Windows Server CAL) license, either per-user or per-device. I’ll use some quotes from the Microsoft’s volume licensing website. Per-user: you purchase a CAL for every user who accesses your server(s) to use services such as file storage or printing, regardless of the number of devices they use for that access. Per-device: you purchase a CAL for every device that accesses your server(s), regardless of the number of users who use that device to access your server(s).

In addition, for every user that will contact your Windows Server using RDS / Terminal Services, direct or indirect, you’ll need an Windows Server RDS CAL as well, again, either per-user or per-device, same as described above. Remember that RDS CALs only apply when configuring HSD’s and not Server VDI since RDS isn’t needed and thus not installed. The same rules apply when Citrix is thrown into the mix. For example, when we’re talking about a Hosted Shared Desktop configuration assigned to just one user, you’ll need a Windows Server CAL, a Windows Server RDS CAL and an additional XenApp or XenDesktop 7 license, depending on which edition you’re using. Using  Server VDI you’ll need a Windows Server CAL and a XenDesktop license (Server VDI is only available with XenDesktop).

SPLA licensing

The above rules apply when we’re deploying Server VDI’s or Hosted Shared Desktop solutions within our own data centers for ‘private’ use, so to speak. If you’re a Service Provider and you want to deliver dedicated Cloud VDI desktops in a multi-tenant fashion leveraging shared hardware and storage to your customers, things slightly change. This comes from the Citrix Blog mentioned earlier: On the Citrix side, this feature (Server VDI) is part of the XenApp/XenDesktop CSP Premium SKU (Platinum level functionality). On the Microsoft side, you can use the normal SPLA options for Windows Server, and a RDS-SAL (introduced not to long ago) for each user.

SPLA

The same goes for HSD as well, this (partly) comes from one of my own articles: To make use of the RDS functionality (limited to the Hosted Shared Desktop functionality) within Azure, or any other Cloud based architecture for that matter, we would need the newly introduced RDS Subscriber Access Licenses (SALs) from Microsoft (assuming that license mobility and Software Assurance is covered). This is where it gets interesting. The RDS SALs are offered as part of Microsoft’s Services Provider Licensing Agreement (SPLA) licensing. This means, to obtain these licenses, you’ll need to be a Microsoft Services Provider! Something to be aware of. As noted in one of the Citrix Blogs as well, Server VDI is by no means a cheaper solution, but in some cases it might just be your only way out.

Installation details

When configuring Server VDI we actually install a client VDA combined with the /servervdi option using the command-line. This also means that as far as XenDesktop is concerned, most of the client orientated HDX features / policies can be applied even though we are running a server OS underneath (with the exception of the features mentioned in the ‘Drawback’ section below, scroll down). Although the differences between the two aren’t that big, there are some that might be of interest, perhaps you want to have a look for yourself? See screenshot below. These, client vs server, differences have something to do with the underlying single and multi-user ICA stacks used by the agents, see the section labeled ‘Single vs multi user’ further on for a more detailed explanation on this.

HDX Policy 2

A note from the Citrix E-Docs page on the installation process: Install a VDA for Windows Desktop OS on a supported server operating system, using the installer’s command line interface. By default, the installer blocks the Windows Desktop OS VDA on a server operating system; using the command line overrides this behaviour. After installing the VDA, you create a new dedicated Machine Catalog for Server VDI. You then assign the new Machine Catalog to a new dedicated Delivery Group. Use the command-line interface to install a VDA on a supported server or server master image, specifying the /quiet and /servervdi options: XenDesktopVdaSetup.exe /quiet /servervdi. More information can be found here.

USB device redirection

USB device redirection support (also configured through policies and disabled by default) in multi user HSD and single user VDI environments is an important one as well. See your Citrix Receiver documentation for a complete list of supported devices, not everything is supported by default. For those devices that are supported optimized virtual channels, which offer enhanced performance and bandwidth efficiency over WAN links, are available to redirect USB traffic. Again, the level of support provided over these channels depends on your version of Receiver installed. Especially in high latency environments optimized virtual channels are preferred whenever possible. This applies to XenApp as well.

USB Logo

Generic virtual channel

If there’s no optimized virtual channel available to redirect specific USB traffic, which basically means that the device isn’t supported, XenDesktop offers (XenApp doesn’t) something called a Generic USB virtual channel to fall back on, which is also referred to as raw USB redirection. Due note that this channel is not ‘optimized’ so no enhanced performance and or bandwidth efficiency will be available. Now for the tricky part. This specific feature (Generic USB virtual channel support) is only available when using a single user ICA stack, let me try and explain.

Single vs multi user

Within XenDesktop 7 we have two Virtual Desktop agents (VDAs): the client VDA (XP, Windows 7 & 8.x), normally installed on desktop machines with the exception of Server VDI (as we’ve learned), and the server VDA (Windows Server 2008R2, 2012 & 2012R2), which only gets installed on server machines. The main difference between the two is the underlying ICA stack on which they are based. With the client VDA this is a single-user ICA stack (also known as PortICA, see Brian’s article mentioned earlier) meaning that only one user / session at a time is allowed, providing a dedicated one to one connection. It connects users to a machines console session, just like Citrix’s GoToMyPC, or any other remote access product for that matter. It also supports some additional HDX features / policies like Aero and Generic USB redirection (there we have it) which both aren’t available when using a multi-user ICA stack which belongs to the server VDA.

The multi-user ICA stack is the same as we are used to with XenApp, meaning that multiple users can access and use a server’s Hosted Shared Desktop (HSD) and or published / hosted applications at the same time. The only difference is that it’s equipped with a different user interface to make it compatible with the XenDesktop FMA infrastructure. So if the device at hand isn’t supported using XenApp, which we would now call a XenDesktop application server, combined with the multi-user ICA stack and, for example, the accompanying software can’t be used on a client OS based machine, than Server VDI might be a valid option. Besides, you might also find that some advanced device specific features may not work as expected even though the device has it’s own supported virtual channel. If this is the case, you could use the Generic USB virtual channel instead.

A short word on the devices supported.

For some more information on the USB devices tested with XenDesktop, see http://support.citrix.com/article/ctx123569. There might also be situations in where you would like to enable USB device redirection but not want allow all USB devices that are supported by default when enabling redirection. Using the information provided in this article you can restrict certain types of devices by updating the list of USB devices supported for redirection.

Drawbacks with Server VDI

Reading the above might lead to the impression that Server VDI is superior to HSD, unfortunately this isn’t the case. Although I do have to note that, as always, it depends on the use case at hand. I mean, if you can’t do without the Generic USB redirection feature for example, and not being able to publish / host applications isn’t an issue, than Server VDI is what you need. Assuming that a single-user connection is sufficient of course. Here’s a list of the features not available with Server VDI:

  • Personal vDisks
  • HDX 3D Pro
  • MS System Center
  • Hosted applications
  • Local App Access
  • Direct (non-brokered) desktop connections
  • Remote PC Access

Conclusion

I hope this kind of gives you an idea on what’s possible with the Server VDI option hidden within XenDesktop. It’s been there since version 5.6 and you could say that it hasn’t really gotten the attention it deserves. Although valid use cases might be limited if you’re not a Service Provider of some sort, it does offer some nice features. I’m surprised it hasn’t been mentioned more often now that we’ve seen and heard so many DaaS announcements lately, especially with Amazon joining the club. Anyhow I thought it was worth a mention none the less. Not to long ago one of my colleagues ran into some of its limitations when implementing Server VDI in a POC environment, which kind of triggered me to have a closer look. Luckily all ended well.

Bas van Kaam ©

Reference materials used: Citrix.com, Microsoft.com and the E-Docs website.

Advertisements

5 thoughts on “XenDesktop Single User Server VDI

    1. Bas van Kaam Post author

      Hi Kees, I think you just answered your own question :-)

      It all depends on what you need to accomplish and what needs to be supported, but if an application can’t run on a server OS and isn’t 64 bit compatible then obviously Server VDI isn’t an option. Perhaps normal VDI is, on premises anyway. I just wanted to highlight some of the options you have with Server VDI, and talk about some of the technology that surrounds it. But yes, use cases are limited compared to ‘normal’ VDI, the HDS model and or hosted applications, especially when implemented within our data centers. On the other hand, this technology does provide a way to offer real one to one ‘VDI’ from the cloud, sort of. Unfortunately it won’t work for all of us.

      Thanks.

      Reply
  1. Pingback: Citrix XenApp or XenDesktop: A decision tree » Ingmar Verheij - The dutch IT guy

  2. KC

    Hi Bas Van Kaam,

    Good article! But quick question – you mentioned that HSD requires RDS CALs because of the reliance of the RDS service on Win Server and that Server VDI does not require RDS CALs. But are you really certain about that?

    Brian Madden talked about this recently as well in a different scenario involving VMware View 5.3 but nevertheless the concept of Server VDI is the same – and he mentions that RDS CALs are required even in 1:1 user to Server is used.

    http://www.brianmadden.com/blogs/brianmadden/archive/2013/10/17/vmware-announces-plans-for-horizon-view-5-3-here-are-the-4-new-features-i-love.aspx

    The reason is because Microsoft has stated that the inclusive 2 simultaneous remote connections to a Server are for ‘administrative purposes’ only. So if you’re providing end-users with a desktop-like OS experience for everyday work – then you’re suppose to get RDS CALs. MS has that spelled out in their documentation – so in other words, it’s not true that you only need the RDS CALs if you’re actively using the RDS service on Win Server.

    Thoughts on this? Agree or you still disagree? Interested and open to hearing your thoughts!

    Thanks!

    Reply
    1. Bas van Kaam Post author

      Hi KC,

      Thanks for reading, and your comment of course!

      Been a while since I wrote that, I’m pretty sure I did my research, but of course I could be off :-) To be honest, I’d really need to (double) check before commenting again, haha, before I say something else that may or may not be true.

      Have a good weekend!

      Bas.

      Reply

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s