Designing Remote Desktop Services and Application Deployment

Lesson 1: Designing Remote Desktop Services

Planning the deployment of Remote Desktop Services in your enterprise environment means taking into consideration licensing, server resilience, how clients connect, and how applications are deployed to the Remote Desktop Session Host. In this lesson, you learn how each of these factors influences the plans you develop to deploy Remote Desktop Services in your own organization’s enterprise environment.

Planning a Remote Desktop Session Deployment

As an experienced enterprise administrator, you are aware of the role Remote Desktop Services plays on your organizational network. You understand how client computers connect using Remote Desktop Connections, how to install applications on a Remote Desktop Session Host, and the basics of managing and configuring an individual Remote Desktop Session server. In this lesson, you go beyond the maintenance and configuration of this technology and learn how to plan the deployment of Remote Desktop Services so that it best meets the needs of your organization.

The first step in planning a deployment is understanding how the following Remote Desktop Services components fit together:

• Remote Desktop Session Host The Remote Desktop Session Host (RD Session Host) role service, formerly the Terminal Server role service, is the core component of a Remote Desktop Services deployment. This is the server to which clients connect so they can access their applications.

• Remote Desktop Session Host server farm The RD Session Host server farm, formerly called the Terminal Server farm, is a collection of RD Session Host servers used to provide high availability and load balancing to clients on the organizational network. Client connections to RD Session Host server farms are mediated by Remote Desktop Connection Brokers. RD Session Host server farms are more likely to be deployed at large sites than are individual RD Session Host servers.

• Remote Desktop Licensing The Remote Desktop Licensing (RD Licensing) role service, formerly called the Terminal Server Licensing role service, provides Remote Desktop Session client access licenses (CALs) to RD Session Host servers on the network. Unless an RD Licensing role service is deployed, clients are able to connect using Remote Desktop Services for only a limited amount of time (120 days).

• Remote Desktop Gateway The Remote Desktop Gateway (RD Gateway) role service was formerly called the Terminal Server Gateway role service. This role service provides access to authorized remote users from untrusted networks. In enterprise networks, the RD Gateway server provides a bridge between the protected internal network and the internal corporate network where the RD Session Host server farm resides. The RD Gateway role service enforces secure, encrypted connections between remote users and internal resources.

• RemoteApp and Desktop Connection The service formerly called RemoteApp programs in Windows Server 2008 Terminal Services provided the ability to run applications that appear to be running locally. With RemoteApp and Desktop Connection, you now have the ability to group and manage the applications so that they are personalized for the individual remote users and accessible to the remote users from their Start menus.

• Remote Desktop Virtualization Host The Remote Desktop Virtualization Host (RD Virtualization Host) is a new role service included in Windows Server 2008 R2 that integrates with Hyper-V to provide access to a unique virtual machine for every individual user through RemoteApp and Desktop Connection. The RD Virtualization Host role service will not install if you are running or testing Remote Desktop Services on a virtual machine—you must be running on supported physical hardware.

• Microsoft RemoteFX RemoteFX is a new client enrichment feature provided in Windows Server 2008 R2 with Service Pack 1. RemoteFX provides the ability to add a fuller complement of codecs, device support, USB redirection, and additional 3D experience to an enterprise desktop accessing applications through a remote desktop connection.

When planning the deployment of individual RD Session Host servers and RD Session Host server farms, ensure that the software applications installed on the RD Session Host servers that will be used by the remote clients are installed after the RD Session Host role is deployed. Many applications perform a check during installation to determine whether the target of the installation is an RD Session Host. In some cases, different executable files will be installed when the installation target is an RD Session Host using the Remote Desktop Web Access role service for application deployment. Alternatively, some applications will generate a pop-up dialog box informing you that installing the application on a Remote Desktop server is not recommended and that the vendor does not support this deployment configuration.

Applications that are deployed on a RD Session Host server might conflict with one another in unexpected ways. Your Remote Desktop Services deployment plan should include a testing period so that you can verify that each Remote Desktop server’s application configuration does not lead to unforeseen conflicts. If conflicts are detected, you will need to plan to either deploy conflicting applications on separate terminal servers or to deploy applications by using Microsoft Application Virtualization (App-V), which is covered in more detail in Chapter 8, “Designing Virtualization.”

Remote Desktop Licensing

Perhaps the most critical aspect of planning the deployment of Remote Desktop Services in enterprise environments is ensuring that licensing is configured appropriately. The loss of one RD Session Host server in an environment in which there are 100 RD Session Host servers is a potential problem. The loss of a license server in an environment in which there are 100 RD Session Host servers is a potential disaster.

All clients that connect to an RD Session Host server require a Remote Desktop Services CAL. This license is not included with Windows Vista or Windows 7 and is not a part of the standard CALs that you use when licensing a Windows-based server. Remote Desktop Services CALs for the RD Licensing role service are managed by the RD Licensing Manager. When planning a Remote Desktop services deployment, answer the following questions when considering the deployment of a Remote Desktop license server:

