TECHPRO.MS

Hello everyone,

we heard a lot of feedback from you about the need for the Remote Desktop Connection client 6.1 to be made available as a standalone install for Windows XP SP2 to ease deployments of Windows 2008 Terminal Services. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

In response to this feedback, we have released the Remote Desktop Connection client (RDC 6.1) for Windows XP SP2 on x86 platforms.

You can download RDC6.1 for Windows XP SP2 from the Microsoft Download Center (KB 952155) for the following languages:

Arabic, Chinese - Simplified, Chinese – Traditional, Danish, Dutch, English, Finnish, French, German, Greek, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese – Portugal, Portuguese – Brazil, Russian, Spanish – Spain, Swedish, Turkish.

We have also released the MUI package for RDC6.1 on Windows XP SP2 from the Microsoft Download Center (KB 952230).

These are some of the supported features of Remote Desktop Client 6.1 for Windows XP SP2:

• Windows Server 2008 & Windows Vista feature support
• TS Web Access support
• TS Easy Print support
• TS Remote Programs support
• TS Gateway support

Please review the complete list of features and details about RDC6.1 for Windows XP SP2 in this Knowledge Base article.

 

 RDC6.1 is now available on the following platforms:

 

Windows Server 2008

Windows Vista SP1

Windows XP SP3

Windows XP SP2 (KB 952155)

What is Application Compatibility for Terminal Services?<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Application Compatibility is the term given to the collection of issues which prevent an application from executing satisfactorily (or in an expected manner) in a given environment - in this case Windows Terminal Services (TS) platform.

TS is deployed for a variety of reasons such as reducing total cost of ownership (TCO), better security & compliance, enabling mobility, etc.

Following are some problems faced by client applications in a TS environment:

1. Client applications are generally written for a single user. Because TS is a multiuser system, this might cause synchronization problems.
2. Some applications are written with the assumption that their binaries are running with administrator privileges. In TS, a normal user is rarely given administrative privileges.
3. Behavior of some APIs is different in a TS server environment than in a client operating system. This might cause programs such as unexpected results from some operating system calls.

 

TS Application Analyzer

TS Application Analyzer is a runtime program analysis tool to enable administrators/users to determine if they can deploy an application on TS with confidence. It provides a summary of an application’s TS-incompatible behavior. The classes of application compatibility issues targeted for detection are:

1. Shared resources – files/registries
2. Access/privilege issues
3. Windows API calls with special cases for TS

The tool does the following:

1. Enables administrators to analyze test runs on a given binary.
2. Determines whether the binary will face any problems when deployed on TS. If so, the tool determines the type of problem and its severity.
3. Summarizes the findings along with a recommendation.
4. The findings can be exported and analyzed at another computer (e.g. for analysis by a test team).
5. The tool can be deployed on a set of user computers or test computers (running the client OS or the TS server OS) seamlessly. The findings can be collected at the administrator’s computer. The administrator can then analyze the findings from all computers and decide whether the application should be deployed on TS or not.

 

More information and downloads for the tool are available at the Connect website for TS Application Compatibility: http://connect.microsoft.com/tsappcompat

 

The guide for using the tool and the End User License Agreement (EULA) are also available at this site.

 

For any queries about the tool or about TS Application Compatibility, email tsappsup@microsoft.com.

With Single Sign-on enabled, the current user’s credentials, also known as “default credentials”, are used to log on to a remote computer. In several scenarios, users may get the following error message when trying to connect to a TS server with <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Vista clients using default credentials:

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />

Possible causes (and their recommended solutions) are identical to the issues presented for saved credentials. Just as it does with saved credentials, Windows Vista Credential Delegation policy does not allow a Vista RDP client to send default credentials to a TS server when the TS server is not authenticated. By default Vista RDP clients use the Kerberos protocol for server authentication. Alternatively, they can use SSL server certificates, but these are not deployed to servers by default.  There are three common scenarios where using the Kerberos protocol to authenticate the server is not possible, but using SSL server certificates is possible. Because SSL server certificates are not deployed by default, using default credentials does not work in these scenarios.

Below is a list of scenarios in which this problem appears, along with recommended solutions. This is identical to the scenarios for saved credentials.

Scenario 1: Connecting from home to a TS server through a TS Gateway server

When you connect from home through a TS Gateway server to a TS server hosted behind a corporate firewall, the TS client has no direct connectivity to a key distribution center hosted on a domain controller behind the corporate firewall. As a result, server authentication using the Kerberos protocol fails.  

Scenario 2: Connecting to a stand-alone computer

When connecting to a stand-alone server, the Kerberos protocol is not used.

Scenario 3: Connecting to a terminal server farm

Kerberos authentication does not work in terminal server farm scenarios because farm names do not have accounts associated with them in Active Directory. Without these accounts, Kerberos-based server authentication is not possible.  

Recommended Solution for Scenarios 1 & 2

