Planning and Deploying Session-based Virtual Desktops

Session-based virtual desktops are widely used by organizations to provide remote access to data and applications in a centralized and controlled environment. In Windows Server 2012 R2, Remote Desktop Services (RDS) provides the infrastructure to implement session-based virtual desktops and virtual machine (VM)–based virtual desktops.

In older versions of Windows Server, session-based desktops were provided by a feature named Terminal Services. Terminal Services had the same basic functionality for session-based desktops as RDS, but RDS has been extended with additional functionality to improve the user experience and manageability.

Understanding RDS

RDS is a Windows Server role that provides much more than just remote desktops. RDS includes six role services that enable you to create a scalable and fault-tolerant RDS deployment. You can manage an RDS deployment centrally and in the same way, regardless of the number of servers in an RDS deployment. This makes RDS very scalable.

One of the most common uses for RDS is the deployment of session-based virtual desktops. In a session-based virtual desktop, all processing is performed on a Remote Desktop Session Host (RD Session Host) server, and the results are displayed on a Remote Desktop client. The communication between the client and the RD Session Host server uses Remote Desktop Protocol (RDP).

RDP is a very efficient protocol and sends a limited amount of data over the network. This makes it possible to use RDS to provide desktops and applications for users over a LAN, from branch locations over a WAN, or over the Internet.

RDS includes the following functionality:

• Provides users with a full desktop Whether you use session-based virtual desktops or VM-based virtual desktops, you can provide users with access to a full remote desktop that you can access from almost anywhere if you configure the necessary infrastructure.
• Provides users with access to applications You can use RemoteApp to provide users with access to applications running on an RD Session Host server. These applications run in a window just as regular applications do on users’ desktops. From the user’s perspective, applications delivered by RemoteApp function as if they are installed locally.
• Allows secure remote access without using a virtual private network The Remote Desktop Gateway (RD Gateway) role service is used as a proxy for accessing session-based virtual desktops or VM-based virtual desktops. This is suitable for securing access from the Internet.

The Terminal Services functionality found in older versions of Windows Server had only session-based virtual desktops and applications. In Windows Server 2012 R2, you also can use RDS to deploy VM-based virtual desktops. Connectivity to the VMs is done by using RDP, just as in a session-based deployment.

Some benefits of using RDS for virtual desktops and applications include the following:

• Easier application deployment and updates A typical application deployment requires you to install and update the application on each client computer. In all but the smallest environments, this requires you to implement some type of automated deployment tools for applications. With RDS, you only need to install and update applications on the central servers. This is significantly less work than installing and updating applications on individual client computers.
• Simplified access to data and applications When you implement RDS, applications and their data can be accessed from anywhere. You can allow users to use applications from a computer in the office, a home computer, and mobile devices.
• Faster access to remote data Access to data over a virtual private network (VPN) or WAN links often results in poor application performance. For example, an application that requires access to a SQL server may be very slow if the connectivity to the SQL server has high latency. When you use RDS, you place the central servers with the application installed close to the application data, and network latency is removed as a performance problem.
• Higher data security for mobile users Without RDS, mobile users copy data onto a mobile computer and take it with them. Or, in some cases, they use a VPN to access data remotely while offsite. In both cases, there is a risk that the mobile computer could be lost or stolen and the data accessed by unauthorized users. When you use RDS for remote access to data, there is no need to copy data to the remote device. This mitigates the risk that your organization will lose control of the data.
• Simplified client hardware management Using RDS to provide virtual desktops reduces the effort to manage client device computers because the devices are performing much less work. Computers used to access virtual desktops become essentially disposable because the only configuration information they contain is the connection information to the remote desktop. In some cases, you may be able to extend hardware life because the client device is performing very little work.

Comparing RDS and the Remote Desktop feature

Remote Desktop is a feature in Windows 8.1 and Windows Server 2012 R2 that enables you to connect to a computer remotely and to view its desktop, just as when you sign in to that computer locally. The primary intention of the Remote Desktop feature is remote administration. That is why, when you enable the feature, by default only the administrator who enables it can connect to the remote desktop. Other users can connect to the remote desktop only if you grant them permission.