• What will be the anticipated deployment size for remote users and devices?

• Will there be a need to provide Remote Desktop Session licensing for Windows Server 2008 Terminal Services? If so, what is the scope of the license server? Will it service clients in the domain or workgroup, or manage the licenses for all clients in the forest?

• How will the license server be activated with Microsoft? How will additional licenses be purchased and installed?

• How many license servers are required to service the needs of your organization?

• What type of licenses will be deployed?

License Server Deployment

An RD Session Host server must be able to contact a Remote Desktop License server to fulfill requests by remote users or devices connecting to the RD Session Host server. Automatic discovery of Remote Desktop License servers is no longer supported for Windows Server 2008 R2 running RD Session Host server. An RD Session Host server is permitted to request RDS CALs from a license server running either Windows Server 2008 R2 or Windows Server 2008.

To determine the need for multiple RD Licensing servers, you should determine the necessity for fault-tolerant connectivity in your environment. It is usually a best practice to install any critical service with servers configured for redundancy. To configure redundancy for the RD Licensing server, you only need to install more than one RD Licensing server and configure each of the RD Session Host servers to use more than one RD Licensing server.

In smaller environments, you can deploy the RD Licensing server on the RD Session Host servers. Larger environments, where there will be substantial overhead with providing Remote Desktop Services CALs for remote users and devices, should consider separating the role services onto separate Windows Server 2008 R2 servers. Figure 7-1 displays the dialog box accessed from the RD Session Host Configuration console.

If Windows Server 2008 Terminal Servers, Windows Server 2003, or Windows 2000 is still in use, it will be necessary to specify a license server’s discovery scope. This is used by previous versions of terminal servers and remote desktop clients to automatically detect the license server. You configure the license server scope during the installation of the Remote Desktop Licensing role service, as shown in Figure 7-2. You can change the scope after it is set. The three possible discovery scopes are This Workgroup, This Domain, and The Forest.

• This Workgroup This scope is not available if the license server is joined to an Active Directory service domain. This discovery scope is most often installed on a computer that hosts the RD Session Host service. RD Session Hosts and clients in the same workgroup can automatically discover this license server.

• This Domain The domain discovery scope enables RD Session Hosts and clients that are members of the same domain to acquire Remote Desktop Services CALs automatically. Plan to use this scope if Remote Desktop Services CALs in your organization are going to be purchased and managed on a per-domain basis.

• The Forest The forest discovery scope enables RD Session Hosts and clients located anywhere in the same Active Directory forest to acquire Remote Desktop Services CALs automatically. You should plan to use this scope when licensing issues are handled at the organizational level rather than at the domain level.

For example, if your organization has a single forest with a separate domain for each state division, but all software purchasing and licensing is handled centrally, you would plan to deploy a license server set to the forest discovery scope. This enables the people responsible for licensing to check a central location to determine your organization’s compliance with its Remote Desktop client licensing responsibilities. It saves them from having to check each state division’s Remote Desktop license server. If, however, your nationwide organization has software and purchasing managed on a regional basis, it makes sense to deploy RD Licensing servers on the same basis. In that case, you would plan to deploy RD Licensing servers by using the domain discovery scope.

License Server Activation

Another important component of a Remote Desktop server deployment plan is choosing a license server activation method. Before a Remote Desktop license server can issue Remote Desktop Services CALs, it must be activated with Microsoft in a procedure similar to Windows product activation. During the activation process, a Microsoft-issued digital certificate validating both server ownership and identity is installed on the Remote Desktop license server. This certificate will be used in transactions with Microsoft for the acquisition and installation of further licenses. As shown in Figure 7-3, a license server can be activated through three methods.

The first method occurs transparently through a wizard, like Windows product activation. This method requires the server to be able to connect to the Internet directly, using an SSL connection, which means that it will not work with certain firewall configurations.

The second method involves navigating to a webpage. This method can be used on a computer other than the license server and is appropriate in environments in which the network infrastructure does not support a direct SSL connection from the internal network to an Internet host.

The third method involves placing a telephone call to a Microsoft clearinghouse operator. This is a toll-free call from most locations. The method you use for activation will also validate Remote Desktop Services CALs that are purchased at a later date, although you can change this method by editing the Remote Desktop license server’s properties. If a license server is not activated, it can issue temporary CALs only, which are valid for 120 days.

When planning disaster recovery contingencies for your Remote Desktop Services deployment, consider that if the certificate acquired during the activation process expires or becomes corrupted, you might need to deactivate the license server. A deactivated license server cannot issue permanent Remote Desktop Services per-device CALs, although it can still issue Remote Desktop Services per-user CALs and temporary Remote Desktop per-device CALs. You can deactivate Remote Desktop license servers by using the automatic method or over the telephone, but you cannot deactivate them by using a web browser on another computer.

Remote Desktop Services Client Access Licenses

