As a key part of the original team at Microsoft that launched the service, I created this 5-part series to provide a review of how we got to Azure Virtual Desktop.
There’s a lot of history in this product and a lot of learnings from previous technologies in the space. In this second blog post in the series, we dive into Remote Desktop Services/Server (RDS).
Remote Desktop Services (RDS): A Brief Overview
RDS is an enterprise product, part of the Windows Server operating system, that allowed administrators to build environments that could be accessed remotely at scale. It was built as an on-premises technology and introduced to the market in 2008.
The process for enabling RDS is outlined like this: you install a certain set of roles, usually on separate hardware, that allow users from distributed locations to be able to resolve that IP address, the DNS name, and from there get a connection broker to find a particular device on that server.
Comparing RDS to Terminal Services
RDS is the next iteration of Terminal Services. It made the service more enterprise ready, able to scale, and also included infrastructure.
When you’re doing a 1:1 connection, it’s very easy to get the connection. And it could be done with Terminal Services. But when you’re managing thousands of users connecting to a server farm, there is a need for records and processes. You need to keep certain information about the user being connected to, their machines, identify which machine they got disconnected, and identify if they are getting back put on the same machine.
The other huge use case that RDS enabled was remote applications.
RDS Introduces Remote Applications
RDS is a complex product, and it introduced its own terminology. An important term to remember is RDSH which stands for Remote Desktop Session Host. Instead of having to send the entire screen or image like we did with Terminal Server, with RDS and RDSH we could send just one application screen at a time.
RDS Allows for (better) Multi-session
RDSH also offered improved handling of multi-session. Once you are connected to an RDS environment there will be multiple active sessions on that server. The improvements for better sharing of computing resources and improved isolation. This improved the user experience and helped combat issues with resource constraints.
On-Premises RDS Requirements + Challenges
On-premises RDS requires licensing requirements, hardware requirements, and network prerequisites. You need a network that connects all your devices (and likely servers). And one that uses the same operating system across all hardware, and servers.
Once you get your hardware and configure your network, you install your operating system, and then have to configure the Windows Server roles. Web access, the gateway, the connection broker, the license server, the RDSH itself are roles in Windows which IT admins were required to enable.
Each role was somewhat complicated to configure and there were many challenges because of its on-premises nature. Questions persisted like:
- What if your environment is distributed?
- What goes into the RDSH?
- Do you give them a single session? Do you give them multi session?
- How do you deliver the applications without a payload?
It required a tremendous level of expertise to properly navigate these questions, and properly configure RDS environments. Add to this application and OS update management and it was clear the product would need further tweaking to best fit the needs of remote working and allow for easier management of remote access technologies.
Learn more about the eventual evolution of Azure Virtual Desktop in our next blog in this series. It takes a look at RDS in Microsoft Azure and the impact of the Microsoft cloud on EUC (end user computing).
