Microsoft Remote Desktop Services is often pigeonholed as a session-based virtualization tool. IT can, however, use it for both VDI and app virtualization, as well.
Microsoft Remote Desktop Services, a platform for implementing virtualization on Windows Server computers, can cause confusion for some.
People often assume that VDI and RDS are mutually exclusive, and that RDS offers only session-based virtualization. Microsoft RDS, however, provides both session-based and VDI capabilities, as well as application virtualization.
Introducing Microsoft RDS
Windows Server includes all the components necessary to implement a scalable RDS deployment that can accommodate distributed and fluctuating workflows. IT teams can deploy session-based virtualization, VDI or both and implement application virtualization in either deployment.
With session-based virtualization, multiple users can connect remotely to a Windows Server computer that's set up to host a multisession deployment. The users connect to a common server desktop, but each user works within an individual session that provides the resources for everyday tasks.
Session-based virtualization is simpler to implement and maintain than VDI, but it also means users share server resources, which can lead to contention and performance issues. In addition, some applications are not designed for session-based access by multiple users.
With VDI, each user connects to a dedicated virtual desktop running a Windows client operating system, such as Windows 10. The Windows Server computer hosting the virtual desktops uses the Hyper-V hypervisor to abstract the physical compute and storage resources and make them available to the individual VMs that support the desktops.
In this way, IT can provision each VM with the compute and storage resources to support the desktop and its applications, thus avoiding the contention and application issues with session-based deployments.
Organizations can deploy RDS on premises, in the Microsoft Azure cloud or both. Regardless of how IT uses it, Microsoft RDS allows end users to access their virtual desktops and applications from their own computers or mobile devices, whether they work behind the corporate firewall or connect from a public network.
Microsoft RDS desktops and applications
IT can provide users with either a full virtual desktop or with virtual applications. A full desktop delivers an experience similar to a local desktop, except users connect to the desktops remotely. Users can configure settings, work with files, install applications and more, the same way they would on their local devices. The goal is to deliver an experience that is as close as possible to working on a local desktop.
For application virtualization with RDS, organizations can use Microsoft RemoteApp to deliver virtual applications to users' devices rather than providing them with full remote desktops. RemoteApp makes it possible to run an application on a Windows Server but deliver it so it appears to run on the user's device.
IT pros might do well to consider Microsoft RDS for their VDI and virtual application deployments.
Virtual applications can run within the context of a server session or within a VM running on Hyper-V. The application image is delivered over the network to the user's computer, where agent software renders the image so the user can interact with the application directly. From the user's perspective, the application operates as if it's installed locally.
When people think about Microsoft's virtual application capabilities, however, they usually think about App-V, a client-based virtualization product that works much differently from RemoteApp. Unlike RemoteApp, App-V runs an application in a sandbox on the endpoint separate from locally installed applications.
Microsoft RDS components
Many Microsoft RDS components are the same whether IT deploys session-based virtualization or VDI. IT implements the components as server roles on the Windows Server computers that make up the RDS platform.
Remote Desktop Session Host (RDSH) makes it possible to host session-based desktops and applications organized into collections that can span multiple RDSH servers. Because the RDSH role is specific to session-based virtualization, it's better for smaller deployments where multiple users share the same RDSH server.
Remote Desktop Virtualization Host implements VDI deployments made up of VMs running on Hyper-V. Each VM is configured with one of the supported Windows guest OSes, which include the Enterprise editions of Windows 10, Windows 8.1, Windows 8 and Windows 7 SP1. All VMs within a collection must run the same guest OS. IT can define multiple collections to accommodate heterogeneous virtual desktops.
Remote Desktop Connection Broker is responsible for managing all the incoming remote connections from the client devices to the RDSH servers. The Connection Broker can handle up to 10,000 concurrent login requests, balancing the load across multiple RDSH servers. It requires SQL Server or Azure SQL Database to store deployment information such as connection states and user-host mappings.
Remote Desktop Gateway enables users to connect securely to their virtual desktops and applications on public networks. The gateway establishes an encrypted Secure Sockets Layer tunnel between the user's device and the gateway server. It also authenticates the user into the deployment and passes traffic between the user's device and the virtual resources.
Remote Desktop Web Access enables users to access their virtual desktops and applications through a web portal, which provides the structure to publish desktops and applications to client devices. The role uses Hypertext Transfer Protocol Secure to provide encrypted connectivity between the client devices and the virtualized resources.
Remote Desktop Licensing provides the structure to manage the client licenses users need to access virtualized resources.
Smaller organizations can combine roles onto one server depending on the workloads. Larger organizations can deploy each role to multiple dedicated servers to support scale-out scenarios. The RDS servers can run on either bare metal or within VMs.
A Microsoft RDS deployment also usually includes file storage for persisting configuration settings, personalization data and other resources. In addition, RDS requires Active Directory (AD) or Azure AD to control access to the virtualization deployment.
The final piece of the puzzle is the Remote Desktop client software that runs on the users' devices. Microsoft provides clients for Windows, Apple macOS, Apple iOS and Google Android devices. The RDS platform utilizes the Remote Desktop Protocol to communicate between the servers and clients. Microsoft also provides the Remote Desktop web client, which lets users access their RDS desktops and applications with a compatible browser.
Make sense of Microsoft RDS
Despite its versatility, Microsoft RDS is primarily used for session-based deployments, with IT turning to other services for their VDI and virtual application needs. IT pros might do well to consider Microsoft RDS for their VDI and virtual application deployments, especially if they've already committed to Windows Server. Of course, it also depends on their virtualization requirements and what tools they already have in place.