When planning the deployment of Remote Desktop Services, you must determine which sort of Remote Desktop Services CAL is most appropriate for your organization. A Windows Server 2008 Remote Desktop license server can issue two types of CALs: the per-device CAL and the per-user CAL. The differences between these licenses are as follows:

• Remote Desktop Services per device CAL The Remote Desktop Services per-device CAL gives a specific computer or device the ability to connect to a terminal server. Remote Desktop Services per-device CALs are automatically reclaimed by the RD Licensing server after a random period ranging from 52 to 89 days. This will not affect clients that regularly use these CALs because any available CAL will simply be reissued the next time the device reconnects. In the event that you run out of available CALs, you can revoke 20 percent of issued Remote Desktop Services per-device CALs for a specific operating system by using the Remote Desktop Licensing Manager console on the license server. For example, 20 percent of issued Windows Vista Remote Desktop Services per-device CALs or 20 percent of issued Microsoft Windows Server 2003 per-device CALs can be revoked at any one time. Revocation is not a substitute for ensuring that your organization has purchased the requisite number of Remote Device Services per-device CALs for your environment.

• Remote Desktop Services per user CAL A Remote Desktop Services per-user CAL gives a specific user account the ability to access any terminal server in an organization from any computer or device. Remote Desktop Services per-user CALs are not enforced by Remote Desktop Services licensing, and it is possible to have more client connections occurring in an organization than actual Remote Desktop Services per-user CALs installed on the license server. Failure to have the appropriate number of per-user CALs is a violation of license terms. You can determine the number of per-user CALs in use by using the Remote Desktop Licensing Manager console on the license server. You can either examine the Reports node or use the console to create a Per-User CAL Usage report.

When planning the deployment of Remote Desktop license servers, remember that Remote Desktop Services CALs can be purchased directly from the server if the Remote Desktop server is capable of making a direct SSL connection to the Internet. Alternatively, it is possible to use a separate computer that is connected to the Internet to purchase Remote Desktop Services CALs by navigating to a website or to call the Microsoft clearinghouse directly.

Backing Up and Restoring a License Server

To back up a Remote Desktop license server, you need to back up the system state data and the folder in which the Remote Desktop licensing database is installed. You can use Review Configuration, shown in Figure 7-4, to determine the location of the Remote Desktop licensing database. To restore the license server, rebuild the server, and reinstall the Remote Desktop Licensing Server role, restore the system state data and then restore the Remote Desktop licensing database. When restored to a different computer, unissued licenses will not be restored, and you will need to contact the Microsoft clearinghouse to get the licenses reissued.

License Server Deployment

When planning the deployment of Windows Server 2008 R2 Remote Desktop Services in an environment with Terminal Services running on earlier versions of a Microsoft-based server operating system, consider that Windows Server 2003 Terminal Services license servers and Microsoft Windows 2000 Server Terminal Services license servers cannot issue licenses to Windows Server 2008 terminal servers or Windows Server 2008 R2 RD Session Host servers. Windows Server 2008 R2 Remote Desktop license servers, however, support the licensing requirements of earlier versions of Terminal Services. If your organization’s Windows Server 2003 terminal servers or Windows Server 2008 terminal servers will coexist with Windows Server 2008 R2 RD Session Host servers for a time, upgrade your organization’s license servers to Windows Server 2008 R2 so that they can support both the new RD Session Host servers and previously installed terminal servers.

License Server High Availability

When planning a high-availability strategy for license servers supporting versions of Terminal Services prior to Windows Server 2008 R2, plan the deployment of two separate Remote Desktop license servers configured with the appropriate scope (domain versus enterprise) and install 50 percent of the Terminal Services CALs on each license server. Because the location of previous versions of license servers is published within AD DS, it is not necessary to use a technology such as Domain Name System (DNS) round robin, Network Load Balancing (NLB), or failover clustering for the deployment of license servers. Current versions of Windows Server 2008 R2 RD Session Host servers will be manually configured for each of the deployed Remote Desktop license servers.

Your deployment plan for license servers should include regular backups so that if a license server does fail, the purchased licenses can be quickly recovered and redeployed. Remember that licenses that have been installed but not issued will be lost when a server is recovered. It is possible to recover these licenses from the Microsoft clearinghouse, but your license deployment plan should ensure that only the required number of licenses is purchased. You should not purchase a significant number of extra licenses for possible future use. It is easier to purchase those licenses when they will actually be used than to worry about recovering unused licenses if the license server fails.

Deploying Applications Using Remote Desktop Web Access

Windows Server 2008 Terminal Services included Terminal Services Web Access (TS Web Access). TS Web Access enables clients to connect to a terminal server through a webpage link rather than by entering the terminal server address in the Remote Desktop Connection client software. This enables you to deploy applications through the publication of URLs, which can be distributed through Group Policy.

