This service uses the computing power of Azure to render even the most complex models in the cloud and streams them in real time to your devices, so users can interact and collaborate with 3D content in amazing detail. Experience your 3D content in full detail View. Remote Desktop Services (RDS) is the platform of choice to cost-effectively host Windows desktops and applications. This offering is designed to help you quickly create a RDS on IaaS deployment for testing and proof-of-concept purposes. Azure is already a popular destination for Windows desktop virtualisation using the traditional Remote Desktop Session Host (Terminal Services) approach with Windows Server - RDSH accounts for. There are some situations you may want to access Azure Service Fabric virtual machines via Remote Desktop (RDP). I have got a requirement to configure VPN in Azure Service Fabric cluster.

Remote Desktop to Azure AD Joined Computer Unfortunately, at this time it isn’t quite as easy as “open up a new RDP connection, type in the computer, type my email, and connect”. If it were, this post wouldn’t be here.

In today’s network-centric world, there is no shortage of solutions available for making PC environments available over the Internet. Two of the most popular approaches, Remote Desktop Services (RDS) and Desktop-as-a-Service (DaaS), deliver approximately the same end-result.

However, RDS and DaaS are fundamentally different types of solutions. The differences matter not just for IT teams who maintain one of these platforms, but also for the end-users who rely on them to access desktop environments remotely.

Here’s a breakdown of the similarities and differences between RDS and DaaS, and why to choose one or the other.

What is Remote Desktop Services?

In Windows, Remote Desktop Services, is a platform that lets users share desktop environments between one Windows computer and another over the Internet. By setting up RDS on a Windows server, then using a Remote Desktop Protocol (RDP) application like Microsoft Remote Desktop, you can log in from another computer to a Windows environment that is hosted via RDS.

Once you log into the RDS-hosted PC environment, you can usually access all of the same local resources — including storage, applications, the Windows desktop interface and so on — that you would be able to use if the RDS environment were an actual PC that was sitting in front of you. RDS can also be configured to make only certain applications available to remote users, if admins choose to set it up that way.

Typically, the machine that hosts RDS runs in the same physical location — such as the same office building — as the computers from which users access the remote desktop environments. It is also possible, however, to install RDS on a server running in the cloud and share desktops from the cloud.

(For the record, RDS in this context should not be confused with Amazon RDS, a cloud-based database service that does not have anything to do with Windows RDS.)

What is Desktop-as-a-Service?

Desktop-as-a-Service, or DaaS, is a type of cloud-based service that allows you to run a desktop environment on a virtual machine that is hosted in a public cloud. With DaaS, you create a virtual machine using a public cloud service like Amazon EC2 or Azure Virtual Machines, install a PC operating system (like Windows 10) on it, then use an application like LogMeIn, GoToMyPC or DesktopReady to access it.

Like RDS, DaaS gives users access to all of the same applications and system resources that they would be able to use if their virtual machine environment were a physical computer instead of a virtual desktop running in the cloud.

RDS vs. DaaS

At a high level, then, RDS and DaaS both provide the same end-result: Desktop environments that are accessible by remote users over the network.

But they achieve this result in quite different ways. The main differences between RDS and DaaS include:

• Host machine: With RDS, you need a server that is running the Windows Server operating system (along with a license for Windows Server) in order to create guest environments that can be shared over the network. With DaaS, you do not need Windows Server. You can install Windows 10 or another consumer-class version of Windows directly in cloud-based virtual machines to set up your desktop environments.
• Availability: If your RDS host server goes down due to a disruption such as a power outage or a restart to apply system updates, you will not be able to access your desktop environments. Connectivity could also be disrupted if users rely on a VPN to access RDS desktops remotely and the VPN fails. With DaaS, however, no VPN is required and the entire cloud service that hosts your cloud desktops would need to fail — an exceedingly rare event — in order to make them inaccessible.
• Security: DaaS allows you to create an isolated virtual machine for each desktop that you want to host. A security issue that arises in one machine won’t affect others. With RDS, however (as well as with any other Windows-based shared desktop environment), because there are multiple desktop environments hosted by the same Windows Server instance, spillover of security problems poses a higher risk. An attacker who takes control of the Windows Server environment could potentially control all of the desktop sessions it hosts, for example.
• Manageability: With RDS, you have to maintain a physical Windows Server machine in order to share desktop environments across your network. With DaaS, the cloud vendor or DaaS provider maintains the virtual machines for you; you need only to manage the software environments running on them (unless that task is also handled by the DaaS provider).
• Accessibility: Accessing RDS sessions from a location other than the one where the RDS server exists may require use of a VPN or a complex networking configuration. This can pose a challenge if, for example, you have employees who need to access their desktop environments from their homes. With DaaS, no VPN or special networking setup is necessary. With a DaaS platform like DesktopReady, users can log in to their desktops through their Web browsers, from any location.
• Scalability: When you use RDS, the number of desktop environments you can host, and the amount of CPU, memory and storage resources you can assign to them, are limited by the resources available to the Windows Server host machine. On a DaaS platform, however, you can easily allocate more resources to your cloud desktops as needed.

When to use RDS and when to use DaaS

Azure Remote Desktop Services 2019

Because of these differences, RDS and DaaS cater to different types of needs.

RDS makes sense if you already have Windows Server running, and you have an in-house IT team that is capable of managing RDS. RDS also works best in situations where the users of your remote desktop sessions will be in the same physical location as the RDS server.

