Microsoft’s Remote Desktop Protocol has been around for 20 years, but even avid users still only have a vague understanding of the concept and its applications. In the Demystifying RDP series, we try to cover the basics.
Since then, the RDP technology has evolved rapidly. Truth be told, it’s become a complex picture which only a few people really master. In, this blog post, we’ll try to bring some structure into the picture, the different options, the different elements, the high-level benefits, and the downsides. We’ll also explain how Awingu adds benefits on top of RDP and the different ways to deploy it. We’re not yet going into the full detail in this post, but we’ll deep dive into some of those areas in subsequent posts. Now, let’s get started.
VDI vs. RDS
Microsoft’s Remote Desktop Protocol (RDP) is the main ‘glue’. It’s the protocol used to connect clients (e.g. laptops, desktops) to operating systems and applications that are running on a remote device. Typically, this will be a Server, but in some cases, it might also be a personal computer. We can identify 2 models in which RDP is used.
The following picture tries to give a summarized overview – which we’ll explain in some more detail below.
Virtual Desktop Infrastructure (VDI)
In VDI, the client connects to a dedicated “host” running a client version of Windows, such as the Windows 7 or Windows 10 that is running on your laptop. The “host” will typically be a Virtual Machine, but in theory it could also be a PC (on the condition that it’s connected to network and power). This Virtual Machine is dedicated to the client and cannot be shared. We’ll touch on Windows 10 multi-user capabilities in a later post (as the details are not known, nor public, at the time of this writing).
As end users can access a remote but ‘dedicated’ operating system, they can also get admin rights and install desktop applications etc. themselves. From an infrastructure perspective, VDI is considered expensive as every user would typically have his own Virtual Machine running a version of Windows and there is no resource sharing.
Remote Desktop Services (RDS)
Microsoft RDS, in contrast to VDI, is a server-based technology. (Note: previously, RDS was named ‘Terminal Server’). It doesn’t run on the (for example) Windows 10 version you run on your PC, but on ‘Windows Server’. The biggest benefit of that is that your infrastructure resources can be shared: multiple users can access the same operating system at the same time. What are end users accessing? This could be a full ‘desktop’ or a single ‘application’. In case of the full desktop, this will be Windows Server – which is typically ‘skinned’ to make it look like a desktop version of Windows. It is, however, not a desktop version, meaning that some desktop applications might not be able to run.
RDS – Remote Desktop Services – is a framework of roles. These are explained below. For a simple VDI connection (without RDS), you don’t need all these roles.
We already mentioned that RDS can be used to give access to full desktops, as well as to (single) applications. For the latter, ‘RemoteApp’ comes into the picture. This is a subset of Microsoft RDS which gives the end user the impression he only has access to a single and isolated application (e.g. Microsoft Excel) without the operating system behind it. In the former, you would use ‘RemoteDesktop’ and install applications (e.g. Microsoft Excel) on this desktop. The end user will then remotely launch his Windows (Server) and inside Windows open Excel. Note: RemoteApp is only available as of Windows Server 2008R2. Technically, the RDS technology can also be used to connect to VDI-based desktops. That means that you can connect via RDP to a VDI, but also via RDP over an RDS platform to a VDI.
Given the fact that the infrastructure is shared, end users can’t enjoy admin access. From an economic perspective, however, the consumed infrastructure will be considerably lower compared with VDI.
Visualizing RemoteDesktop vs. RemoteApp
Awingu’s workspace with a mix of RemoteApp & RemoteDesktop based services, including
A. Bob50 deployed as RemoteApp
B. Windows 10 deployed with BOB50 as a local app
Opening a published RemoteApp application in Awingu
Opening the same application in a published RemoteDesktop in Awingu
How do end users access their VDI or RDS environment?
From the client side, by far the most used access mechanism is the use of an RDP Client. This is available from Microsoft on Windows, but there are other versions available also (on Windows, and other OS platforms such as Linux and MacOS). This client needs to be installed on the end user’s device. For most end users, the initial setup and connection will require some help from (typically) the IT department. Furthermore, it requires additional security measures to be in place, as discussed in our article about the 2017 WannaCry ransomware attacks.
Example: connect to RDP on a Windows 10 device
Since a few years, access via HTML5 and without a dedicated client software is increasingly popular. In this case, the browser becomes a very efficient client. Given all devices these days are equipped with browsers, they don’t require additional software to be installed. The latest version of RDP comes with RDWeb which also brings HTML5 capabilities. This is only available on the most recent version of RDP and thus not available on versions older than Windows Server 2016. Read more on HTML5 as client of the future in this blog post.
Since its conception, Awingu has been based on using the browser as the sole client, delivering RDP in HTML5 via the proprietary Awingu HTML5 Gateway.
Example: login to an Awingu workspace via any browser (Chrome browser in windows 10 shown)
The typical components of an RDP deployment
Until Windows Server 2019, RDP has been closely tied to the version of Windows Server. This meant, if your applications were running on Windows Server 2008 for example, you would be bound to the capabilities (and limitations) of this version of RDP.
RDS itself is the combination of a number of components or ‘roles’. Not all roles are always required. In some cases, they will require additional infrastructure to be made available. For a simple VDI connection (without RDS), you don’t need all these roles. Here is the overview:
Remote Desktop Session Host (RDSH)
Enables a server to host both RemoteApp programs as well as session-based desktops (RemoteDesktop). Users can connect to the RD Session Host servers in a session collection to run programs, save files, and use resources on those servers. Users can access the Remote Desktop Session Host server by using the Remote Desktop Connection client or by using RemoteApp programs. Note: for VDI, you don’t require RDSH.
Remote Desktop Virtualization Host
Enables users to connect to virtual desktops by using RemoteApp and Desktop Connection.
Remote Desktop Connection Broker
Allows users to reconnect to their existing virtual desktop, RemoteApp programs, and session-based desktops. It enables even load distribution across RD Session Host servers in a session collection or across pooled virtual desktops in a pooled virtual desktop collection and provides access to virtual desktops in a virtual desktop collection. In very simple deployments, the Connection Broker is not required.
Remote Desktop Gateway
Enables authorized users to connect to virtual desktops, Remote-App programs, and session-based desktops over a private network or the Internet. Basically, it enables secure access from a public network into a private network (more specifically to the Session Hosts, brokers, VDI’s,…).
Remote Desktop Web Access
Enables users to access RemoteApp and Desktop Connection through the Start Menu or through a web browser. RemoteApp and Desktop Connection provides users with a customized view of RemoteApp programs, session-based desktops, and virtual desktops. For the web browser-based access, you should imagine a webpage that displays published applications and desktops. When the user clicks to open, it will traditionally trigger the locally installed RDP client to launch and connect.
Remote Desktop Licensing
Enables a server to manage RDS client access licenses (RDS CALs) that are required for each device or user to connect to a Remote Desktop Session Host server. RDS CALs are managed using the Remote Desktop Licensing Manager application.
Awingu adds layers of value and security on top of RDP
Awingu is a ‘unified workspace’ and a ‘workspace aggregator’. It offers a browser-based, and thus HTML5-based access to Windows applications and desktops, Linux-based desktops, web and intranet applications, SaaS and files. For Windows-based applications and desktops that are deployed in “Server Based Computing”, Awingu builds on top of RDP. Similar to other technologies such as Citrix, VMware, Parallels, Ericom and the likes, RDP is always the core building block.
Awingu adds different layers of value and security on top of ‘naked’ RDP:
- Aggregate: Awingu doesn’t just give you access to Windows applications and desktops, but also to files, intranets, web applications, SaaS, Linux desktops & apps, …
- Enhanced Security: naked RDP is vulnerable to cyber-attacks. Awingu can minimize these risks: multi-factor authentication is built-in; SSL encryption is built-in, usage auditing is built-in, …
- Rich HTML5 experience: Awingu has perfectioned it’s HTML5 access for many years with useful additions such as a virtual printer, support for Function keys and in-app downloading.
- Open API & Multi-tenant: contrary to RDP, Awingu itself is multi-tenant and fully Open API based. Perfect for ISV’s, MSP’s and CSP’s.
- Collaboration built-in: with Awingu, you can share access to application sessions and share documents of any size in a secure and controlled manner
Do you want to know more about how Awingu can help you to secure your IT environment? Get in touch with us!