Unlike the similar functionality that was available in Windows Server 2003, TS Web Access in Windows Server 2008 does not rely on an ActiveX control to provide the Remote Desktop client connection, but instead uses the Remote Desktop Client (RDC) software that is installed on client computers. This means that to use TS Web Access, client computers need to be running Windows XP SP2, Windows Vista, Windows Server 2003 SP1, or Windows Server 2008.

A drawback to deploying TS Web Access in an enterprise environment is that it must be installed on the terminal server to which it is providing access. It is not possible to connect to a second terminal server by using TS Web Access installed on the first. When considered from the perspective of planning the deployment of applications in an enterprise environment, it means you must distribute a different set of URLs to groups of clients as a method of limiting the number of simultaneous connections to TS Web Access.

In general, you should not plan to use DNS round robin or NLB with TS Web Access. Although these technologies will balance incoming connections, they will cause problems with reconnections, with clients occasionally reconnected to servers that are not hosting a currently active session. An exception to this rule is TS Web Access servers located at branch office locations. If your organization has single TS Web Access servers deployed at each branch office location, using DNS round robin and netmask ordering will ensure that branch office clients will be connected to their local TS Web Access server.

In Windows Server 2008 R2, Remote Desktop Web Access now has the ability to be installed on a separate server from the RD Session Host server role. You are able to configure high availability for the Remote Desktop Web Access service by using either an NLB cluster or DNS round robin.

A user or an administrator is able to configure specific RD Session Host servers hosting applications using RemoteApp. In addition, a user is able to target any computer allowing Remote Desktop access. Thus, a user with only a browser is able to connect to any remote desktop or RemoteApp configured for that user.

With the added advantage of connecting to any available Remote Desktop Services–enabled application or desktop from a browser, an administrator is assured of providing a secure connection to an application from managed and unmanaged desktops. As an enterprise administrator, you are now more focused on securing the connections and less concerned with the securing the user’s desktop.

Planning the Deployment of Applications Using RemoteApp

RemoteApp differs from a normal terminal server session in that instead of connecting to a window that displays a remote computer’s desktop, an application being executed on the terminal server appears as if it’s being executed on the local computer. For example, Figure 7-5 shows WordPad running both locally and as a RemoteApp on the same computer running Windows Vista. The visible difference between these two is that one does not have the Windows Vista borders, and it retains the Windows Server 2008 appearance.

When planning the deployment of applications using RemoteApp, you can use one of three methods:

• Create a Remote Desktop Protocol (RDP) shortcut file and distribute this file to client computers. You can do this by placing the RDP shortcut in a shared folder. This distribution method is inefficient in enterprise environments, although it can work well in smaller, branch office situations.

• Create and distribute a Windows Installer package using Group Policy or a file share.

• Have clients connect to an RD Web Access server and launch the RemoteApp application from a link on the page. The drawbacks of previous versions of TS Web Access as an application deployment platform have been largely reduced with the enhancements added to Remote Desktop Web Access in Windows Server 2008 R2.

Deploying RemoteApp allows application administrators the freedom to deploy applications without worry of conflicting dynamic link libraries associated with applications already installed on users’ computers. In addition, RemoteApp offers users the ability to resize the window of the application as if it is running locally. Notifications, custom print settings, and redirection of various devices, along with the ability to customize access to the RemoteApp programs, provide a rich user experience.

Another RemoteApp enhancement for Windows Server 2008 R2 is the ability to provide per-user authentication and authorization for each application. With per-user authorization for each RemoteApp, an enterprise administrator is now able to granularly control application access from the RemoteApp management console.

A complete solution for offering remote users access to authorized applications within the corporate environment is now more complete:

• Configure an RD Session Host server to host applications through RemoteApp.

• Configure additional RD Session Host servers as a session farm for redundancy and load balancing (discussed later in this chapter).

• Configure on a separate computer for the Remote Desktop Web Access server to publish through links on the page applications available for access on the internal network. This provides browser-based clients to access internally published applications.

• Configure RemoteApp with RemoteApp Manager from an RD Session Host server to publish the applications (multiple publishing options are available, as noted earlier).

• Configure a Remote Desktop Gateway server to allow secure access for the external clients using either RD Web Access or the RD Gateway server directly with a remote desktop connection.

Planning RD Session Host Server Farms

The RD Connection Broker role service simplified the process of adding capacity to an existing RD Session Host deployment in Windows Server 2008 R2. RD Connection Broker enables load balancing of RD Session Host servers in a group referred to as a load balanced RD Session Host server farm.

The RD Connection Broker maintains a database of RD sessions. RD Connection Broker can work with DNS round robin or with NLB to distribute clients to RD Session Host servers. When configured with load balancing, the RD Connection Broker service monitors all RD Session Hosts in the group and allocates new clients to the RD Session Host servers that have the largest amount of free resources. When used with DNS round robin, clients are still distributed; the main benefit is that RD Connection Broker remembers where a client is connected. Thus, a disconnected session is reconnected appropriately rather than a new session being created on a different RD Session Host. The limitation of the load balancing service of RD Connection Broker is that it can be used only with Windows Server 2008 RD Session Hosts. Windows Server 2003 terminal servers cannot participate in an RD Connection Broker server farm.

