• planning considerations
• rolling out the servers
• configuring them to work with the other role services of RDS
• publishing applications
• configuring SSO

Planning Your RD Session Host Deployment 

Capacity Planning Whitepaper for RD Session Host

Installing and Configuring the RD Session Host Role Service

Video: How to Install RD Session Host
Locking Down a RD Session Host Farm
Configuring IP Virtualization 
Troubleshooting Remote Control (Session Shadowing)

The goal of a Remote Desktop Session Host (RD Session Host) server is to host Windows-based programs or the full Windows desktop for Remote Desktop Services clients. Users can connect to an RD Session Host server to run programs, to save files, and to use resources on that server. This step-by-step guide walks you through the process of setting up a working Remote Desktop Services infrastructure in a test environment.
Step 1: Setting Up the Infrastructure 
Step 2: Installing and Configuring Remote Desktop Session Host
Step 3: Verifying Remote Desktop Session Host Functionality

Configuring Single Sign-On

When applied to Remote Desktop Services, Single Sign-On means using the credentials of the currently logged on user (also called default credentials) to log on to a remote computer. If you use the same user name and password logging on to your local computer and connecting to a Remote Desktop Session Host, enabling Single Sign-On will allow you to do it seamlessly, without having to type in your password again.

How to enable Single Sign-On?

Single sign-On can be enabled using domain or local group policy.

1. Log on to your local machine as an administrator.
2. Start Group Policy Editor - "gpedit.msc".
3. Navigate to "Computer Configuration\Administrative Templates\System\Credentials Delegation
4. Double-click the "Allow Delegating Default Credentials" policy.
5. Enable the policy and then click on the "Show" button to get to the server list.
6. Add "TERMSRV/<Your server name>" to the server list. You can add one or more server names. Using one wildcard (*) in a name is allowed. For example to enable Single Sign-On to all servers in "MyDomain.com" you can type "TERMSRV/*.MyDomain.com". (Notice the "Concatenate OS defaults with input above" checkbox on the picture above. When this checkbox is selected your servers are added to the list of servers enabled by OS by default. For Single Sign-On this default list is empty, so the checkbox has no effect.)
7. Confirm the changes by clicking on the "OK" button until you return back to the main Group Policy Object Editor dialog.
8. At a command prompt, run "gpupdate" to force the policy to be refreshed immediately on the local machine.
9. Once the policy is enabled you will not be asked for credentials when connecting to the specified servers

What are the limitations when using Single Sign-on?

• Single Sign-On works only when connecting from an XP SP3, Vista or a Windows Server 2008 machine to a Vista or Windows Server 2008 machine. Please see this KB article about enabling CredSSP on XP SP3 which is required for Single Sign-On.
• If the server you are connecting to cannot be authenticated via Kerberos or SSL certificate, Single Sign-On will not work. You can circumvent this restriction by enabling "Allow Default Credentials with NTLM-only Server Authentication" policy, which is less secure. (NTLM-only Server Authentication is less secure compared to using Certificates or Kerberos.)
• If you have saved credentials for the target machine they take precedence over the current credentials.
• Single Sign-On works only when using domain user accounts. Please see section below regarding user experience for non-domain clients.
• If the Terminal Server connection is configured to go through a TS Gateway server then in some cases the settings of the TS Gateway server can override the TS Single Sign-on setting.
• If the terminal server is configured to Always prompt or RDP file setting Always prompt, then Single Sign-on to TS will not work.
• Single Sign-on only works with Passwords. Does not work with Smartcards.

For more detailed information on SSO using the Remote Desktop Client see this blogpost:
http://blogs.msdn.com/b/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx

SSO on a RDS farm

If you are using a RDS farm and need to configure SSO to it be aware that the farmname by default doesn't have a kerberos identity so before you can successfully use it in a  "Allow Delegating Default Credentials" policy you need to create a kerberos identity for the farmname.

Important! The user account in the following procedure must have the Add workstations to domain user right and be a member of local Administrators security group on the Remote Desktop Connection Broker.

Important! Kerberos identity is not supported if the Connection Broker runs as a node in a Failover Cluster.

Important! RDS provider for Windows PowerShell does not enable automatic updates of the farm account’s password. To enable automatic password updates use WMI script as shown in SSO on a RDS farm

If you are using a RDS farm and need to configure SSO to it be aware that the farmname by default doesn't have a kerberos identity so before you can successfully use it in a  "Allow Delegating Default Credentials" policy you need to create a kerberos identity for the farmname.

Important! The user account in the following procedure must have the Add workstations to domain user right and be a member of local Administrators security group on the Remote Desktop Connection Broker.

Important! Kerberos identity is not supported if the Connection Broker runs as a node in a Failover Cluster.

gs.msdn.com/rds/archive/2009/05/27/creating-kerberos-identity-for-rd-session-host-farms-part-ii-using-a-wmi-script.aspx"> Part II of this blog post series.

Follow these steps to create the Kerberos Identity

1. On the RD Connection Broker, launch Windows PowerShell Modules. To launch Windows PowerShell Modules, click Start, point to Administrative Tools, and then click Windows PowerShell Modules.