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 4 and 4 and type the answer here:
  • Post
  • Feedback #6 - sounds like a good work around

    Additional feedback

    a) when the program installs, please have it create a proper add/remove line item so that the item is identified by name not just by KB number (ie. its kb925876, after removing it from 10 or so machines in the past week, the number finally stuck in my head)

    b) if the next version is to be considered beta too, please also identify it as such at windows/microsoft update, as well as in the add/remove applet because users may be instructed not to get beta software but that it is ok to get everything else.  And while 6.1 will be greatly anticipated in our org, we still don't want people installing it until **we** tell them its specifically ok to do so.

  • I'm using RDP from lots of different XP Pro PCs TO my Vista Enterprise PC.

    When I end the RDP session, sometimes it signs me off of my Vista profile.  

    This does not always occur but it is very annoying as all my open files get abruptly ended and unsaved work is sometimes lost.

  • So is there *any* workaround to have saved credentials in each rdp-file again?

  • Hi

    I can't find any solution for connection from WindowsXP SP2 RDP6.0 (on laptop) to Vista Ultimate installed on my home pc (connected directly). Always I have the same error "because of an error in data encryption. this session will end". I don't know what to do. Any suggestion?

  • Hi,

    I have some doubts about TS (not especifically this version 6.0):

    I using TS in sites where we have low bandwidth (128 or 256 Kbps ex). When I´m using ERP, Excel, Word, Outlook, etc, I have no problem in performance, and my aplications works good. But, if a use a powerpoint (PPS), IE (ex.), that needs to show images or pictures, wow....it´s too slow. Looking my sniffer, I saw that TS use a lot of bytes to transfer the screen (mounted frame by frame).

    More information: Compress is enable, I´m using just Bitmaps Cache Storage on Experience Menu.

    The questions is:

    1 - TS works this form?

    2 - If not, Have any configuration to do on Server or Client?

    3 - Do you recommend Citrix in this case?

    More information (visiting a site with pictures, images, etc,  Metaframe used 880 Kb and with TS 3.1 Mb).

    Regards

  • Is there a way to completely disable the pre-connection authentication popup?  For using other GINAs on the server that may support Virtual Channels of other authentication methods within the session(i.e. biometrics), the popup prevents a seamless connection to the 3rd party GINA.

  • Disable initial pre-connection prompt:

    Put the line

    enablecredsspsupport:i:0

    in your rdp.file used to connect.

    Workaround for FQDN/IP/DOMAIN name prepended to username at server-side login:

    Copy/paste this into a textfile, name it rdc.cmd, put it in windows-folder, then create a shortcut having this as commandline:

    cmd /c rdc <your domainname, FQDN, IP or NETBIOS DOMAIN>

    This batch simply strips whatever it otherwise prepends to the username. I admit, it's just a workaround, but at least it works until microsoft releases the next version which probably will have more logic added to detect better what the client is connecting to, and which also fixes the USernameHint-bug (which really is a bug in the 6.0 client). Hope this will help most people having this issue here.

    This batch leaves all other options and features intact, so saving credentials, choosing not to save them, etc. all still works. This batch only strips every time you use it to logon, nothing more. Be advised that in a multi TS environment this batch can lead to other problems, be aware of this!

    The batch:

    @echo off

    if %1x==x goto help

    for /f "usebackq tokens=2 delims=: " %%i in ('echo %1') do set a=%%i

    for /F "usebackq delims=" %%i IN (`reg query "HKCU\Software\Microsoft\Terminal Server Client\UsernameHint" /v %a%`) do set t=%%i

    for %%i in (%t%) do set n=%%i

    set name=%n%

    if %n%==REG_SZ set name=

    if %n%==UsernameHint set name=

    if not %name%x==x for /f "usebackq tokens=2 delims=\" %%i in ('echo %name%') do set name=%%i

    reg add "HKCU\Software\Microsoft\Terminal Server Client\UsernameHint" /v %a% /d "%name%" /f

    start mstsc /f /v:%1

    exit

    :help

    echo RDC FQDN/IP/DOMAIN to connect to

    echo RDC replaces the annoying crediantial dialog of Remote Desktop Connection 6.0

    echo     asking and setting FQDN\Username as default

    echo     It does this by stripping the FQDN/IP/DOMAIN-part,leaving only the username

    pause

  • Where can I download 6.1 After I've installed 6.0 the program crashes when i press the connect button. I've tried to reinstall the program but that dosen't help.

    Can I downgrade if 6.1 don't work?

  • When accessing a host by IP address, the credentials automatically fill-in each time as IPaddress/username - I always have to change it becuase I want to log on to the domain, not the local PC...it's annoying, so i've disabled the credential security service

  • Please let us download the 6.1 beta MSI file so we don't have to live with the douchey 6.0 client!

  • When will a new RDP version be available.  I have not been able to locate this 6.1, is it not released yet?  

    Also, I added enablecredsspsupport:i:0 to the .rdp file, but when you connect it still defaults to the local machine account instead of the domain account.  Is there a way to change this?

  • I am an administrator and need to connect to the same target server with multiple different credentials (for testing or configuration purposes).  It appears to me that the new RDP client saves ONE set of credentials for ONE server, and that I cannot have ONE server with multiple RDP files with multiple default credentials, correct?  I don't need to automatically login, but it would be highly convenient to be able to populate the authentication dialog box with the preferred credentials for that particular use based on which RDP file is used rather than using the stored creds for the server.

    I have worked around it temporarily by creating HOST file entries with different names for the same servers, but that just seems ridiculous, please fix this new "feature", or at least give me the ability to do it the old (right) way.

  • Scott,

    Your problem is going to be addressed by the next version of TS Client.

    TS Client v6.1 will use RDP file to pre-populate user name in credential prompt.

    Please, see “feedback #6” in the above Blog.

  • For the record...  If in reference to feedback #6 you will only allow a pre-population of a username but will force us to type in a password every time then your 'fix' is still broken, you have taken us backwards from 5.1, and you have NOT listened to the customer.  I won't bite on 6.1 until I can double-click on and icon and I get logged into a machine with the credentials from a RDP file without keying in a thing, as I have today with 5.1

    Every time you restrict choice you lose, because people like me won't let you force me to lose and will do something like VNC, which is really one step closer to saying 'what the hell, just go to Linux'.

    In another blog someone argued that needing to know passwords is a vulnerability.  Someone from Microsoft shot back that it is never the case.  I argue the following:

    - If the need to know something is not a risk, why did you so lock up corporate product keys with Vista.  Can't we just trust our tech's with the product keys?  Could it be that TCO is ridiculously high when you publish info to a group and then have to manage information in the wild?  Yes.

    - you could argue that everyone should have their own user name and password, and so the product key argument is not valid.  But let's be serious, in some settings it again forces TCO through the roof to not have 'role' based accounts (scenarios where the is one account for a role and everyone playing that role uses the ONE account.)  Assigning people to groups given 'role-like' abilities, you say?  TCO I say again.  Not every needs to abide by SOX and they are probably more effective.

    I've been in big, dumb, lumbering organizations and I understand your need to add features for these groups, but when you turn off the options (rather than set them in GP) you lose... me.

  • My organization has the same problem with needing to connect to the same server with multiple different credentials.  I have tried creating different rdp files with different credentials for the same server with no success. I see this is supposed to be fixed in v6.1. When will this be released? Is there some sort of hotfix available now? The way users connect to an application we run has basically been crippled.

Page 3 of 8 (112 items) 12345»