Providing users access or performance has become a hot and constant topic amongst organizations, especially today where pandemics and job market forces demand remote work.
If you’re evaluating how you can better enable a remote workforce, keep the below in mind when you compare your options. Let’s start by defining some terminology. You’ve likely heard of Virtual Desktop Infrastructure (VDI), Remote Desktop Services (RDS), Remote Desktop Services Host (RDSH), and Terminal Services all as options for providing your users access to programs and services on your server.
Let’s start small with Terminal Services / RDS
Terminal Services is deprecated terminology. It’s now referred to RDS, or remote service desktop services. It is often used interchangeably with RDS, RDSH, and VDI. This is technology that relies on Microsoft’s Remote Desktop Protocol (RDP) to allow more than one individual to utilize an application that is installed on one or more server. This is opposed to the application being installed locally. The differentiating factor between Microsoft’s RDS technology and VMware’s product boils down to the protocol being leveraged. VMware uses PC over IP (PCoIP) developed by Teredici or Blast, developed by VMware, to optimize bandwidth utilization to provide a better user experience.
VDI is also used as a blanket term. It can refer to individual virtual machines that act much like a physical desktop. It can also refer to applications that are hosted on server that many users can work with. For instance, you could have 20 users opening the same application using RDS or RDSH. These applications would likely be installed on an operating system like Windows Server 2016 or Windows Server 2019.
Virtual desktops versus virtual applications
This is a very important distinction to make as your use case will determine what solution works best for you. You can use one or a combination.
Virtual Desktops generally make sense if you want to provide users with an experience they’re familiar with. Virtual desktops will behave much like a traditional laptop or desktop. Each person is assigned an individual machine.
These machines can be persistent, meaning that they behave exactly like a traditional workstation and need to be treated as such. They’re created from a base image much like one you may already deploy to your desktops and laptops. Security updates need to be applied, applications installed, etc. Generally, this works very well for a small deployment and in my opinion is the simplest to configure and maintain.
Conversely, these machines can also be non-persistent. Non-persistent machines provide a substantial amount of benefits at the cost of more administrative overhead. The machines are replaced at whatever interval you choose — at log-off, once a week, or whenever you need to update your gold image.
With non-persistent machines, you want to have your applications installed and configured and make sure that users are not saving data locally (as it will be wiped away when the machines refresh). You also can use a very lean gold image but deploy virtualized applications on the fly depending on an individual’s needs. When done correctly, this process is invisible; the applications will appear to be installed even though they’re virtual disks that are mounted on the machine (typically at log-in).
Profile management is also a factor with non-persistent machines. Since they do get refreshed, individual user settings will be overwritten. There are several options for managing profiles, though that is a topic all its own.
Virtual applications are installed on a server operating system and are generally used by more than one person. These can be extremely useful for applications that may require a significant amount of manual configuration by the administrator. A good example would be an application that could use several third-party plug-ins and extensions, like Microsoft Great Plains. Some of these extensions can require configurations that just aren’t practical to automate. For instance, if only three users in your organization utilize an application that may take several hours of research to package and deploy effectively, it may not be a great use of time to struggle through that process when it could be installed and configured one time but used by multiple individuals.
When selecting RDS or VDI, start by asking what problem are you trying to solve? Are you trying to enable lots of users to access a workload-heavy, critical application? Are you trying to leverage cutting-edge hardware to run it? Are you trying to seamlessly deploy and manage users or applications? Or did your boss tell you to do some research and determine if it would be more cost effective than upgrading laptops and desktops every three to five years?