When planning the deployment of RD Connection Broker load balancing in your organization, you must ensure that clients support RDC 5.2 or later. It is also necessary to ensure that each RD Session Host in a particular farm has the same application configuration. Configure separate RD Session Host server farms when it is necessary to deploy different groups of applications. For example, application A and application B conflict when deployed together on a single RD Session Host server and must be deployed on separate ones. It would be necessary to plan the deployment of two RD Session Host server farms, one for each application, if you need to extend client capacity by adding additional RD Session Host server farms to support each application.

Planning the Migration to Remote Desktop Connection Broker

Remote Desktop Connection Broker in Windows Server 2008 R2 provides the previously discussed load balancing and session reconnection service as TS Session Broker, but now provides a unified management service for the user’s access to RemoteApp and Desktop Connection and virtual desktops (discussed in Chapter 8). Proper planning and configuration of Remote Desktop Connection Broker using Remote Desktop Connection Manager will still provide the same enhanced user experience for the desktop and single sign-on authentication provided by RemoteApp and Desktop Connection.

To ensure proper configuration for the digital signing files used for virtual desktop connections and to provide single sign-on for RemoteApp and Desktop Connections, make certain these few relatively simple configurations are implemented:

• Configure digital signing of .rdp files using the RemoteApp Manager on RD Session Host. If public access to RemoteApp and Desktop Connections will be needed, it will be necessary to use Trusted Root Certification Authorities (CAs) for the certificate. An Enterprise CA was used to issue the signing certificate (in this case, the server authentication certificate) displayed in Figure 7-6.

• Also configure digital signing of .rdp files using the Remote Desktop Connection Manager. To maintain single sign-on for access to RemoteApp and Desktop Connections, use the same digital signing certificate for .rdp files that was configured on the RD Session Host for RemoteApp in the Digital Signature settings. Configure the Digital Certificate setting as shown in Figure 7-7.

  

  Figure 7-6 Configuring the digital signing file for RemoteApp

In planning the use of RD Connection Broker to manage access to RD Session Host farms, ensure all remote clients connecting will be using at least RDC 7.0 or a web browser with RD Web Access configured. The RD Session Host servers must be configured to use a farm in Remote Desktop Connection Broker. All servers configured for the farm must be running Windows Server 2008 or Windows Server 2008 R2. You should configure the use of load balancing using the relative weight value that the RD Connection Broker will use. Each server in the farm will receive connections based on a proportional value by comparing the relative weights of the RD Session Host servers in the farm. Otherwise, DNS round robin, NLB clustering, or a third-party load balancer will be needed to administer proper load distribution within the farm.

Planning the Deployment of Remote Desktop Gateway Servers

Plan the deployment of Remote Desktop Gateway (RD Gateway) servers when you need to enable Remote Desktop Protocol over HTTPS connections to RD Session Host servers located on protected internal networks from remote clients on the Internet or untrusted networks.

RD Desktop Gateway Services for Windows Server R2

Remote Desktop Gateway Services in Windows Server 2008 R2 provides enterprise administrators the following enhancements for remote desktop deployment over the previous Terminal Server Gateway server of Windows Server 2008:

• You are now able to configure idle timeouts to reclaim resources from user sessions that are no longer in use.

• Using the configurable session timeouts, you can provide the enforcement of security policy changes in your environment in a timelier manner.

• Background session authentication and authorization allows a user to reestablish the use of a disconnected session without the need for interaction with a new authentication process.

• Device redirection enforcement provided in RD Session Host servers is now available through RD Gateway Services for clients running Remote Desktop Connection 7.0 or better. The RD Gateway Server will direct connections to RD Session Host servers that enforce device redirection.

• Network Access Protection (NAP) remediation can be enforced through an RD Gateway Server (using an RD connection authorization policy) to manage clients not in compliance with the corporate health policy.

Planning Connection Authorization Policies

RD Gateway servers enforce Remote Desktop connection authorization policies (RD CAPs) that specify which users are allowed to connect through the RD Gateway server to resources located on a protected network. One requirement of an RD CAP is to specify which users of a domain from groups within AD DS are authorized to connect through the RD Gateway. In addition, an optional configuration item is to configure the client computers users are allowed to use for connection through the RD Gateway. RD CAPs also specify whether remote clients use a password or a smart card for authentication to access internal network resources through the RD Gateway. RD CAPs can also be used to ensure remote clients that are trusted are redirected to RD Session Host servers that enforce RD Gateway device redirection. To be granted access to internal resources, a remote user must meet the conditions of at least one RD CAP prior to being denied access from a list of policies in the Network Policy Server.

You can use RD CAPs in conjunction with NAP to ensure that clients pass a system health check before being allowed to connect to terminal servers on a protected network. Automatic remediation is configurable for remote clients not passing a health check. In addition, a remediation server group can be configured to automatically redirect the remote client computer for remediation.