RDS is a Windows Server role that is available only in the Windows Server operating system. To deploy RDS, you need to install at least three role services and perform an additional configuration. RDS provides a similar experience to the Remote Desktop feature, but the primary intention of RDS is to enable users to have a standard remote environment that is available from any device and to use remote resources while integrating remote applications on the local user desktop. Table 8-1 compares RDS and the Remote Desktop feature.

Table 8-1 Comparing RDS and the Remote Desktop feature

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.

RDS architecture

There are six RDS service roles that can be included in an RDS deployment. At minimum, you need to have the Remote Desktop Connection Broker (RD Connection Broker) role service, the Remote Desktop Web Access (RD Web Access) role service, and either the RD Session Host or Remote Desktop Virtualization Host (RD Virtualization Host) role service. You can install individual RDS role services, but you won’t be able to manage them unless they are part of an RDS deployment. Depending on your implementation goals, an RDS deployment can include additional RDS role services, and RDS role services can be installed on multiple servers for scalability and high availability.

Windows Server 2012 R2 RDS includes the following role services:

• RD Session Host This role service configures a server to provide session-based desktops and applications. Users can connect to an RD Session Host server and then run applications and use the network resources that the RD Session Host offers. RD Session Host is a required role service in a session-based desktop deployment of RDS.
• RD Virtualization Host This role service integrates with the Hyper-V role in Windows Server 2012 R2 to provide VMs that can be used as virtual desktops. The RD Virtualization Host role service also monitors and reports on established client sessions to the RD Connection Broker role service. This role service is responsible for managing the VMs that function as pooled and personal virtual desktops. If VMs are in a saved state, the RD Virtualization Host role service starts the VMs to prepare them for a user connection. For pooled virtual desktops, the RD Virtualization Host role service reverts the VMs to their initial state when users sign out. The RD Virtualization Host role service is required in a VM-based deployment of RDS.
• RD Connection Broker This role service manages connections to RemoteApp programs and virtual desktops, and it directs client connection requests to an appropriate endpoint. The RD Connection Broker role service also provides session reconnection and session load balancing. For example, when a user disconnects from a session and later establishes a connection, the RD Connection Broker role service ensures that the user reconnects to his or her existing session. This role service is mandatory in all RDS deployments, but it does not require large amounts of server resources.
• RD Web Access This role service provides a web-based interface to RemoteApp programs, session-based virtual desktops, or VM-based virtual desktops. A webpage provides each user with a customized view of all RDS resources that have been published to that user. This role service supports organizing resources in folders, which enables administrators to group remote applications in a logical manner. It also publishes available RDS resources in an RDWeb feed, which can integrate with the Start screen on client devices. RD Web Access is a mandatory role service for each RDS deployment.
• Remote Desktop Licensing (RD Licensing) This role service manages RDS client access licenses (RDS CALs) that are required for each device or user to connect to an RD Session Host server. You use RD Licensing to install, issue, and track RDS CAL availability on an RD Licensing server. You are not required to install this role service during an initial RDS deployment, but an RDS deployment without proper licensing ceases to function after 120 days.
• RD Gateway This role service allows authorized remote users to connect securely to RemoteApp programs and virtual desktops from outside the organization over the Internet. An RD Gateway server acts as a proxy for external users to connect to internal RDS resources. To increase compatibility with firewalls in public locations such as hotels, RDP traffic is encapsulated in Hypertext Transfer Protocol Secure (HTTPS) packets. Access is controlled by configuring Remote Desktop connection authorization policies (RD CAPs) and Remote Desktop resource authorization policies (RD RAPs). An RD CAP specifies who is authorized to make a connection, and an RD RAP specifies to which resources authorized users may connect.

All deployment and management of RDS is done by using Server Manager, as shown in Figure 8-1. Server Manager provides an overview of all servers in an RDS deployment and a management interface for each server. RDS in Server Manager uses a discovery process to detect the role services that are installed on each machine that is added to Server Manager.

Connecting to virtual desktops and RemoteApp programs

Windows client operating systems include Remote Desktop Connection (RDC), which is used to connect to virtual desktops and applications. Microsoft also provides Microsoft Remote Desktop for iOS and Android devices. All of these applications use RDP to connect to virtual desktops and RemoteApp programs.

