TS connection experience improvements based on RDP 6.0 client customer feedback

TS connection experience improvements based on RDP 6.0 client customer feedback

Many users have downloaded the RDP 6.0 TS client through Windows update since it was released. We have received significant feedback on the RDP 6.0 client -- both on what you liked and what you disliked. In this post we want to let you know that we heard you and show you how your continued feedback helped us to improve the TS client connection experience for all of our users.

The improvements discussed in the post will be available to the public as part of the next planned TS client update. I will update this blog with a link to the new beta client download page once it is released. In the meantime, I thought I would provide an update to our TS user community that we heard your feedback, and we have made improvements in the next beta of the RDP client.

The improvements we made in the beta RDP client are discussed and organized by feedback topics. I have grouped your most common feedback into one of these seven buckets. Of course, additional comments/feedback is appreciated.

Feedback #1:  When using Remote Desktop Client 6.0 to connect to a computer running Windows 2003 Windows 2000, some users are forced to enter credentials (user name and password) twice in a row - once at the TS client, and again at TS server.

This blog post provides details on cause for these problems and possible workarounds.  To better address the problems mitigated by these workarounds, we changed the design for the next version as summarized by the following table:

Client OS with RDP 6.1

Target TS Server OS

Prompt for credentials

Windows Vista and Windows Longhorn

Windows Longhorn and Windows Vista

Always at TS client side

Windows XP, Windows 2003, and Windows 2000

Windows Longhorn and Windows Vista

Always at TS Server side

Windows Vista, Windows XP, Windows 2003, and Windows 2000

Windows XP, Windows 2003, and Windows 2000

Always at TS server side

With this design change, users will not be prompted for credentials twice anymore, provided they have installed the latest RDP client.

Feedback #2:  Saved credentials (user name, password) do not work. I don't know how to edit or delete my saved credentials.

This blog post provides details on the cause of these problems and possible workarounds.  In the new beta RDP client, we have bubbled up the "save" and "edit" options to the top-level UI by showing the logon settings on the TS client UI as shown below. If you need to edit or delete the saved credentials, you can do it directly from this UI instead of clicking the "Options" button and then editing them at the TS client expanded UI.  Remember that saved credentials are per target computer name. This means whenever you select a different computer name, it will tell you which user name and credentials it is going to use for the remote connection.

Whenever you or your administrator enable group policy (GP) settings to use the currently logged on Windows credentials to provide a single sign-on experience for a given terminal server, you will see this status as shown below.

When TS client has no saved credentials for the selected target computer, it will show the appropriate status as shown below.

Feedback #3: RDP 6.0 client provides no easy way to save credentials for the target server similar to what we had in RDP 5.0 client.

In the RDP 6.0 client, we removed the option to save credentials (user name and password) in the RDP file. If you need your RDP 6.0 client to remember your logon credentials, when you connect to Windows Longhorn TS server or Windows Vista, select the "Remember my credentials" checkbox in the credential prompt UI shown below.

 

This will store the credentials in Windows credential manager. Next time, when you connect to the same TS server, your saved credentials will be used automatically, and you will not be prompted for credentials. 

 

What about storing credentials for Windows Server 2003 or Windows 2000 Server TS connections?  In the new beta RDP client, we have provided an "Allow me to save credentials" checkbox at the TS client for pre-Longhorn terminal servers. This checkbox will be visible to you only when the TS client doesn't have saved credentials for the target computer. When you select this checkbox, you will be prompted for credentials at the TS client side once, even though your target computer is Windows 2000 or 2003 server, but when you enter the credentials, it will automatically save the credentials for you at the TS client computer. Next time, when you connect to a Windows 2000 or 2003 server, your saved credentials will be used automatically.

 

To see this checkbox, you need to click on the "Options" buttons in the TS client. Here is the expanded TS client UI with the "Allow me to save credentials" checkbox.

Important note:  Whenever your saved credentials (user name and password) have expired for a target TS server running Windows 2003 or Windows 2000, the target TS server will prompt for credentials again using Winlogon UI but the TS client will not be automatically updated with your newly entered credentials. When this happens, you need to manually edit the saved credentials on the TS client. Note that this is the same behavior as when connecting to a Windows 2000 or Windows 2003 Server from a pre-RDP 6.0 client.

Feedback #4:  Credentials entered in TS client get rejected when connecting to Windows Server 2003.

With the design in the new beta RDP client, you will not see this problem anymore because when you connect to Windows Server 2003 or Windows 2000 Server, TS client will not ask for credentials. Refer to Feedback #1 section for more details.

