Windows 10 and Windows Server 2016 – the Old Battle of VDI Versus RDSH
UPDATE: November 28, 2018 by Jon Rolls
This blog post was first published in March 2017 and has been hugely popular, underlining how critical this debate still is over 12 years since VDI started gaining momentum.
VDI is continuously being compared to its older desktop virtualization cousin—variously known as Terminal Server/RD Session Host/Server-Based Computing—and of course the Citrix variants of MetaFrame, Presentation Server, XenApp and now just Citrix Virtual Apps and Desktops!
As we look to the emerging DaaS world, and Microsoft’s new Virtual Desktop offering, we still see the same deliberation over which model is the most economical in terms of CPU/hardware costs versus operational difficulty and application compatibility. At Ivanti our User Workspace Manager solutions cover all varieties of desktop and application virtualization, and of course physical desktops too. We continue to remain an independent value-add solution for all flavors of cloud and on-premises desktops, improving the user experience, tightening security and increasing ROI. Anyway, James Rankin nailed it in this article, so read on!
We are moving inexorably towards a world of Windows 10. Microsoft have nailed their colours to the mast – Windows 10, preferably in its Current Branch/Current Branch for Business format, is going to be the primary desktop client operating system for the foreseeable future. We’ve already discussed the issues that sit around servicing branches, changes to the Start Menu, and the development of profiles, so what more is there to discuss?
Well, there isn’t just Windows 10 on the horizon – Windows Server 2016 has also landed, and the latest iteration of Microsoft’s server-end operating system looks and works very much like its client-side little brother. Interestingly, though, despite being very similar, the Server version of the latest Microsoft operating system operates on Long-Term Servicing Branch only. Unless you adopt the Nano Server edition, which fits in to the Current Branch model, Server 2016 takes you back to the old days of updating and upgrading. And it’s worth pointing out that Nano Server has no UI, which means no graphical apps. Hmm… maybe Windows Server 2016 is now the little brother?
Many companies use virtualized end-user environments to provide their estates with a lower-cost, centrally managed alternative to traditional physical PC environments. In these instances, decisions need to be made as to precisely which desktop virtualization approach to utilize as you move towards the adoption of Microsoft’s “brave new world”. It’s not just Windows 10 that needs to be considered – there is another option.
This other option for desktop virtualization comes via Windows Server 2016 and the fact that it also supports Remote Desktop Session Host, as most of you will probably well know. In a virtualized thin-client environment, this allows administrators to publish full server-based hosted desktops to their end users. And this option in itself raises a question that has been debated probably since the early days of virtual desktop delivery – do we use full-fat VDI, or is an RDSH-based published desktop good enough?
This conversation would usually take place before you even start getting into the “holy war” of choosing Citrix XenDesktop or VMware Horizon View or A.N.Other for the virtualization platform. The vendors have no particular preference, as they support VDI and RDSH equally. For example, Citrix has XenApp and XenDesktop (which are simply different editions of the underlying XenDesktop product), VMware have Horizon which can publish resources from full Windows clients or RDSH servers…there is no preference from the vendor side as to which of these technologies is leveraged for your deployment.
In order to make the decision, we need to understand fully what the relevant similarities and differences are between the two concepts.
VDI – a holiday villa
VDI is based on an individual virtual machine running a desktop operating system such as Windows 10. The allocation ratio of VDI systems is generally one-to-one – one user per VM. There can be multiple VDI virtual machines running on each physical server, but each individual instance is used by one user at a time. You can present them as non-persistent (users are allocated a random VM from a pool each time they log on), or persistent (users always log on to the same VM from the pool each time, which is exclusively for their use). The connection to the desktop operating system and the applications that are contained within it is made from a remote system using a remote display protocol.
Using VDI is like renting a house for a holiday. You can pretty much tailor the environment to your own needs and not worry about sharing any facilities with others (particularly so if the persistent model is adopted). VDI VMs can be allocated different levels of resources dependent on the user’s particular application needs. Software that doesn’t play nicely with other applications can be isolated away. Both users and administrators will be in a familiar desktop operating system environment. Users can (if absolutely necessary) be made administrators themselves and/or allowed to provision their own applications.
However, there are drawbacks. Each user requires a dedicated virtual machine. Licensing can be complicated or expensive (although Microsoft’s recent partnership with Citrix may start to simplify this somewhat). If you’re adopting non-persistent, there may well be extra technology solutions required to enable this solution to align with the user expectations. Network bandwidth and connectivity need to be solid and reliable. If you’re using the persistent model, and you’ve allowed users the rights to customize the environment, you may find more support is required than previously anticipated.
RDSH – a motel chain
RDSH works on the principle that multiple users connect up to a server operating system and run an individual session that shares resources and the application stack with the other users on the server. The allocation is one-to-many, with the total number of users driven by the available resource on the underlying server. Unlike VDI, RDSH doesn’t necessarily require a hypervisor underneath to host it. You can also publish single instances of applications via RDSH rather than specifically full desktops (although technically you can do this with VDI as well, such as Citrix’s VM Hosted Apps feature, but this is a fairly niche area).
Using RDSH is like staying in a Motel. Each user receives the same environment and application sets, and shares resources with everyone else. RDSH systems can scale rapidly to thousands of users, without the overhead of deploying thousands of machines. Management is centralized, licensing is simpler and the overall complexity of the solution is reduced.
But just like a Motel, if someone starts hogging resources (such as bandwidth), then all the other users (or guests) will be affected. Applications designed for Windows desktops may not perform optimally on Windows server operating systems. Multi-user operating systems, by their very nature, make changes and updates more difficult to apply, whereas with VDI, systems can be taken out of service and remediated more rapidly.
Windows 10 and Server 2016 look very much alike in terms of interface. Under the hood, the real difference between the two is simply that Windows 10 provides Universal Windows Platform (UWP) or “Windows Store” applications, whereas Server 2016 – so far – does not. Therefore, if you have any requirement for the provision or usage of UWP applications, then RDSH is not yet a viable option.
But that aside, there is no real difference from a user interaction or experience perspective. The decision needs to be driven by other factors.
A huge factor is applications. For demanding applications, or ones that don’t play nicely with others, VDI is often the compelling case. Diversity within the application sets often leans towards VDI as the adopted solution. Application virtualization technology – such as Unidesk, AppVolumes, App-V, FSLogix, Cloudhouse, Numecent, FlexApp and the like - can take some of the sting out of this, but if the constraints are around resource, then often VDI takes precedence. Segregating applications can be difficult in RDSH environments without provisioning more servers.
At the moment, RDSH is significantly cheaper – to the extent that some are offering RDSH solutions based around “one user per server” in the same way that VDI has a one-to-one mapping. But this may be changing in the light of Microsoft’s partnership with Citrix to provide Windows 10 desktops from Azure, or at the very least, getting simpler. As it stands, though, RDSH is the better cost option.
User experience is often thought to be significantly better on VDI than RDSH, but this isn’t necessarily true. RDSH is often optimized so that many of the visual “bells and whistles” are removed to accommodate more users, but the Windows Server experience can be skinned to look very much akin to that from a Windows client OS should you wish it. The underlying resource is much more important to performance than the choice between VDI and RDSH, although VDI is naturally suited to graphically-intensive applications.
It has often been stated that in modern environments, you can only get 20% more users per server with RDSH than you can with VDI. However, this was done via automated testing with more intensive workloads than would normally be seen in production environments. With the workloads lightened, the percentage uptick hits closer to 100%, as can be seen in this article from Citrix.
Security risks are pretty much the same between physical, VDI and RDSH sessions. Whilst with VDI and RDSH the users are operating within a datacenter, this can only afford more security if the sessions are configured via policy to be so.
What’s the answer?
So, is there really a good answer to the persistent question of “VDI or RDSH”?
When you first think about it, especially in environments where administrators are used to managing Windows client estates, VDI often seems the simpler option. It’s familiar, the management processes are tried-and-tested, and most applications can slot into it quite comfortably.
But that’s before you explore the possibilities with RDSH. Many environments I work in start looking at RDSH as a remote access solution and then begin seriously considering it as a full published desktop provider. Delivering the server-based solution can be much easier, licensing may well be cheaper, and you can certainly support more user sessions with less initial overhead.
I think there’s really no “one size fits all” for a modern environment – not unless all of your users have identical application sets. And in the era of SaaS, “Shadow IT” and the web, this is more unlikely than ever. RDSH and VDI both have applicable benefits for most environments.
So if you’re all-in on virtualized desktops, then it may well be an option to present a “two-tiered” environment with both VDI and RDSH. For the standard “task worker” users who need access to similar application sets, then a properly-structured RDSH farm could well provide everything they need. But for users with more exotic or intensive application requirements, then VDI could simply be slotted in for them as well.
This does of course raise the issue of deploying and managing two environments, and the ever-present danger that RDSH-based users with errant processes can cause problems for all the other sessions on the same VM. Additionally, what happens when you move users between the VDI and RDSH environments according to their needs – do they have to start from a clean slate again in terms of settings and profile?
Dealing with VDI and RDSH issues
No matter which way you decide to go, Ivanti DesktopNow offers a few key areas that can make the management of your systems much easier.
Environment Manager Policy and Personalization allow you to seamlessly roam user sessions between Windows 10 VDI and Server 2016 RDSH. Both operating systems are based on the same profile version and configuration items can easily be ported between the two, but even if in future they aren’t based on the same profile version, Personalization can still move between the two. The policy side can also allow you to lock down entry points within the operating systems that can cause issues if invoked, and this can all be done from a single central configuration which uses Conditions to differentiate between VDI and RDSH.
Application Control can allow users of VDI and RDSH sessions to perform admin-level tasks (like clearing print queues and the like) without actually being given them. This gives users the flexibility without compromising system security.
File Director also ensures users’ data is securely migrated away from a specific endpoint device into the datacenter and then injected into the user workspace irrespective of whether it’s a physical or virtual desktop. This eliminates data sprawl, where users save data to their local devices, and ensures all their files can be instantly accessed from RDSH sessions too.
Additionally, Performance Manager is extremely effective at setting resource limits which is invaluable for both RDSH and VDI sessions. Errant processes can be restricted or clamped to prevent adverse effects for other users on the same VM or host.
With these tools at hand, the problems you may encounter by leaning towards the VDI or RDSH approach – or even the approach that combines both – are greatly reduced. You could even choose one and then migrate to the other, without compromising the user’s saved settings or user experience.
There’s no real fast-and-easy answer to the VDI versus RDSH debate. Knowledge, analysis and testing of your applications and user environment is the only way you can make an informed decision. But if you adopt the right toolsets to complement it, you can manage and adapt your selected environment to work awesomely for your user base – no matter what you choose.