When you use RDC to access a computer with the Remote Desktop feature enabled, you enter the IP address or DNS name of the remote computer, as shown in Figure 8-2. This type of direct connectivity doesn’t work when connecting to RDS because you are connecting through the RD Connection Broker and need to be directed to a specific collection for the RemoteApp program or virtual desktop.

After you implement servers for the RDS infrastructure, you need to create collections that define what the clients are connecting to and how it is configured. There are two types of collections:

• Virtual desktop collections This type of collection contains VMs hosted on RD Virtualization Host servers.
• Session collections This type of collection contains RD Session Host servers that provide session-based virtual desktops or RemoteApp programs.

To connect to collections in RDS, you need to have an .rdp file with the correct connectivity information for the RD Connection Broker and the collection to which you are connecting. RDC uses the connectivity information in the .rdp file.

You can create an .rdp file manually and make it available to users. When the user opens the .rdp file, RDC launches and connects to the RD Connection Broker. This method is functional but relatively complex because you need to learn the syntax for creating .rdp files and need to update them if your infrastructure changes.

The simplest way to provide user connectivity to RDS is by using RD Web Access, shown in Figure 8-3. When users connect to RD Web Access, they are provided with a list of collections to which they have access. When they click the appropriate collection, an .rdp file with the correct configuration information is generated, and RDC launches using the information in the .rdp file. This provides a consistent access method even if the RDS deployment is modified.

The following process, shown in Figure 8-4, is used when clients connect to a session collection by using RD Web Access:

1. Users connect to the RD Web Access portal and identify the RDS resource to which they want to connect.
2. Users click the link on the RD Web Access portal for the RDS resource they want to access. This downloads the .rdp file, which contains information about the resource to which the user wants to connect.
3. RDC is launched, and it uses the information in the .rdp file to initiate a connection with the RD Connection Broker role service. After users authenticate to the RD Connection Broker role service, the RDC passes the request about the RDS resource to which the user wants to connect.
4. The RD Connection Broker role service examines the request to find an available RD Session Host server in the desired collection and sends the connection information back to the RDC client. If the request matches a session that already is established for the associated user, RD Connection Broker redirects the client to the server in the collection where the session was established. If the user doesn’t have an existing session in the collection, the client redirects to the server that is most appropriate for the user connection, based on the RD Connection Broker load balancing algorithm—for example, weight factor, fewest connections, and least utilized.
5. The RDC client establishes a session with the RD Session Host server that RD Connection Broker provided.

RDS functionality that enhances the client experience

RDC uses the RDP protocol to connect to RDS servers. The following are some of the specific features available that enhance the client experience:

• Bandwidth reduction features When an RDP connection is established, various methods to reduce network bandwidth are used, such as data compression and caching. Caching enables an adaptive user experience over LANs and WANs. Clients can detect available bandwidth and adjust the level of graphic detail that is used.
• Full desktop or application window only When a client connects to RDS, it can display either a full remote desktop or only the window of a remotely running application (RemoteApp program). With full desktops, users can perform remote administration or run multiple applications. However, the user must deal with two desktops: local and remote. RemoteApp programs integrate with local desktops, but they still require network connectivity to RDS.
• RemoteApp programs that look and feel like locally installed applications The window displayed when you connect to a RemoteApp program looks like a locally installed application. Links to RemoteApp programs can be added to a client’s Start screen. RemoteApp program icons support pinning, tabbed windows, live thumbnails, and overlay icons. RemoteApp windows can be transparent, and the content of a RemoteApp window displays while you are moving it.
• Reconnection to existing sessions If a user disconnects from a remote desktop session, the user can reconnect to the session and continue to work from the point at which he or she disconnected. The user can connect from the same device or from a different client device. If a session disconnects for a different reason, for example, because network connectivity is lost, the user automatically reconnects to the disconnected session when network connectivity is restored.
• Redirection of local resources Client resources such as drives, printers, the Clipboard, smart card readers, and USB devices can redirect to a remote desktop session. This enables you to use locally attached devices while working on RDS and to use the Clipboard to copy content between a local and remote desktop. You even can redirect USB devices that you plug in when the remote desktop connection already is established.
• Windows media redirection This feature provides high-quality multimedia by redirecting Windows media files and streams from RDS to a client. When Windows Media Player is used in a session-based virtual desktop, the multimedia file is not rendered on the RD Session Host. Instead, the multimedia stream is redirected to the RDC client and is rendered on the client. This reduces load on the RD Session Host and provides higher quality audio and video playback on the client. If the RDC client does not have the necessary codec for the multimedia content, then the content is rendered on the RD Session Host.
• Multi-monitor support This feature enables support for up to 16 monitors of any size, resolution, and layout. Applications function just as they do when you run them locally in multi-monitor configurations.