Feedback #5: When connecting to Windows Server 2003 or Windows Server 2000 using RDP 6.0, I am seeing a new credential UI prompt which I don't like.

If you always connect to Windows Server 2003 or Windows Server 2000 using the new beta RDP client, you will not see the new credential prompt anymore, and you will see the typical remote TS server logon screen (Winlogon) as it was in RDP 5.0.

 

 

But if you are connecting to Windows Vista or Windows Longhorn Server using the new beta RDP client from Windows Vista, you will see the new credential prompt at the client side as shown below.

We are showing this new credential UI prompt at the client because we want to do network level authentication for all TS connections to Windows Vista or Windows Longhorn Server. The new CredSSP (Credential Security Service Provider) used in Longhorn TS server provides benefits like RDP data stream protection, RDP port attack surface reduction, and server authentication by default.

Feedback #6:  The pre-populated user name in the credentials dialog does not match the user name that is in the RDP file.

Most users make a TS connection in one of two ways:

  • Style #1 by double-clicking a custom RDP icon published by your admin or a custom RDP file authored by you.
  • Style #2 by launching the "Remote Desktop Connection" icon in the Accessories folder on the Windows Start menu and typing in the remote computer name and user name and then clicking the "Connect" button, or by typing mstsc.exe from a command prompt. Whenever you use this style, TS client uses the default.RDP file.

 

With the RDP 5.0 client, when you use a custom RDP file, it always reads the user name from the file. It is optimized for users following connection style #1. The downside with the RDP 5.0 client is that if your connection style is #2, and you connect to five different TS servers in a day, you will be required to enter the user name again and again because it shows only the most recently used computer name and user name.

 

In RDP 6.0 client, we have optimized it for connection style #2 users but we understand that this approach breaks the "TS Remote Admin" scenario with connection style #1 where two different RDP files with two different user names are used for the same TS server, or where you want to use a custom RDP file with the user name pre-filled for you by your administrator.

 

