Remote desktop virtualization host role server 2012
This chapter from Virtualizing Desktops and Apps with Windows Server 2012 R2 Inside Out covers Remote Desktop Services (RDS), including planning infrastructure for session-based desktops, deploying session-based virtual desktops, and understanding high availability for RDS. Show 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 RDSRDS 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:
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:
Comparing RDS and the Remote Desktop featureRemote 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 architectureThere 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:
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.
Figure 8-1 RDS configuration in Server Manager Connecting to virtual desktops and RemoteApp programsWindows 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.
Figure 8-2 Remote Desktop Connection (RDC) 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:
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.
Figure 8-3 RD Web Access The following process, shown in Figure 8-4, is used when clients connect to a session collection by using RD Web Access:
Figure 8-4 Connectivity for session collections RDS functionality that enhances the client experienceRDC uses the RDP protocol to connect to RDS servers. The following are some of the specific features available that enhance the client experience:
RemoteFXRemoteFX 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:
Remote Desktop Connection configuration optionsWhen 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.
Figure 8-5 Remote Desktop Connection, Display tab 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.
Figure 8-6 Remote Desktop Connection, Local Resources tab 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:
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
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 licensingIf 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:
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.
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. |