• Single sign-on (SSO) When users connect to RDS, they have to provide their credentials again. With SSO, a user can connect to a remote desktop or start a RemoteApp program as the user who signed in to the local computer, without reentering credentials.
• CPU, disk, and network Fair Share Fair Share features are enabled by default on RD Session Host servers to ensure even resource distribution among users. One user can’t monopolize resources or negatively affect the performance of other users’ sessions. Fair Share can distribute network, disk, and CPU resources dynamically among user sessions on the same RD Session Host server. You can control Fair Share settings through Group Policy.

RemoteFX

RemoteFX introduces a set of enhancements to RDP that enables rich graphics and video capabilities within a remote desktop session, regardless of whether you are connecting to a session-based virtual desktop, running a RemoteApp program, or connecting to a VM-based virtual desktop. In all three cases, the user experience is almost identical to using a local physical desktop. RemoteFX is included in RDS, and you don’t need to enable it explicitly unless you want to use the RemoteFX virtual graphics processing unit (vGPU) on a VM-based virtual desktop. In that case, you must add hardware to the VMs that are used for the virtual desktop.

The following is a list of some RemoteFX features:

• RemoteFX for WAN This feature delivers an improved user experience over lower-speed networks, such as at a branch office, on a wireless device, or working from home over a WAN connection. RemoteFX for WAN combines the RemoteFX Adaptive Graphics feature with intelligent WAN-aware transports. TCP and UDP can be used for remote desktop connections. The protocol that is better suited for the current connection is selected automatically, and automatic detection of network conditions to adjust the encoding of content is available.
• RemoteFX Adaptive Graphics This feature dynamically adapts to changing network conditions and optimizes encodings based on the content delivered. RemoteFX Adaptive Graphics use multiple codecs, which are optimized for different types of content, such as text, images, and video.
• RemoteFX Media Streaming This feature provides redirection of multimedia content. When a user attempts to play multimedia content in a remote session, the content is intercepted and redirected to the client. The client receives the compressed content, decodes the content, and plays it back locally.
• RemoteFX Multi-Touch This feature extends the Windows 8.1 touch experience to devices on which multi-touch is the primary means of user interaction. Windows 8.1 users are able to interact with remote desktop sessions in the same way as a local desktop, including support for multi-touch gestures and the ability to navigate between local and remote sessions by using touch.
• RemoteFX USB Redirection This feature enables devices to redirect at the USB level. Because of this, no device drivers are required on the client computer, and any USB device—including audio, storage, all-in-one printers, and scanners—can be redirected.

Remote Desktop Connection configuration options

When you connect to a virtual desktop through RDS, RDC is configured automatically by using an RDP file that is provided by the RD Web Access server. When you use RDC to connect to a server or client with the Remote Desktop feature enabled, you can configure the connectivity settings manually. The configuration options are grouped on several different tabs. Microsoft Remote Desktop for iOS and Android have similar configuration options but different user interfaces.

On the General tab, you can specify the computer to which you want to connect by using RDC and user credentials. You also can save RDC settings in a text file with an .rdp file name extension to initiate a connection later without configuring RDC settings again.

The Display tab is shown in Figure 8-5. On this tab, you can choose the size of the remote desktop window, including the option to run the remote desktop in full-screen mode. You can select to use all local monitors for a remote session, select color depth, and enable a connection bar when the remote desktop is running in full-screen mode.

The Local Resources tab is shown in Figure 8-6. On this tab, you can set remote audio settings, such as whether you want to enable remote audio playback and recording. You also can specify a location where Windows key combinations, such as Alt+Tab, are applied and whether local devices and resources in remote sessions are available. For example, you can enable the option to make the Clipboard, local drive, printers, and devices that you plug in later available in a remote session.

