Native RDS in Server2016 - Part 1 - The Basics

Part 1: The Basics (you are here)
Part 2: RDVH
Part 3: RDSH
Part 4: Scaling and HA

As is the case with a number of Microsoft workload technologies, particularly in the End User Compute (EUC) space, Microsoft provides you with the basic tools to fulfill a particular requirement or use case. If you want to get more granular with management or fancier with features, your next step would be to invest into their partner ecosystem to expand upon the base offering. Such is and always has been the case with Remote Desktop Services (RDS). Remote Desktop Virtualization Host (RDVH) and Remote Desktop Session Host provide a very functional, but basic solution for virtual desktops or shared sessions. If you want greater granularity with an increased feature set while wanting to stay on Hyper-V, you can upgrade into the Citrix XenDesktop or XenApp product space. If you want to use vSphere as your hypervisor you could run RDSH VMs natively or add greater management granularity and features by buying into the VMware Horizon product space. At the end of the day, no matter which way you go, if you intend to deploy shared sessions or shared virtualized applications, as most environments do initially, Microsoft RDSH is the technology underneath it all. This series will cover the what, why and how of the native Microsoft RDS stack for Server 2016.

Use Cases

The first thing to decide is whether you need shared sessions/ published apps (most common) or dedicated pooled or personal virtual desktops assigned 1:1 to each user. RDSH is the most widely deployed technology in this space and where most environments initially invest to virtualize published applications or deploy a shared hosted workspace. If the shared session/ app solution falls short in any way or if users need greater dedicated performance, the next step is to isolate users via pooled or personal virtual desktops. Pooled desktops can be refreshed for each new user (non-persistent) while personal desktops are dedicated to a user (persistent). Pooled desktops or shared sessions can make use of User Profile Disks (UPD) which store user settings and folders in a central location. A collection can make use of both folder redirection as well as UPDs.
Virtual desktops are completely complimentary to published applications which can reduce the complexity of the template used for a collection while lowering the resource consumption of VMs running within. This is done by offloading the running applications to RDSH hosts keeping the desktop VMs leaner thereby yielding greater density per compute host. Multipoint is now an installable role in Server 2016 RDS which is useful for single-server multi-user scenarios not requiring RDP across the network. For Server 2016 all uses cases can be built on-premise, in the cloud, or a hybrid of the two. This blog series will focus on the on-premise variety which is also most common.

What's new in RDS 2016

Personal Session Desktops - A new type of session collection that allows users to be assigned to a dedicated RDSH VM (Azure deployments)
Gen2 VMs - Full support for Gen2 VM templates for pooled/ personal VM collections and personal session desktop collections
Pen Remoting - Surface Pro stylus devices available for use in RDS
Edge browser support
RemoteFX Virtual GPU - OpenGL, OpenCL, DX12, CUDA, 4K resolution, Server OS VMs, 1:1 Direct Device Assignment
Windows Multipoint Services - Now a part of RDS as an installable role for super low cost single server solutions, RDSH required
RDP10 - h.264/ AVC 444 codec, open remoting
Scale - RD Connection Broker capable of supporting 10K concurrent connection requests

Solution Components

At a very basic level, if you want shared sessions you need the RDSH role enabled on physical hosts or Server VMs. If you want virtual desktops you need Hyper-V and the RDVH role enabled on the physical host/ parent partition. Best practices suggest that only Hyper-V and RDVH roles be enabled on physical hosts, all other roles should exist within VMs to enable better scale, HA and portability. It is important to note that neither SQL Server nor System Center Virtual Machine Manager (SCVMM) are required for a basic RDS deployment.
The RDS management infrastructure for Server 2016 has two deployment scenario roles and four Services roles which can be deployed within a single VM for POCs or very small environments.

Hosts

• Compute hosts - Hyper-V hosts used for the sole purpose of running RDSH VMs or pooled and personal desktop VMs.
• Management hosts - Hyper-V hosts used for the sole purpose of running RDS infrastructure components such as Connection Brokers and Web Access servers.

Deployment Roles

• RDVH - Virtualization Host role provides the ability to deploy pooled or personal desktops within Hyper-V, organized via collections. Enabled within parent partition of Hyper-V enabled host.
• RDSH - Session Host role provides the ability to deploy servers or VMs hosting shared sessions or published applications, organized via collections. Can be enabled within physical or dedicated RDSH Server VMs.

Services Roles

• RD Connection Broker - The broker is the heart of the operation and connects users to their desktops, sessions or apps while load balancing amongst RDSH and RDVH hosts. This role is mandatory.
• RD Gateway - The gateway role is used to securely connect internet-based users to their session, desktop or app resources on the corporate network. This role is optional.
• RD Web Access - Enables users to access RemoteApp and Desktop Collections via the Start menu or web browser. This role is mandatory.
• RD Licensing - Manages the licenses required for users to connect to RDSH sessions, virtual desktops or apps. This role is mandatory after 120 days.

Collection Deployment Options

• Sessions/ apps - Users connect via RDP to a RDSH host or VM to run a full desktop experience or a published app. All users connected to a single RDSH host share the physical resources of that host. In 2016 users can be configured to connect to a dedicated RDSH host (useful for Azure and desktop licensing rules).
• Pooled desktops - Non-persistent desktop VMs created within a collection that have power state and automatic rollback capabilities to create fresh VMs for each user login. User settings can be stored on a UPD.
• Personal desktops - Persistent desktop VMs created within a collection that have power state managed and are permanently assigned to a user of the desktop. This collection type does not require nor support the use of UPDs.
• User Profile Disks - UPDs can be added to any session or pooled desktop collection to persist user profile data between session or desktop connection activities. One UPD per user.

View of the various RDS infrastructure roles as portrayed within Server Manager:

Architecture

Here are all those pieces showcased in a basic distributed architecture, separating resources based on compute and management roles as I like to do in our Dell solutions. You'll notice that there are a couple of ways to connect to the environment depending on where the user is physically as well as which resource they need to connect to. SQL Server is listed for completeness but is only required if you intend to add HA to your RDS deployment. Pooled (non-persistent) and Personal (persistent) desktops are functionally similar in that they are both based on a template VM to deploy the collection but only sessions and pooled collections can make use of a UPD. The storage hosting the UPDs is illustrated below as external to the management hosts but it could also be a file server VM that exists within. This RDS architecture can be deployed using traditional shared storage, software defined, or local disk.


Part 1: The Basics (you are here)
Part 2: RDVH
Part 3: RDSH
Part 4: Scaling and HA

Resources

Technet