Microsoft Azure - Remote Desktop Solutions (Part 2)

In my previous blog, I discussed two solutions available to allow remote access to your end users into your environment. In this blog, we will discuss the second option called Remote Desktop Services.

Remote Desktop Services (RDS), formerly known as Terminal Services, is a server role in Windows Server that provides technologies that enable users to access session-based desktops, virtual machine-based desktops, or applications in data centre from both within a corporate network and from the internet.

RDS is officially supported on Microsoft Azure since 2014 and with the release of Windows 2016, it now offers even more flexibility, cost efficiency and extensibility.

Depending on your environment and preferences, you can set up the RDS solution for session-based virtualization, as a virtual desktop infrastructure (VDI), or as a combination of the two:

• Session-based virtualization : Leverage the compute power of Windows Server to provide a cost-effective multi-session environment to drive your users’ everyday workloads

• VDI : Leverage Windows client to provide the high performance, app compatibility, and familiarity that your users have come to expect of their Windows desktop experience. VDI can be deployed in various flavours, I will discuss those later in this blog.

Within these virtualization environments, you have additional flexibility in what you publish to your users:

• Desktops : Give your users a full desktop experience with a variety of applications that you install and manage. Ideal for users that rely on these computers as their primary workstations or that are coming from thin clients, such as with MultiPoint Services.

• RemoteApps : Specify individual applications that are hosted/run on the virtualized machine but appear as if they’re running on the user’s desktop like local applications. The apps have their own taskbar entry and can be resized and moved across monitors. Ideal for deploying and managing key applications in the secure, remote environment while allowing users to work from and customize their own desktops.

Below is a high level architecture of an RDS deployment and it components

In above RDS architecture, below three core roles are required to setup an RDS environment:-

• Remote Desktop Session Host (RDSH): The Session Host allows a server to host session-based desktops or RemoteApp programs. Applications are installed and published from the Session Host servers.
• Remote Desktop Connection Broker [RDCB]: This role handles user sessions by load balancing among the RD Session Host servers. Also allows disconnected users to reconnect to their existing sessions without starting a new one.

• Remote Desktop Web Access [RDWA]:   This role provides a web portal to access the RDS environment. Also allows Windows 7 & 8 desktops to connect using the  RemoteApp and Desktop Connection.

• Remote Desktop Gateway [RDG]:  This role enables remote users to use the Remote Desktop Protocol (RDP) over HTTPS. It is placed on the edge of your network and acts as the entry point to your RDS environment externally.

• Remote Desktop Virtualization Host [RDVH]:  This allows RDS integration with a Hyper-V hypervisor to manage virtual desktops.

• Licensing: RDS comes with a 120 day trial period. When the trial period ends RDS will no longer accept connections. The RDS License role handles the licensing for RDS. It manages the Remote Desktop Services client access licenses (RDS CALs) that are required for each device or user to connect to a Remote Desktop Session Host (RD Session Host) server. You use RD Licensing to install, issue, and track the availability of RD CALs on a Remote Desktop license server.

Now, coming back to VDI deployment flavours. Windows Server 2016 offers the following deployment scenarios:

• Virtual machine (VM)–based.  In this scenario, Windows 10 VMs run in a Hyper-V infrastructure. You use Remote Desktop Services to provide users remote connectivity to the VMs. You can use the VM-based deployment scenario with pooled or personal VM collections.

• Session-based.  In this scenario, remote users connect to Remote Desktop Services in Windows Server 2016 and run their application in Windows Server 2016 sessions. Only Remote Desktop Services is required for this scenario.

	Session-based Desktop Deployment	Windows MultiPoint Server 2012	VM-based Desktop Deployment
User operating system experience	Windows Server 2012 R2	Windows 8.1	Windows 8.1
Support for full-fidelity video, with coverage for all media types and highly synchronized audio, rich media support, Microsoft Silverlight, 3D graphics, and Windows Aero	Microsoft RemoteFX	Requires direct video–connected stations, USB zero client–connected stations, USB-over-Ethernet zero clients, or RDP–over-LAN with RemoteFX	Requires RemoteFX
Directly connect the VDI session to client USB devices	Standard RDP connection provides limited support of USB device RemoteFX required for broader support of USB devices	Standard RDP connection provides limited support of USB device Direct video–connected stations, USB zero client–connected stations, USB-over-Ethernet zero clients, or RDP-over-LAN with RemoteFX required for broader support of USB devices	Standard RDP connection provides limited support of USB device RemoteFX required for broader support of USB devices
Supported client devices	Any device that supports RDP or RemoteFX (including Windows Thin PC)	Supports the following: Direct video–connected stations USB zero client–connected stations USB-over-Ethernet zero clients Any device that supports RDP or RemoteFX	Any device that supports RDP or RemoteFX (including Windows Thin PC)
Scaling	As many as hundreds of users for each server, but multiple servers can be added to scale to higher numbers	As many as 20 users	Up to hundreds of users for each server, but multiple servers can be added to scale to higher numbers
High availability	Supports load balancing and clustering of resources	Unavailable	Supports load balancing and clustering of resources