For scenarios 1 and 2, to enable server authentication, use SSL certificates that are issued by a trusted Certificate Authority and have the server name in the subject field.  Deploy them to all servers that you want to have server authentication. To set the SSL certificate for a connection:

1. At a command prompt, run tsconfig.msc. Note: tsconfig.msc is only available on servers.
2.  Double-click the RDP-Tcp connection object.
3.  On the General tab, click Select.
4.  Select the certificate you want to assign to the connection, and then click OK.

Recommended Solution for Scenario 3

To enable server authentication in a server farm, use SSL certificates that are issued by a trusted Certificate Authority and that have the farm name in the subject field. Deploy them to all servers in your farm. The SSL certificate will provide server authentication for a TS server and therefore Credential Delegation policy will allow saved credentials to be used for remote desktop connections. 

Alternative workaround for these scenarios (less secure than recommended options):

Another option is to allow delegation of users’ default credentials with NTLM authentication mechanism. This option is not recommended because NTLM-only server authentication does not confirm the server's identity. Sending your credentials to such servers can be dangerous.

1. At a command prompt, run gpedit.msc to open the Group Policy Object Editor.
2. Navigate to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.
3. Select the "Allow Default Credentials With NTLM-only Server Authentication" setting:

 

When enabling this policy, you also need to add "TERMSRV/<Your server name>" to the server list for all servers to which you want to allow NTLM-only server authentication.

 

 

This article discusses some significant improvements achieved in Windows Server® 2008 related to redirecting connections in a TS Farm.

Understanding the terminologies:

Terminal Services Session Broker (TS Session Broker) is a role service in Windows Server® 2008 that allows a user to reconnect to an existing session in a load-balanced terminal server farm. TS Session Broker stores session state information that includes session IDs and their associated user names, and the name of the server where each session resides.

Credential Security Service Provider (CredSSP) is a new security service provider introduced in Windows Vista that enables an application to delegate the user's credentials from the client (by using the client-side SSP) to the target server (via the server-side SSP). Terminal Services client uses this feature to authenticate the user before further negotiation is done with the terminal server to start the session.

Behavior before Windows Server® 2008:

Before Windows Server® 2008, when a terminal server in a farm received a connection request, it created a temporary session to authenticate the user and load user policies. If no local disconnected session was present, it queried the TS Session Broker to see if there was a disconnected session for the user on another machine in the SB farm. If a disconnected session was found, a redirection request was sent to the client to connect to the other server instead. The temporary session was then discarded.

The temporary session creation resulted in significant delay in completing the connection because a full logon occurs in the session. Also, the user experience was unpleasant because the user saw two welcome screens, first for the temporary session and then again for the redirected session. The new technique addresses these drawbacks when a connection is made using the new Terminal Services client with CredSSP.

What changed in Windows Server® 2008:

In Windows Server® 2008, a new load balancing algorithm has been introduced to distribute the load amongst all the servers in the farm. This can increase the number of redirected connections in a Windows Server® 2008 TS farm, hence making it more important to address the drawbacks with redirection.

A new technique was introduced to improve the redirection scenario in Windows Server® 2008. When CredSSP is used, the user credential is available even before temporary session is created. The new technique uses the credentials (user name and domain name) provided by CredSSP and the initial program available at that point, to load the user profile. It then uses the same credential to query for a disconnected session in the SB farm, if the machine is in a farm. If a disconnected session is found on another machine in the farm, it immediately sends a redirect packet to the client and the client subsequently connects to the redirected server. Hence no temporary session is created before the connection is redirected.

Benefits of the changes in Windows Server® 2008:

Security improvements - The use of CredSSP provides enhanced security for terminal servers against rogue clients. With this feature, clients need to authenticate even before the connection sequence is completed and a session is created for the user.

Performance optimization - The new technique removes the expensive process of creating a temporary session if a disconnected session is already available in a farm. This helps improve the redirection performance significantly in terms of time to connect and CPU utilization on the server.

Experiments performed in our lab shows significant performance improvements in terms of CPU utilization.

Fig 1 CPU utilization for a single redirected connection:

 

Figure 1(a) Before Optimization

 

Figure 1(b) After Optimization

Fig 2 CPU utilization for a burst of redirected connections:

 

Figure 2(a) Before Optimization 

 

Figure 2(b) After Optimization

Improved customer experience - In addition to providing performance improvement, the new technique also helps deliver a better user experience for a redirection scenario. This is primarily because the user no longer sees two sessions, one for the first server (temporary session) and one on the redirected server. Instead they see only the final session after redirection occurs.

 

 

The MSIT pilot project of Windows Server 2008 Terminal Services was so successful that Microsoft IT went on to test the scalability and performance into the production environment. The environment acts as a SSL-based remote access solution and MSIT was able to create a scalable remote access solution that is accessible by using HTTPS connections from any location worldwide. Additionally, user experience enhancements in Windows Server 2008 improved the end-user experience when using Terminal Services.

Technical White Paper | IT Pro Webcast