In contrast, DaaS is a better solution for organizations seeking a hands-off remote-desktop solution that can be accessed from anywhere, with minimal deployment and maintenance effort on the part of the organization. DaaS also offers greater opportunities to scale up by creating additional desktop environments, or assigning more resources to existing ones, as needs change.

The bottom line: Although RDS and DaaS may seem like basically the same thing, it’s important to understand the major differences between each approach, identify your organization’s needs and determine which solution is the best fit for them.

‍

Over the past few months I have had the opportunity to implement Remote Desktop Services in Azure. The strategy of this project was to go beyond a “lift and shift” mentality of an RDS deployment to an infrastructure that will scale on demand and provide for rapid deployment of new resources as needed. In this post I give a high-level view of the RDS services deployed and the Azure services used to support them.

Running RDS in Azure provides a high degree of availability compared to hosting in a conventional data center. For example, Azure has native features such as Availably Sets and Load Balancing services to limit interruptions from planned and unplanned outages. Azure also has network resilience built in. Hosting a reliable externally available RDS environment on-premises requires redundant internet connections, BGP and underlying Routing and Switching infrastructure. In Azure, simply provision an external IP and the rest is built in.

The illustration in this post provides a visual of the Azure services used in this project and how they relate to each RDS service. More detail is provided below.

RD Web and RD Gateway

To start with, the Remote Desktop Web (RD Web) service provides a web-based landing page for users to log into and access services published to them. The RD Gateway acts as a middleman between Web to RDP services, tunneling RDP traffic over port 443. Providing RDP services over the internet without exposing the RDP port.

Azure Load Balancer – Standard Windows Network Load Balancing (NLB) will not work with Azure. Instead, Microsoft Azure offers software load balancers with all VM (except for “Basic” VM’s). Load balancers provide HA by redirecting traffic to active nodes if one becomes unavailable. Azure Load Balancers provide HA on the RD Web/RD Gateway servers and the Connection Brokers in this implementation.

** Please note, A reader pointed out that the correct name for the service below is Azure AD Application Proxy. That is different from the Application Gateway**

Azure AD Application Gateway Proxy– It is common practice to expose the RD Web page to the internet for external access, relying on forms-based authentication to protect the site. The Azure AD Application Proxy is used to provide an extra layer of security to the RD Web Page. The Azure AD Application Proxy is a cloud-based proxy service. It works by installing an agent on a server inside your network. This agent makes an outbound connection to the Azure AD Application Proxy services, establishing a two-way connection. Internal services can be published in the Application Proxy services and made available externally without opening ports on a firewall.

An added benefit to the Azure AD Application Proxy is it can use Azure AD authentication services as a “pre-authentication” to the RD Web server. This way, Azure AD authentication, including MFA if enabled, is required prior to accessing the RD Web page.

RDS Connection Broker

The connection broker acts as a traffic cop for RDP sessions. It monitors active connections to the session hosts and directs new connections accordingly. It also reconnects disconnected sessions to the same server, preventing orphaned connections.

Azure SQL – Multiple Connection Brokers provides HA, but requires a central database. Azure SQL Server provides this central database for the Connection Broker cluster. Microsoft has outlined the steps to use Azure SQL for a Connection Broker Cluster here.

Azure Remote Desktop Services

Session Host Auto Scale – It costs money to run servers on Azure. However, it doesn’t cost money when they are shut down and in the deallocated state. With that in mind, a higher number of smaller, less expensive VM’s as Session Host servers were provisioned. These servers can be powered on and deallocated as usage increase and decrease, providing a cost savings.

Microsoft provides an auto scale script here that runs on the Connection Broker and brings Session Host Servers online as demand increases and shut them down when the need decreases. To do this, the script needs to log into Azure to control the Session Hosts power state. The script can be configured with user name and password credentials, or a more secure certificate option. The certificate option uses an Azure AD Service Principle login, storing the certificate in the Azure Automation certificate store. This provides additional security as it is not necessary to store your credentials in the script.

Session Hosts

The Session Host is the resource users interact with as a remote desktop or published application. As mentioned previously, these can be shut down and powered on as needed by the auto scale script. This can be a problem however when it’s time to patch the servers. An Azure Automation Runbook is used to start all Session Hosts during their patch window. The Runbook uses the Azure Key Vault to store the credentials used to log into Azure and start the VM’s. Azure Auto Shutdown is used at the end of the patch window to shut down and deallocate the VM’s.

Azure ARM Template Deployment

Azure Terminal Services

Azure ARM Templates are used to deploy all VM’s in this environment. Although not unique to RDS, it is worth a mention. ARM templates provide a way to quickly deploy a large number of VM’s. One feature of ARM Templates called Copy Index allows for creating multiple VM’s in parallel. Templates are used to rapidly scale out the number of session hosts in this project.

Azure Remote Desktop Services Step By Step

Passwords for items such as local computer and Domain Join accounts are secured in Azure Key Vault. The ARM template references those secrets during the deployment. This prevents storing credentials directly in the template file.

Azure Desired State Configuration is used to finish server setup tasks. This service can add roles and services, copy file, set the time zone and make many other configuration changes. Azure ARM Templates and DSC cut the deployment time down to a fraction of what a traditional server deployment takes.

More information on ARM templates and DSC can be found here.