BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
VMware made a long overdue decision to better support RDSH and add application publishing in Horizon 6, giving shops more options to support task workers.
Some of the earliest business computers used a shared access method with remote screens. Way back in the distant IT past, green screens provided access to line-of-business applications. Dozens, or even hundreds, of staff members shared one mainframe or minicomputer. In those days, a single application met all the needs of many employees, and task workers were the backbone of the information business.
Today, task workers are still a common class of users, and they can still use a shared computer in the data center (though they probably need more one than application now).
Task workers use a very limited range of applications, and they are usually only allowed to make a small number of changes to their work environments. Call centers are the typical example: lots of employees with tightly controlled computing environments. Many of these users get nonpersistent desktops, but they are also very well served with a shared desktop. And the decreased overhead per user in Remote Desktop Session Host (RDSH) settings reduces the cost of delivering desktops to users.
How VMware revived RDSH support in View
It is a little known fact that VMware has supported RDSH desktops since the first release of View. Terminal Server desktop pools could contain multiple RDSH servers and would balance the concurrent user sessions across the servers. Oddly, VMware downplayed this support, making less and less mention of it with each new View release.
One of the gaps in RDSH support was the remote display protocol. View uses the PCoIP protocol to deliver a high-performance remote display for View desktops. Before Horizon 6 however, RDSH desktops could not use PCoIP and had to fall back on the inferior Remote Desktop Protocol. The lack of support for PCoIP and application publishing suggested that VMware did not feel RDSH was important to its customers.
With the release of View 6.0, now called Horizon View, VMware has removed both of these restrictions.
View vs. RDSH
With Horizon View and other VDI products, each user can have his or her own virtual machine (VM) with the operating system -- such as Windows 7 -- and applications inside. This means one desktop for each user, usually provisioned from a golden image.
Often the VMs are disposable; everything the user cares about is delivered to the virtual desktop as the user logs on, and is then extracted at logoff. Then, the desktop can be reset to the base, pristine state to await the next user. View provides the connection brokering and VM provisioning, as well as the remote display protocol and clients for all manner of devices and operating systems. View also provides a way to deliver desktops securely over the Internet, without a virtual private network.
Microsoft's RDSH has been with us for more than fifteen years (called Terminal Services in the earlier days). RDSH allows multiple staff members to share a single Windows Server in a data center and still have a desktop delivered to the screens in front of them.
For a user with modest requirements, this can be the most efficient way to deliver a desktop. A group of users shares the overhead of running an operating system instead of getting a dedicated VM and OS for each user. You can support the same number of users with less hardware using RDSH.
One of the great uses of RDSH is to reduce data latency. A database application that needs fast access to the database server may perform very poorly over a wide area network (WAN), particularly a trans-continental WAN.
Running the database application on an RDSH server close to the database server can remove the data latency. Latency will still be there, but it is transferred into the remote display protocol. In this case, it's important to be able to deliver just the application without the whole desktop.
This application publishing method delivers a remote application to the user's desktop. It makes the application behave like it is running on the user's desktop, even if the RDSH server is on the other side of the Atlantic.