Brian Madden recently posted a blog “Is VMware tricking customers into using more expensive VDI where RDSH would meet their needs for a lower cost?” 

He argues that customers should really do their homework and understand the use cases before abandoning RDSH over non-persistent VDI.  He also mentions some of the claims the VMware EUC document makes against RDS. In the comments section, Harry Labana (former Citrix CTO for XenDesktop group) mostly agrees and adds that scalability numbers of VDI and RDS are getting closer  (See my previous blog for the numbers) so if you can justify the higher cost and the use case you may want to go for VDI.

Additionally, Adam Carter from Microsoft RDS team also blogged debunking the FUD by VMware Microsoft VDI vs. VMware View: Freedom of Choice  around RDS and points out that flexibility and use cases are the key to choosing the right delivery model.

The common point between Brian’s and Adam’s blog is that there are use cases for both RDS and non-persistent VDI desktops. I completely agree and believe that empowering IT and offering them greater flexibility will help them solve their problems. If you want to offer your end users a fully managed and locked down desktop with only enterprise apps, then there is no better solution than RDS (think call centers, support centers, university labs).

Unlike what VMware would want you to believe, you actually can offer a locked down desktop via RDS and allow users to personalize their desktops with personalization persisting between sessions (think UE-V and Citrix universal profile solution). RDS further enables you to deliver virtual, seamless Windows apps on non-windows devices and tablets which is great for BYO scenario with easy access to their apps without launching the entire desktop.

There are lots of claims around the RDS solution in the VMware’s document but let’s clear up some of the most common  misconceptions  in this blog.

Application-to-application conflicts are NOT RDS specific  When spreading FUD regarding this topic, one thing which VMware document doesn’t tell you here is that the application-to-application conflict can also occur in a VDI environment.  This is not a Citrix or RDS specific issue. You can’t run multiple versions of native IE on the same client machine. VMware has this exact same issue with their VDI offering and they try to solve this problem using their application streaming solution ThinApp. XenApp recommends grouping servers by applications, which optimizes IT operations and helps eliminate problems faster. With Citrix XenApp you can also use App-V to solve application-to-application compatibility issues. App-V comes as a part of the RDS CAL licenses so there is no additional cost involved.

One user/session DOES NOT bring down the whole server:   As Adam from Microsoft describes in his blog – going back to Windows Server 2008, services run in Session 0, and user sessions run in isolation starting with Session 1, so there’s no direct interaction between users and services. Generally speaking, this means an application crash in a user session can only affect that user; it won’t bring down services or other users on the same server because of this isolation.  The isolation between sessions also effectively creates a security barrier between user sessions—with the proper security configuration, user data is only visible to the user session where it is being used.

RDS DOES NOT have broad application-compatibility issues – I won’t say that 100% of the apps are compatible with RDS, but I would argue that it is getting extremely hard to find an app which won’t work on a terminal server platform. Microsoft and Citrix have worked together for over a period of 20 years to squash most app compatibility issues and have jointly published several best practice guides. Citrix AppDNA is the best practice solution for organizations to utilize in determining the best way to deliver applications (native, hosted, streamed App-V). AppDNA is proven to reduce the risk, time and cost of app migration. VMware doesn’t offer a solution like this and you will need to obtain one or struggle greatly to manually configure your applications.  Because of the experience  Citrix has in this area, most major enterprise apps have been verified via Citrix Ready program to give you additional peace of mind. Microsoft also offers RDS Application Analyzer  to determine if an application has any behavior that would prevent it from properly running in a multi-user environment.  Citrix has over 250,000 successful XenApp users and that number continues to grow   Even on the off chance an app might have a compatibility issue, Citrix XenApp VM hosted apps solves those one-off instances by ensuring IT can deliver ALL apps to their users

RDS environments CAN offer the same level of user personalization as non-persistent VDI  –  This is  another claim where VMware document only tells half the story.  VMware claims that unlike RDS base desktops, non-persistent VDI allows users to install apps inside their desktop. What they don’t tell you is that  even with non-persistent VDI a user who installs an app on the image will lose that app once he or she logs off and the desktop is reset thereby nullifying any changes the user made.  Citrix (profile management solution) and Citrix Ready partners (RES software, AppSense, etc.) offer unified profile and personalization management tools across RDS and VDI based desktops.  You as customer again have lots of options and flexibility around user personalization in virtual environment.

Recently released XenDesktop 7 offers VDI, RDS, virtual applications and Remote PC Access solutions using a single architecture.  We as a community can argue all day long about the best way to deliver lock down desktops (RDSH vs non-persistent VDI)  but with XenDesktop7, you can mix and match the use case to the user and offer the best desktop using a unified delivery architecture with common protocol, provisioning and policy engine.  There are uses cases for everything non-persistent VDI, persistent VDI and session bases desktops.

I would love to hear about other arguments around non-persistent vs RDS. Please add your comments and discuss this topic.