Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Deploying an RD Session Host is relatively simple, but it does require some preparation. Three issues to consider during the planning phase are scalability, licensing and authentication.
Depending on how many users will be establishing sessions with your RD Session Host server, one host server may not be enough to keep pace with user demands. If that is the case, deploy parallel session host servers for load-balancing purposes.
Windows won't load-balance session host servers by itself: An additional server called a Remote Desktop Connection Broker is needed. After deploying the connection broker, create a farm of session host servers and link those servers to the connection broker server. Furthermore, load balancing requires round-robin use of the Domain Name Server. For more help, check out Microsoft's complete set of instructions on load-balancing Remote Desktop Session Host Servers.
Microsoft requires RD Session Host users to buy an additional client-access license known as an "RDS CAL." As with Terminal Services in Windows Server 2008, these licenses must be managed through a license server.
Microsoft offers two different types of RDS CALs: per-device and per-user. A per-device RDS CAL allows a single device to connect to a RD Session Host server, regardless of how many users actually use the device. A per-user RDS CAL allows one user to access the session host server with an unlimited number of devices.
Remember that licensing users or devices to use the Remote Desktop Session Host does not give them permission to access the session host server. After the licenses have been applied and the session host server has been linked to a license server, you have to add the users to the Remote Desktop Users Group to grant authority for them to use the session host server. Alternatively, you can specify which users can use the server through the Remote tab on the server's System Properties sheet, as shown in Figure 1.
Authorising users to access the server is a required step, even if you have chosen a per-device RDS CAL. Check out Microsoft's TechNet for more information about the Remote Desktop Users Group.
You also have to determine the authentication method used by Remote Desktop Session Host Servers. Microsoft recommends that session host servers be configured to perform network-level authentication. The network-level authentication process must be completed prior to establishing an RDS session.
Network-level authentication is preferred mainly because it reduces the risk of a denial-of-service attack. Each session consumes a certain amount of server resources. If users are required to authenticate before establishing a session, then an attacker cannot deplete the server of resources by establishing an excessive number of sessions unless he has access to a user account that has been authorised to use the session host server.
However, you can't always use network-level authentication because there are client-side requirements. Remote Desktop clients must be running Version 6.0 or higher of the Remote Desktop Connection software. In addition, clients must support the Credential Security Support Provider (CredSSP) protocol, which is currently offered only with Windows Vista and Windows 7.
Note that network-level authentication is not enabled by default. You can enable network-level authentication by opening the System Properties sheet and selecting the Remote tab, as shown in Figure A. Finally, choose the "Allow connections only from computers running Remote Desktop with network-level authentication (more secure)" option.
Deploying a Remote Desktop Session Host server isn't too difficult, but administrators need to be aware of planning requirements. You can learn more about the deployment and configuration process at TechNet.
ABOUT THE AUTHOR
|Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities and was once a network administrator for Fort Knox. You can visit his personal website at www.brienposey.com.|
This was first published in March 2010