RDSH versus VDI: 2015 edition

I've given a "TS versus VDI" presentation several times in the past. It began at BriForum 2008 Chicago, where I co-presented the topic with Benny Tritsch.

I've given a "TS versus VDI" presentation several times in the past. It began at BriForum 2008 Chicago, where I co-presented the topic with Benny Tritsch. In that presentation, Benny dressed up as the mature, "proper" solution (as TS was in those days) and argued the case for TS, while I dressed up as the young scrappy VDI:

Brian and benny 2008

Our general conclusion from 2008 was that VDI was too risky and complex.

I gave the session again at VMworld 2008 (video from vmworld.com) and VMworld 2009 Europe (video from BrianMadden.com), with the main argument being that VDI was too expensive.

I presented the topic a third time at VMworld 2011 where I argued that VDI might actually have a chance, especially when it came to persistent images, but still in most cases RDSH made more sense.

Believe it or not, I'll be giving this session again (at Citrix Synergy in May and perhaps at BriForum), so I thought I'd share my thoughts about where the TS versus VDI debate is in 2015. (Well, first, I guess I should change it to "RDSH versus VDI."

What is the "RDSH versus VDI" debate about?

To take a step back, the fundamental question I'm trying to answer is how you know whether you should use an RDSH- or VDI-based solution for a particular group of users. When I say, "RDSH", I'm not talking about pure Microsoft-only RDSH, rather, I'm talking about RDSH-based application and desktop delivery solutions including Citrix XenApp, VMware Horizon 6, and Dell vWorkspace where you have a "session per user." And when I say "VDI," I'm talking about Citrix XenDesktop, VMware Horizon (6/View), and Dell vWorkspace where you have a "VM per user."

I'm also assuming here that "VDI" is based on a client-based OS (like Windows 7) and "RDSH" is (obviously) a server OS. For RDSH, I'm not necessarily talking about single-user VMs based on Windows Server OSes, though that's an option too.

Also, to be clear, I don't think this is an "all or nothing" proposition. Certainly within companies there can be a use for both, and I don't want to be dogmatic about one or the other.

RDSH and VDI are actually very similar

The most important thing to know about the "RDSH versus VDI" debate is that the two solutions are actually very similar. They're both about Windows instances running in a datacenter (whether on-premises or hosted), and they both can involve delivering full desktops, seamless published applications, or a combination of both.

In today's world, both RDSH and VDI use the same protocols and can deliver the same end user experience.

So this debate today is really just about the underlying platform.

Historical debate points

The main reason we're having this conversation in 2015 is that a lot of the advantages of RDSH or VDI in the past don't apply anymore. (This is why I need to make a new presentation, since if nothing changed then I would just tell people to watch the videos of the old presentations.)

But consider the following:

  • In 2015, both RDSH and VDI can deliver full desktops or single published apps.
  • In 2015, both RDSH and VDI can deliver either persistent or non-persistent desktops.
  • In 2015, VDI technology is more "proven" and not a crazy fringe idea.
  • In 2015, the cost (measuring in terms of user density for a certain dollar spend on hardware) is much more similar. (Previously RDSH was far cheaper than VDI because you could fit so many more users per server, but with advancements in hypervisors and server hardware, RDSH's cost / user density advantages are not enough to be the main driver of the decision.)
  • In 2015, non-persistent VDI images can automatically be spun up as users login and destroyed when the log out, so the "automatic" management advantages of RDSH don't apply.

RDSH versus VDI in 2015

So where's this leave us in 2015? Honestly there's only one major difference that I can think of: RDSH is a server OS. VDI is a client OS.

Of course you're thinking, "umm . . . duh! That's in the name!" But it's a key point.

A major advantage of VDI is the mere fact that VDI sessions run the same OS as all the other non-VDI desktops in your environment. This is important for several reasons.

First, since no enterprise is going to go 100% VDI, running your VDI sessions on the same OS as your traditional desktops and laptops means that everything is "the same."

  • You can use the same base image for all your users, regardless of whether they're accessing a remote or a traditional desktop.
  • You install your apps in the same way for both remote and traditional users.
  • You only need one set of instructions to support everything.
  • Your patch cycles are also in sync because you don't have to worry about Windows Server patches coming out at different times than Windows client patches.
  • You can also run the same OS for all your users, which means you have the same support lifecycles and the same versions of everything.

Contrast that to using RDSH for some apps and desktops while using Windows 7 for everyone else. Service Packs are different, and you have to have extra steps in all your support to figure out whether you need to follow the Server or the Client procedures.

Another thing that's still a reality in 2015 is that occasionally you do come across apps that don't work out of the box when installed on a multi-user RDSH server. Sure, there's a lot you can do in order to tweak the server to trick the app into running on RDSH, but meh, if you just use VDI with a client OS then you don't have to worry about anything.

Really the only reason you'd be forced to use a server OS is if you're a customer of a hosting provider (like DaaS) where Microsoft's license agreements don't allow them to sell Windows Client as a service (though in most enterprise DaaS environments you can provide your own Windows Client licenses for instances of Windows desktops that they host).

The bottom line

At the end of the day, in 2015, the main difference between VDI and RDSH is the simple fact that you're talking about a server OS versus a client OS. Any slight density advantages you might have with RDSH are swallowed up by the additional support costs generated by the fact that you're supporting multiple OS platforms for your users.

Again, to be clear, I'm not suggesting that you go out and migrate all your XenApp Servers to XenDesktop VDI environments, and I'm not suggesting that RDSH or XenApp are going away anytime soon. Certainly if you just need to publish a few apps here and there, it might be easier to just stand up a few RDSH servers and publish those apps from there.

But if you're talking about the platform to base full user desktops on, in 2015 I'm really leaning towards VDI for that, if for nothing else than the ease you get by having all your users being the same across the board.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

You talk about 'Enterprise' uses cases and in this space I think VDI and RDSH are equally compelling and are essentially just 'tools in my toolbox'.

One area where VDI seems to shine for me is in the non-Enterprise space, the 50-500 user companies who do not have the expertise to analyse/remediate/migrate and manage their apps on an RDSH platform.

I see many, many smaller customers adopting VDI where previously RDSH was a non-starter as they are now pretty 'hypervisor savvy' and can just take their old desktop, virtualise and manage it with no additional skills required.

In this space you want a solution which can be air-dropped into place with little or no deployment skills (low start-up cost), which can subsequently be managed by the part time IT guy who also runs the phones and buys the milk and biscuits every day.

Not saying every SMB falls into this category (before you all shoot me down!), but there is a large market out there for a cheap and easy to deploy desktop virtualisation solution (VDI in a Box anyone?) which does not introduce the additional cost and complexity of application migration to RDSH.


....and dude....you need to wear the suit and tie this time around and let some snotty nosed FUIT grad student take the moral low ground :-)


Benny lost it with the shoes!! What the hell was going on down there!?

RDSH will likely become a more compelling tech.

I've been using Unidesk for a few months now. VDI is pretty damn easy with their solution.


You are so right, Rory, the shoes were a disaster. I only had black sneakers with me, forgot to put proper shoes in my BriForum suitcase.

And BTW, I still like RDSH/TS more than VDI. Azure RemoteApp is the newest incarnation of TS-published apps, converting legacy Windows apps into a cloud service.



Oooh.. maybe we should do that session again for 2015? I just updated the photo:



Count me in, Brian. Need to check if I still have the old suit...


I agree.  The VDI market is not even 1/5 the size of the existing Server Based Computing Market anyway.  Some of the last numbers I saw was that Citrix alone has more than 100 million XenApp users including the ones accessing published apps. I made a prediction that this could be the year of a renaissance of SBC.  You can't deny the solid and time proven method that XenApp and RDSH offer in delivering desktops and management of those corresponding servers has gotten easier with new technologies.  With Citrix, XenApp servers are easier to manage than ever before and VMware is attempting to catch up in that area with their RDSH support and tools.  When you add to that new application layering technologies that support XenApp and RDSH (ahem, FlexApp and others) you have a lot of the benefits of VDI...without VDI.  Here is a link to what I wrote on the matter a couple of months ago.... vmblog.com/.../liquidware-labs-2015-prediction-year-of-the-sbc-renaissance.aspx


Agreed not much has changed.  But I sort of disagree with the statement that there are only "slight density advantages" when using SBC vs. VDI.  This is one of the myths that Dan and I were talking about at BriForum last year - LoginVSI might only show a 20% density advantage, but the SBC test is inherently flawed due to the timers they use, not to mention the extremely heavy workload that is active 85% of the time!  If you tune the timers (or reduce the activity ratio even slightly), you'll quickly see that SBC scales at least TWICE as well as VDI.  And I wouldn't classify that as "slight" - the difference between buying 500 or 1000 blades, for example, is significant in my opinion.

Check out Dan's "proof" here:


And by the way - we have been in talks with LoginVSI for the last few  months, they are aware of the timer issue and are actually going to fix it in the release that is about to come out.  So I hope you consider this when you present this year at Synergy.



IMO the main decision to be made when implementing Windows cnteralization is app publishing vs desktop publishing. Despite all the technical advances in both techs, I still think RDSH is preferable for app publishing, and VDI is  preferable for desktop publishing.