chanpipat - Fotolia
VDI vs. RDSH doesn't matter if users don't need full Windows desktops
Most companies don't need to publish full Windows desktops anymore -- users mostly just need their applications. That means there's no reason to discount RDSH in favor of VDI.
Much of the talk about desktop virtualization over the past few years has been about VDI. That term describes running a client-based OS (such as Windows 7) as a virtual machine in some far-off data center while the user's client device does little more than display the remotely generated pixels and transmit keystrokes and mouse clicks to the remote host.
What most people fail to remember -- especially when getting excited about VDI -- is that there's another technology that is almost identical to VDI. Microsoft Remote Desktop Session Host, or RDSH, is just the modern name for Microsoft Terminal Server, a product that was initially released way back in 1998 and has remained largely unchanged since then -- I mean that in a good way!
RDSH includes "session host" because multiple users log into the same virtual machine (VM) at the same time, but each user has his or her own "session." From the user's standpoint, RDSH and VDI are identical: The user clicks a button on his client, enters his credentials, waits a few seconds, and boom! -- a Windows desktop is presented that's actually running in some remote data center.
From the IT pro perspective, RDSH was always a bit trickier than VDI because administrators had to jump through a few more hoops to make sure everything was configured properly. For example, you wouldn't want one user to install a new application onto "his" Windows desktop only to have that application's icon show up on the Start Menus of every other user connected to that same server.
IT admins tended to put up with these quirks because RDSH traditionally offered much more user density per server when compared with VDI. A few years ago, a typical dual-processor 1U server could often host 600 or 700 RDSH user sessions versus maybe only 150 VMs with VDI.
In more recent years, however, the gap between RDSH and VDI has narrowed, thanks to advances in virtualization and hypervisor technologies, causing many IT staffers to think, "Well, if I can get almost the same amount of VDI users on a server as RDSH sessions, and if VDI doesn't require all that special tuning to make sure one user session doesn't affect another user's session, maybe I should just go with VDI?"
Deliver apps, not full Windows desktops
That line of thinking makes a lot of sense, especially for companies that use remote desktop technology to deliver entire Windows desktops. But the irony is that just as we're getting to the point where VDI and RDSH technologies are similar in terms of cost and user density, the core reason you'd choose one or the other isn't as important. In other words, in today's IT environment, publishing a full remote Windows desktop is not as important as it once was.
This is due to the fact that today's users aren't typically looking to their IT departments to provide them with complete remote desktops. Instead, they just want IT to provide them with their applications. Today's users already have their own computers, laptops, phones and tablets, which give them access to email, calendars, shared files, their expense apps, travel booking, etc.
This means that IT departments need to find a way to provide access to single Windows desktop applications, and the trend today is to provide those applications via RDSH (or via third-party products based on RDSH, such as Citrix XenApp or VMware Horizon 6).
When it comes to delivering single Windows applications from a data center, RDSH-based systems are cheaper and more scalable, and they are much simpler to install, configure and manage than the "full" desktops required for VDI.
So if you need to provide a single Windows application or a handful of Windows apps, join the many IT departments today that are re-examining "old-school" RDSH technologies. Chances are you can build your solution on RDSH in a fraction of the time it would take you to get up and running on VDI.