Also, below table provides a comparison of Pooled and Personal Virtual Desktop Collections.

	Pooled	Personal
Changes are made to	Transient virtual hard disk	VM virtual hard disk
Changes saved after session ends	No (except for user profile changes)	Yes
VM instances	Single VM master image that all users in the collection share	Separate VM instances created from a mater VM for each user
Number of images to manage	One master image	An image for each user (after the VM instance is created)
Infrastructure services	Managed network Remote Desktop Services HyperV	Managed network Remote Desktop Services HyperV
Network connectivity	Support standard Remote Desktop Services by using low-bandwidth connections RemoteFX connection requires medium- to high-bandwidth connections (depending on content being displayed)	Support standard Remote Desktop Services by using low-bandwidth connections RemoteFX connection requires medium- to high-bandwidth connections (depending on content being displayed)
Storage requirements	Storage for master image and transient virtual hard disks Storage for each User Profile Disk (if used)	Requires separate VM storage for each user; if the average storage for the master VM is 100 GB and there are 100 users, 10 TB of storage will be required
Manageability	Only one image to manage, so use stand-alone image-management tools; changes to the master image are reflected the next time a session is initiated	Manage by using technologies and products such as Group Policy, Windows Server Update Services, or Microsoft System Center 2012 R2 Configuration Manager
User flexibility	Users cannot install apps Users cannot be an administrator on their VM	Users can install apps Users can be an administrator on their VM
User profile storage	Transient virtual hard disk (VHD; user profile changes are lost) User Profile Disk (user profile changes are retained)	Stored and retained in the VM VHDs
User, operating system, and app configuration management	Roaming Profiles Folder Redirection Microsoft User Experience Virtualization (UE-V) Microsoft Application Virtualization (App-V) User Profile Disk	Roaming Profiles Folder Redirection UE-V App-V Locally stored on VM

As mentioned earlier, Azure has added supported quite a while back and a standard deployment of RDS on Azure looks like below:-

A highly available deployment that contains all necessary components to have the highest guaranteed uptime for your RDS environment will look like below:-

Hopefully, this would have given you a high level overview of RDS services. You can read more about it and what’s new is available in RDS 2016 on Microsoft official pages. A quick summary is available on a poster here.

Microsoft Azure - Remote Desktop Solutions

I am sure everyone using Azure must have done RDP connections to either cloud services or virtual machines at least once or more. Below is a standard architecture now-a-days for allowing RDP access to end users into your cloud environment using a Jump box in between hosted inside a separate subnet.

Things gets interesting when number of users requiring RDP access to cloud environment increases. By default, there is a limit on Windows OS as to how many concurrent RDP sessions it support.

A desktop version (Win 7 or 8.1) supports only 1 whereas the server versions support 2. This make things bit complicated as if you have let’s say 10 user requiring RDP access to your environment then you need 5 Jump boxes. That's not ideal and this is where you need proper service to enable that. Something like Remote Desktop Services (RDS).

RDS is a proper & recommended way for enabling remote connections when you have between 5 to 5000 users requesting/requiring RDP. It’s a feature which you can enable in Windows Server (only) and it supports various kinds of deployments for high availability, integration with Azure Active Directory etc.

The downside is, unlike remote desktop feature in Windows, RDS is not free and you require license for using this service. I will discuss the features offered by RDS and what all you get for what you pay in a separate blog but below is a quick comparison of RDS vs Remote Desktop feature.

Remote Desktop Services (RDS)	Remote Desktop Feature
Can support many simultaneous users.	Desktop operating systems are limited to one simultaneous user. Server operating systems are limited to two simultaneous users.
Proper licensing must be purchased and configured.	No additional licensing is required.
Used to access a full remote desktop or remote applications (RemoteApp).	Used to access the full remote desktop.
Supports advanced features such as RemoteFX USB Redirection and multimedia redirection.	Does not support advanced features.
Requires an infrastructure of multiple servers that has been properly planned and deployed.	Is enabled on a single computer.