Planning Resource Authorization Policies

RD Gateway also provides configurable Remote Desktop resource authorization policies (RD RAPs) to determine the specific resources on the protected network that an incoming RD Gateway client is able to use. You create an RD RAP and specify a group of computers that you want to allow access to a specified group of users. For example, you could create a group of computers called AccountsComputers that will be accessible to members of the Accountants user group. To be granted access to internal resources, a remote user must meet the conditions of at least one RD RAP configured on the RD Gateway Manager.

For example, for a sample configuration to satisfy the connection requirements for access through an RD Gateway, you might create an RD CAP that specifies that the Accountants group, members of which have authenticated using smart cards and whose computers have passed a health check, are also users of a configured group of an RD RAP that is requesting access to approved RD Session Hosts groups also configured in the RD RAP.

Planning for Secure Communications

Configuring the use of Transport Layer Security (TLS) on the RDP-Tcp property settings of an RD Session Host has been shown to be an easy solution for securing communications within the corporate environment. Also, securing communications for external clients has been briefly discussed with the use of RD Gateway services.

The RD Gateway, formerly TS Gateway Services, was introduced by Microsoft to replace the complex solution often implemented when using RDC in the past. Most RDC solutions involving access through an untrusted network and requiring a secure solution required the initial use of a VPN connection into the internal environment. Then the remote user initiates a remote desktop connection through the VPN. This convoluted solution is too time consuming for performing minimal tasks and would drive users away from accessing corporate resources when only minimal access was needed if time was an issue. Another obstacle for this solution might be that the use of the VPN client configured for access was prohibited by the policy of the location from which the remote user was attempting access.

The RD Gateway service allows a remote user to connect to the RD Gateway host using an SSL connection over TCP port 443, a very common port to configure for access through a firewall. The RD Gateway server then provides the connection to the secure RD Session Host servers in the internal network. The solution appears easy, but the complexity of the back end of the connection, the connection between the RD Gateway server and the internal RD Session Host servers, causes a bit of anxiety for security administrators because the RD Gateway server still needs access to the following services using the following destination ports:

• To provide for authentication of users: TCP port 88 for Kerberos.

• The RPC Endpoint Mapper: TCP port 135. This communication provides the TCP port for communicating with the NTDS RPC service for AD DS.

• Communicating with the NTDS RPC service for AD DS. This TCP port must be configured statically in the registry of the RD Gateway server.

• Information to authorize the user using the Lightweight Directory Access Protocol (LDAP) service: TCP port 389.

• DNS Traffic for name resolution: User Datagram Protocol (UDP) port 53.

• RDP Traffic for communicating with the back-end RD Session Hosts: TCP port 3389.

• RADIUS traffic if a central Network Policy Server server is used for authentication and authorization of the remote connection: UDP ports 1812 and 1813 for RADIUS and RADIUS accounting, respectively.

• Finally—yes, this list is pretty exhausting—if checking for the certificate revocation list is necessary: LDAP or HTTP (80) or FTP (21) might be necessary.

An easier and more secure solution would be to employ a security server or security device to provide a secure reverse proxy of all the above communication from the perimeter network to an RD Gateway service on the internal network. This would alleviate using firewall rules to provide communication for the RD Gateway server in the perimeter network to all of the previously listed servers and services. Microsoft Forefront Threat Management Gateway 2010, formerly ISA Server, provides an elegant solution to this problem by receiving the remote client’s request and providing a secure web gateway through the firewall separating the perimeter network and the internal network. All of these rules can be provided within a predefined rule set preconfigured for use with the RD Gateway server.

Designing for RD Virtualization Host Servers

To provide further integration of all remote user access to applications, desktops and now virtual desktops, Microsoft introduced Remote Desktop Virtualization Host (RD Virtualization Host). RD Virtualization Host utilizes Hyper-V as its platform and RD Connection Broker as the management piece to provide redirection for a user to the user’s virtual desktop. RD Virtualization Host can also provide via RD Connection Broker access to dynamic pools and session reconnection if a user has an existing session with a virtual desktop within a pool. RD Virtualization Host also provides the ability to access applications enabled with RemoteFX in the virtual machines.

In planning the deployment of the RD Virtualization Host role service, the administrator must also plan for the associated deployment of Hyper-V because the Hyper-V role is also installed on the same server. First, the server has to meet the following hardware specifications for the Hyper-V role:

• x64-based processor and Windows Server 2008 R2 SP1 x64-based versions

• Hardware-assisted virtualization from Intel, Intel VT, or AMD, AMD-V

• Hardware-enforced Data Execution Prevention, otherwise known as NX/XD, No eXecute (AMD), eXecute Disable (Intel)

• Hyperthreading is enabled in the BIOS of the RD Virtualization Host

In addition, the hardware specifications must also comply with the requirements for running RemoteFX. The requirements for installing the RemoteFX role service are discussed later in this chapter.