Here is a proposed new solution to address both these cases. Whenever the TS client uses the default RDP file (this is the case for connection style #2), it will always use the user name hint from the registry. Whenever you use a custom RDP file (this is the case for connection style #1), it will read from the RDP file if it is available, or else it will read the user name hint from the registry. With this proposed solution, we think we'll be able to address both connection styles that customers use and all possible edge scenarios supported by RDP 5.0 clients. Please let us know your feedback.

Feedback #7: How to suppress the ‘Remote Desktop cannot verify the identity of the computer you want to connect to..." security warning message?

This blog post provides details on cause for this problem and possible solution. We are investigating how to make this security warning message valuable while still making it easy for customers to suppress it when it is not needed. We are considering is to provide a checkbox called "Don't ask me again for remote connections to this computer."  If the user selects this checkbox, it will be remembered and will automatically ignore this warning the next time.

 

If the user clicks on this checkbox to suppress the security warning on server authentication failure, and one year later the TS server admin has changed the server certificate or a bad TS server sends an incorrect server certificate, we will show this security warning again until user click again to suppress it. This way, it is suppressed for the same server certificate error messages only. Here is the proposed UI mockup.

 

 

 

 

 

Leave a Comment
  • Please add 2 and 4 and type the answer here:
  • Post
  • Can you point me at this GP setting?

    Here are steps to enable GP for Single-Sign-On experience for Vista to Vista or Vista to Longhorn server.

    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”.

    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.

    Our team is arealdy working on a detailed blog article on how to enable the GP setting for Single-Sign-On expereince.  Please stay tuned...

  • Redowa, could you please provide more details on your error?  

    If it was working with RDP 5.0 client, then it should work with RDP 6.0 client.  To troubleshoot your issue fruther, could  you please

    - provide the full error text that you are seeing including the error codes if avaialble.

    - provide the client OS version.

    - provide details about your Smart Card manufacturer and driver details.

  • Roger,  The problem you have reported is not a known issue.  

    >>"The client could not connect. You are already connected to the console of this computer. A new console session cannot be established."

    This error  happens only when you do loopback connection to a box where more than one remote session is not allowed - like any client OS SKU.  Meaning, you logon the desktop and then attempt a Remote Desktop Connection again to the same box.  

    If you are not doing loopback connection but you still see this problem thne please provide the detailed repro steps.  

  • Hi,

    "The client could not connect. You are already connected to the console of this computer. A new console session cannot be established."

    I raised this issue in the "Remote Desktop Connection (Terminal Services Client 6.0) for Windows XP and Windows Server 2003 (English Only) released" blog on December 1st and 8th. Gerard also seems to have the same issue see 13th December.

    The scenario is I have two servers (lets call them ServerA and ServerB), both domain controllers, running Windows 2003 SP2. I have no problems connecting a Remote Desktop session to either with TSC 5.1 but I get the above message every time I try to connect to ServerA from any windows XP workstation running TSC 6.0. If I revert to TSC 5.1 I can again connect. No other sessions are in progress at the time.

    I have no problem connecting to ServerB with TSC 6.0 and I can connect to ServerA from ServerB using TSC 6.0

    ServerA runs all our FSMO roles as well as most of our other server software.

    Roger

  • I testing TSC 6.0 on XP using Win2003 Server as the TS. My initial problem was the failing smartcard logon and the double logon. After making all of the changes in the FAQ and verifying that my server was not configured to "Always prompt client..." in the GP, I was only able to successfully perform a Smartcard logon only when "enablecredsspsupport:i:0" was added to the Default.rdp. For us internally, this workaround can be applied.

    Unfortunately we have clients who are unable to make file changes without assisstance. For this reason we are considering a deinstallation of TSC 6.0 and disabling the update altogether. Can this be done?

    Robert Collins

  • I been searching around and scratching my hair alot lately about authenciation on TS.  

    Is it possible to implement terminal server which remote client need certicicate to install to able to access?, so far i only found authenciation to TS with SSL.

    if client not has certificate then they not access TS even select "Alwasy connect..."?

    Thanks

  • MSRDP client 6.0 @ Vista Business x64

    Hi all!

    Why is it that the first parameter sent to mstsc.exe from the command line is ignored?

    Some examples:

    mstsc myconnection.rdp --> doesn't work

    mstsc /foo myconnection.rdp --> starts connection

    mstsc /edit myconnection.rdp --> starts connection!

    mstsc /foo /edit myconnection.rdp --> starts edit GUI

    Am I missing something here? Is my Vista corrupted? Is this a known bug (can't be???). And if so, is there a known workaround?

    Cheers,

    Edward

  • Edward:

    If you're running the x86 version of mstsc.exe this is a known bug.

    Can you try it with the x64 version?

    Rob

  • termserv, thanks for your reply.

    I tried both %systemroot%\system32\mstsc.exe and %systemroot%\syswow64\mstsc.exe. In the Task Manager, both processes show up under the Image Name column without the *32 addendum.

    Both mstsc's give the same result.

    Then I searched for mstsc executables in my %SystemRoot%, and found one at %SystemRoot%\winsxs\amd64_microsoft-windows-t..minalservicesclient_31bf3856ad364e35_6.0.6000.16386_none_a7c4271cdc89f060\mstsc.exe, together with mstsc.mof and tscupgrd.exe.

    You will be pleased to hear that the latter mstsc.exe works as expected!

    So, how can I make sure that the mstsc.exe on a customer's PC is the one that will work correctly? Or will there be a bugfix on the way?

    Thank you for your pointer!

  • Edward:

    Can you check the file size of each of these mstsc.exe?

    Also, how are you launching these, exactly?

  • termserv (or rather, Rob):

    %systemroot%\system32\mstsc.exe: 600576 bytes

    %systemroot%\syswow64\mstsc.exe: idem!

    %SystemRoot%\winsxs\amd64_microsoft-windows-t..minalservicesclient_31bf3856ad364e35_6.0.6000.16386_none_a7c4271cdc89f060\mstsc.exe: 643584 bytes

    HTH, cheers!

  • Edward:

    Are you testing this from a 32-bit version of cmd.exe?  In that case, %systemroot%\system32 is really syswow64, so you're looking at the same location in both checks.

    Try using the 64-bit version of cmd.exe.

  • Rob,

    No, it's a completely standard Vista x64 Business edition. I do start->run->cmd.exe, and in the Task Manager the cmd.exe process is 64 bit...

  • I like the improvements but have not found a solution besides disabling credssp to address the issue where the customer is using Remote Administration or connecting to a Longhorn server where they have a custom credential provider tile that they need exposed.  In one case the customer is filtering the default credential provider so that theirs is the only tile showing and therefore the user gets prompted twice.  Is there a way to not disable Network Level Authentication but still leverage the customer Credential Provider such as filling out the username and password fields but allowing the end user to enter the additional data needed for the custom credential provider?

  • Edward:

    I don't have any ideas, then, except that Vista SP1 may solve this problem.

    Rob

Page 2 of 8 (112 items) 12345»