On the Programs tab, you can specify a program that starts automatically in a remote desktop session when you connect to a remote computer. If you configure this option, when you close the program, your session is signed out automatically.

On the Experience tab, you can select a connection speed to optimize performance. You can enable different features, such as the following:

• Desktop background
• Font smoothing or visual styles in RDC
• Show window contents while dragging

By default, RDC automatically detects connection quality and configures connection quality–dependent features accordingly. On this tab, you also can configure persistent bitmap caching and automatic reconnection if a connection drops.

RDC displays the bandwidth with an icon on the connection bar (top of the window) that is similar to a signal strength meter. The meter is based only on bandwidth and does not take latency into account. The number of bars in the icon identify the bandwidth, as show in Table 8-2.

Table 8-2 RDC bandwidth values

Icon	Bandwidth
4 bars	10 megabits per second (Mbps) and higher
3 bars	2000–9999 kilobits per second (Kbps)
2 bars	512 Kbps - 19999 Kbps
1 bar	Less than 512 Kbps
No icon shown	No bandwidth detected or older remote desktop host

On the Advanced tab, you can configure server authentication and Connect From Anywhere settings. The server authentication options allow you to define what should be done if the certificate provided by the server during authentication isn’t valid. By default, a warning is displayed and you have the option to continue. If desired, you can configure this setting to connect without warning or prevent connections.

The Connect From Anywhere settings allow you to configure connectivity through an RD Gateway server. You can configure the alternate credentials for authentication to the RD Gateway server and the location of the RD Gateway server.

RDS licensing

If you want to use RDS, you need to purchase additional RDS CALs for each user or device that uses RDS. This is in addition to the typical licensing that is required for desktop computers. For example, in an environment where users have desktop computers and some applications are delivered by RemoteApp, you would need the following licenses:

• Operating system license for the desktop computer
• Server licenses for the Windows-based servers that deliver the RemoteApp programs
• Windows CALs for each user or computer that accesses the Windows servers
• RDS CALs for each user or desktop that uses RemoteApp programs
• Application licenses for each user or desktop that uses RemoteApp programs

RDS CALs provide users with access to session-based virtual desktops or RemoteApp programs. Licensing for VM-based virtual desktops is slightly more complex because the operating system for the VM also needs to be licensed. If you connect to a VM-based virtual desktop from a device that is covered by a Microsoft Software Assurance agreement, then the license includes rights to use that same operating system in a VM-based virtual desktop. If the device isn’t covered by a Microsoft Software Assurance agreement, then you need to purchase Windows Virtual Desktop Access (Windows VDA) licenses.

• For more information about licensing VM-based virtual desktops, see Chapter 10, “Planning and implementing pooled and personal virtual desktops.”

When a client attempts to connect to an RDS deployment, the server that accepts the connection determines if an RDS CAL is needed. If an RDS CAL is required, then the server requests the RDS CAL on behalf of the client that is attempting the connection. If an appropriate RDS CAL is available, it is issued to the client, and then the client can connect to RDS.

RD Licensing manages the RDS CALs that are required for each device or user to connect to an RD Session Host server. You use RD Licensing to install, issue, and track the availability of RDS CALs on an RD Licensing server. At least one RD Licensing server must be deployed in the environment. The role service can be installed on any server, but for large deployments, the role service should not be installed on an RD Session Host server.

After an RDS installation, there is an initial grace period of 120 days. This grace period begins after the RD Session Host accepts the first client connection. If you have not installed valid licenses by the time the grace period expires, clients will not be able to sign in to the RD Session Host.

A single RDS deployment can be configured with only one licensing mode. If you need a mix of Per User and Per Device RDS CALs, then you need to implement two RDS deployments.

If you need to provide access to RDS for multiple external users who are not employees of your organization, then you should consider using an RDS External Connector License. An RDS External Connector License allows an unlimited number of nonemployees to connect to a specific RD Session Host. If you have multiple RD Session Host servers, you need multiple RDS External Connector Licenses in addition to any required Windows Server External Connector Licenses.