In addition to ensuring these software and hardware specifications required for the individual roles and role services, the enterprise administrator must plan for the scalability of the design when deploying a Virtual Desktop Infrastructure (VDI). Because all application execution and data processing occurs on the server on a virtual machine, the hardware of the server hosting the RD Virtualization Host must be able to satisfy all of the requirements for the proposed number of virtual desktops planned for use on this server. This is discussed more thoroughly in Chapter 8.

Designing for RemoteFX Content

The ability to improve remote user experience to the point that it feels as if the user is experiencing the same multimedia, 3D graphics, Windows Aero, full-fidelity video and all rich media content provided through service features such as Silverlight and DirectX has finally arrived with RemoteFX. RemoteFX is really a set of RDP technologies that provides the platform for technologies enabling the rich content normally experienced by a local user. Microsoft RemoteFX is available for RD Session Host servers running on Windows Server 2008 R2 Service Pack 1.

RemoteFX technology can be embedded into a thin client device to provide an extremely rich environment when used for access to a remote desktop using Remote Desktop virtualization. A user with this type of thin client device will be capable of running truly powerful applications such as AutoCAD 2011 or even games requiring extensive 3D graphics. This has not been previously possible for any environment using a remote desktop or a virtual desktop.

The requirements for deploying RemoteFX include deploying RemoteFX on a Windows Server 2008 R2 Service Pack 1 installation including the Hyper-V and RD Virtualization Host role services. The RemoteFX is also a role service of the Remote Desktop Services role. The computer requirements for providing the RemoteFX role service are as follows:

• A Second-Level Address Translation (SLAT)–enabled processor that provides virtualized environment hardware-assisted memory enhancements to reduce the overhead in memory mapping and memory I/O for the memory space of each individual virtual machine running on the computer.

• A high-performance graphics processing unit (GPU) capable of quickly rendering 3D graphics because all graphic rendering is performed on the server back end for a RemoteFX–enabled application. The graphics adapter requires an amount of dedicated video memory that is directly dependent on the number of monitors used for the virtual machines hosted on the computer. If multiple GPUs per computer will be used to increase scalability, then the GPUs must be identical.

• An optional RemoteFX hardware encoder can be installed to increase scalability. This requires installation in a PCI Express x4 slot, or greater, on the server.

• A Windows Display Driver Model (WDDM) compliant driver is needed.

Deployment considerations for the client to run RemoteFX–enabled applications require one of two solutions:

• Client software that includes a software client for RemoteFX. The Remote Desktop Client update for Windows 7 included in Windows Server 2008 R2 with Service Pack 1 contains a RemoteFX–enabled client.

• A hardware decoder for RemoteFX that can be included in thin client devices as an embedded application-specific integrated circuit (ASIC) to provide a hardware-based RemoteFX decoder.

Practice: Planning Use of the Remote Desktop Gateway

Tailspin Toys is an Australian company headquartered in Sydney. The company uses a single Active Directory forest. Regional branches are located in each Australian state and territory as well as on both of New Zealand’s islands. Each regional branch has its own domain in the Tailspin Toys forest. Responsibility for software purchasing and licensing is handled on a branch-by-branch basis by a designated licensing officer. The licensing officer is responsible for ensuring that his or her regional branch complies with its licensing responsibilities.

Tailspin Toys has an existing Remote Desktop Services infrastructure, which you plan to expand as the need for applications installed on Remote Desktop Session Hosts continues to grow. Although Tailspin Toys has more than 10,000 employees spread across offices in Australia and New Zealand, only a small percentage of employees ever need to access applications hosted on RD Session Hosts and terminal servers running on Windows Server 2008; however, they often do so from multiple computers. These employees primarily use two applications. Extensive testing has revealed that installing application Alpha and application Beta on the same RD Session Host leads to application instability. At present, RD Session Hosts are deployed with either application Alpha or application Beta in each regional office. There are no plans to use Microsoft App-V at Tailspin Toys.

Another application that runs from an RD Session Host, called application Gamma, is used with the company’s financial database. This application is used at the Sydney office only. As a method of protecting the company’s financial database, you are planning to move all servers that support the database, including the RD Session Host that hosts application Gamma, to an organizational unit (OU) named Secure Servers. The Secure Servers OU has a Group Policy object (GPO) applied that enforces TLS 1.0 to secure communications with all RD Session Hosts.

EXERCISE Plan Tailspin Toys Remote Desktop Services Deployment

In this exercise, you review the business and technical requirements to plan a Remote Desktop Services deployment for Tailspin Toys.

1. Twenty members of the accounting team need access to the front-end financial application installed on the RD Session Host. Which steps can you take to allow only these users access from anywhere, using the required TLS security layer for communications, and not configure certificates for each individual remote client?

   • Configure an RD Gateway Server to use a certificate to enforce the use of SSL for all traffic between the remote client and RD Gateway Server.

   • Configure the use of TLS communications for the security layer on the RDP-Tcp properties of the RD Session Host.

   • Configure an RD RAP and RD CAP that allow only the 20 authorized users from the accounting team to use the RD Gateway server to connect to the RD Session Host that publishes the database front-end application through RemoteApp.

2. What plans should you make for the deployment of Remote Desktop license servers on the Tailspin Toys network to mirror the company’s current software purchasing arrangements and to ensure that a license server is still accessible in the event of a hardware failure?

   • Place two RD Licensing servers in each domain in the forest. Set the scope on each license server to Domain because there is a mix of Windows Server 2008 Terminal Servers and Windows Server 2008 R2 RD Session Hosts. License purchasing is done on a regional basis, and each domain represents a region.

   • Instruct the licensing officers to purchase per-user Remote Desktop Services CALs. These are appropriate because only a small number of users actually access Remote Desktop Services but often do so from multiple computers.

   • Instruct the license administrator in each domain to install 50 percent of the licenses on each RD Licensing server.

3. Clients connecting to RD-Alpha and RD-Beta at the Sydney head office site are reporting that performance has degraded significantly. It is likely that the number of users at the head office that need to use application Alpha and application Beta will increase threefold in the next financial year. What changes can you implement to improve capacity on RD-Alpha and RD-Beta to meet this projected growth in demand?

   • Install two RD Session Host farms, one for RD-Alpha and one for RD-Beta. Add RD Session Hosts to each farm as required.

   • Install an RD Connection Broker to establish load balancing and session reconnection.

   • It is necessary to use separate farms because application Alpha and application Beta conflict when installed on the same RD Session Host. Each server in an RD Session Host farm must have an identical application configuration.

Lesson Summary

• Remote Desktop Licensing servers must be activated before you can install Remote Desktop Services CALs. The discovery scope of a license server is still required for Terminal Servers running on Windows 2000 Server, Windows Server 2003, and Windows Server 2008. The discovery scope determines which clients and Terminal Services servers can automatically detect the server. RD Session Host servers running on Windows Server 2008 R2 do not use a discovery scope because RD Session Host servers must be individually configured for a license server.

• RD Connection Broker enables you to manage load balancing in an RD Session Host farm. RD Connection Broker can be paired with DNS round robin or NLB for load balancing and ensures that disconnected clients are always reconnected to the correct session on the appropriate server.

• RD Web Access allows clients to connect to an RD Session Host by using a browser for remote clients not using RDC.

• RD Gateway servers can enable clients from unprotected networks to connect to RD Session Hosts on protected networks.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 1, “Designing Remote Desktop Services.” The questions are also available on the companion CD if you prefer to review them in electronic form.

1. You are planning the deployment of Remote Desktop licensing for your organization’s Australian subsidiary. Your organization has two offices, one located in Brisbane and one located in Adelaide. A data center in Hobart hosts infrastructure servers. Both the Brisbane and Adelaide offices have their own RD Session Host farms. The offices are connected by a high-speed wide area network (WAN) link. Each office has its own AD DS domain, and both are a part of the same forest. The forest root domain is located in the Hobart data center and does not contain standard user or computer accounts. For operational reasons, you want to ensure that Remote Desktop Services CALs purchased and installed at each location are allocated to devices at that location only. All RD Session Hosts are running on Windows Server 2008 R2. Which of the following license server deployment plans should you implement?

   1. Deploy a license server to each location and set the discovery scope of each license server to Domain.

   2. Deploy a license server to each location and set the discovery scope of each license server to Forest.

   3. Deploy a license server to the Hobart data center and set the discovery scope of the license server to Forest.

   4. Deploy a license server at each site and configure each RD Session Host server at each site to use the local RD Licensing server.

2. You are planning the deployment of RD Licensing servers. Which of the following steps do you need to take prior to installing Remote Desktop Services CALs on an RD Licensing server?

   1. Set the forest functional level to Windows Server 2008.

   2. Set the domain functional level of each domain in the forest to Windows Server 2008.

   3. Activate the license server.

   4. Install Internet Information Services (IIS).

3. The organization for which you work is going through a period of growth. Users access business applications from client terminals. You are concerned that the growth in users will outstrip the processing capacity of the RD Session Host. Which of the following solutions enables you to increase the client capacity without requiring client reconfiguration?

   1. Use Windows System Resource Manager (WSRM) to ensure that all users are able to access resources equally.

   2. Install Hyper-V on a computer running Windows Server 2008 Enterprise and add virtualized servers as required.

   3. Add RD Session Hosts as required and reconfigure clients to use specific ones.

   4. Create an RD Session Host farm and RD Session Hosts as required.

4. You need to ensure that clients connecting to your RD Session Hosts have passed a health check. Which of the following deployments should you implement?

   1. Install Microsoft Forefront Client Security on the RD Session Hosts.

   2. Implement an RD Connection Broker.

   3. Mediate access using an RD Gateway server.

   4. Mediate access using Forefront Threat Management Gateway.