none
BUG: Remote Desktop session is disconnected with protocol error if Remote Control is used on a Windows Server 2008-based computer

    General discussion

  • SYMPTOMS

    When a user remote controls another user's session using Remote Desktop Services Manager or Terminal Services Manager on a Windows Server 2008-based computer, and then stops remote controlling, one or both sessions are disconnected with the following error:

    Remote Desktop Disconnected

    Because of a protocol error, this session will be disconnected. Please try connecting to the remote computer again.

    CAUSE

    This problem occurs if Remote Desktop Connection Client version 6.0.6001 or 6.0.6002 is used with the highest RDP Compression setting.  Windows Server 2008 SP1/SP2 defaults to a lower RDP Compression setting, and thus will only exhibit the above symptoms if the setting has been changed to "Optimized to use less network bandwidth", which is the maximum.  Windows Server 2008 R2 defaults to the maximum RDP Compression setting.

    WORKAROUND

    Change the RDP Compression setting on the server to "Balances memory and network bandwidth" (recommended) or "Optimized to use less memory" using Group Policy.  If using Windows Server 2008 R2 you may also choose "Do not use an RDP compression algorithm".  An alternative workaround is to use a different Remote Desktop Connection Client version than those mentioned above, however, this may not be practical.  Below are instructions for making the change to the local group policy; if preferred you can use a domain group policy instead.

    Windows Server 2008 R2

    1. Logon to the Remote Desktop Services Session Host computer as an administrator
    2. Start--Run gpedit.msc
    3. In the left pane, under Computer Configuration, navigate to following:

    Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment

    4. In the right pane, double-click on Set compression algorithm for RDP data
    5. Select Enabled, and choose Balances memory and network bandwidth
    6. Click OK to save the change

    Windows Server 2008 (SP1 or SP2)

    1. Logon to the Terminal Services computer as an administrator
    2. Start--Run gpedit.msc, click Continue if prompted by UAC
    3. In the left pane, under Computer Configuration, navigate to following:

    Administrative Templates\Windows Components\Terminal Services\Terminal Server\Remote Session Environment

    4. In the right pane, double-click on Set compression algorithm for RDP data
    5. Select Enabled, and choose Balances memory and network bandwidth
    6. Click OK to save the change

    STEPS TO REPRODUCE

    Windows Server 2008 R2 x64

    1. Install 2008 R2 Standard (Full Installation) x64 from DVD using defaults
    2. Upon first logon, scroll down the initial configuration tasks window and click on Enable Remote Desktop
    3. Choose Allow connections from computers running any version of Remote Desktop (less secure), click OK
    4. Open up Computer Management and create a test user, make them a member of the Remote Desktop Users group, on the Remote Control tab, uncheck "Require user's permission"
    5. Connect from a PC using Remote Desktop Client version 6.0.6001 or 6.0.6002 to the server, logon as administrator
    6. Connect from a PC using Remote Desktop Client version 6.0.6001 or 6.0.6002 to the server, logon as the test user
    7. In the administrator's session, open up Remote Desktop Services Manager, right-click on the test user and choose Remote Control, click OK
    8. After you are viewing the test user's desktop, press Ctrl-Tab to end the Remote Control

    Windows Server 2008 x64

    1. Install 2008 Standard (Full Installation) x64 from DVD using defaults
    2. Upon first logon, scroll down the initial configuration tasks window and click on Enable Remote Desktop
    3. Choose Allow connections from computers running any version of Remote Desktop (less secure), click OK
    4. Open up Computer Management and create a test user, make them a member of the Remote Desktop Users group, on the Remote Control tab, uncheck "Require user's permission"
    5. Change RDP Compression algorithm to "Optimized to use less network bandwidth" using instructions above
    6. Connect from a PC using Remote Desktop Client version 6.0.6001 or 6.0.6002 to the server, logon as administrator
    7. Connect from a PC using Remote Desktop Client version 6.0.6001 or 6.0.6002 to the server, logon as the test user
    8. In the administrator's session, open up Terminal Services Manager, right-click on the test user and choose Remote Control, click OK
    9. After you are viewing the test user's desktop, press Ctrl-Tab to end the Remote Control

    NOTE: This problem may occur when connecting to a Windows Vista or Windows 7 host under similar conditions.  I have not tested this theory, however.

    As always I welcome your comments/questions/corrections/suggestions/etc.

    Thank you for reading.

    -TP

    Wednesday, August 26, 2009 9:11 PM
    Moderator

All replies

  • I am seeing this issue when RDP'ng from my Win7 desktop to a Windows 2003 TS. I can get into the TS just fine as administrator; however when I go to remote control a users session, I get kicked out of the TS with the protocol error.

    version of mstsc on Win2003 server: 6.0.6000.16459

    Version of mstsc on Win7 Desktop: 6.1.7600.16385
    Thursday, September 10, 2009 3:16 PM
  • I am seeing this issue when RDP'ng from my Win7 desktop to a Windows 2003 TS. I can get into the TS just fine as administrator; however when I go to remote control a users session, I get kicked out of the TS with the protocol error.

    version of mstsc on Win2003 server: 6.0.6000.16459

    Version of mstsc on Win7 Desktop: 6.1.7600.16385
    Same here. 

    I'm using Win7 RSAT tools to remote control my 2003 Terminal server. Then using the terminal services manager to remote control a thin client - and I get the boot with the protocol error. Very very very very frustrating. I can't help my users.
    Thursday, September 17, 2009 2:06 PM
  • All,

    I did some quick testing before when Defrag4 posted, and was unable to reproduce the issue.  Questions:

    1. If you disable compression in the .rdp file, does the problem still occur?  To disable compression, open the .rdp file in notepad and modify the compression:i:1 to the following:

    compression:i:0

    2. You can run the 5.2.3790 version of the RD Client under Windows 7 as a potential workaround.  I have it installed under XP in a separate folder, which I then copied to Windows 7.  In this folder I only have two files:

    mstsc.exe
    mstscax.dll

    If you do not want to have launch the 5.2.3790 exe each time you need to modify your .rdp file association, or you can add an additional option so that you when you right-click an .rdp file you can choose which version to use.  This is not a long term solution, but it helps if you need it.

    Thanks.

    -TP

    Thursday, September 17, 2009 2:34 PM
    Moderator
  • im having the same issue, it only happens when i remote control thin clients ( Axel Terminals), i can remote control sessions hosted on windows xp pc's without error.
    Wednesday, September 23, 2009 9:55 AM
  • im having the same issue, it only happens when i remote control thin clients ( Axel Terminals), i can remote control sessions hosted on windows xp pc's without error.
    Same problem with my Win 7 Entreprise

    it's impossible to remotely help my users on 2003 TS, it will crash with the "protocol error".

    Connecting as admin is no problem though.
    Sunday, October 18, 2009 11:43 PM
  • 1. If you disable compression in the .rdp file, does the problem still occur?  To disable compression, open the .rdp file in notepad and modify the compression:i:1 to the following:

    compression:i:0


    Hi TP,

    I tried what you suggested but it did not work for me. I'm trying to connect to connect to a Remote Desktop Session using Terminal Services Manager. The screen pops up and I get a "Because of a protocol error, this session will be disconnected. Please try connecting to the remote computer again." (This is the same error I've been getting since making the switch to 7). I tried this with using the RD Gateway server set to Automatic and set to Do not use. Neither seems to work.
    Tuesday, October 20, 2009 8:51 PM
  • Just tried to disable compression on my win7 RDP shortcut; No change, still got kicked out after Remote Controlling a 2003 TS User for about 5 secs

    When I downgraded my mstsc client to an older version it works again, I think windows update might have replaced it because it started happening again, and i checked the version, sure enough it was the new RDP again.
    Wednesday, October 21, 2009 3:09 PM
  • Errrr. I'm also having the same issues as everyone else when RDP into 2003 TS Server from Windows 7 and using remote control via Terminal Server Manager. Extremely frustrating to say the least. Give us a fix M$! :D
    Gold is for the mistress -- silver for the maid -- Copper for the craftsman cunning at his trade. "Good!" said the Baron, sitting in his hall, "But Iron -- Cold Iron -- is master of them all."
    Wednesday, October 21, 2009 5:01 PM
  • Right now the only workaround is to downgrade your mstsc.exe client; steal one from vista or XP
    Wednesday, October 21, 2009 5:32 PM
  • So only work around is to downgrade mstsc.exe on the Win08R2 server?

    Friday, October 23, 2009 7:30 PM
  • BWC-Dave:  No.  You would use the older mstsc.exe on the client PC.

    -TP

    Friday, October 23, 2009 9:08 PM
    Moderator
  • I've got this working finally!!!  For anyone who's interested, this is what I did.

    Find a windows XP machine.  Copy onto a USB pen drive (or something like that:

    mstsc.exe
    mstscax.dll

    then create a subfolder called en-US and copy into it
    mstsc.exe.mui
    mstscax.dll.mui

    Now copy these files onto your windows 7 machine.  It doesn't matter where, so long as the en-US folder you've created follows it.
    go into the properties of mstsc.exe and set the compatability options to windows xpsp3 and run as administrator

    Now double click on mstsc.  I've just tried remote controlling a user and it worked.

    I'm now off to change my file associations to point at this older version of mstsc.exe
    Monday, November 2, 2009 7:55 AM
  • wonder when microsoft will realized the one in 7 is bugged and need to be patch instead of doing a work around with XP !
    Monday, November 2, 2009 10:24 AM
  • Still no update; Its also a pain in the butt to get the older mstsc client if you dont have a vista/xp machine laying around, Can someone upload the mstsc.exe and dll needed to get this working?
    Tuesday, December 8, 2009 9:21 PM
  • First thing I noticed with the new client.  No one tested it?

    Workarounds:

    1) use older client
    2) RDP to an intermediary server and then RDP from there to your normal server.  Remote control then works [for me].

    For instance, if I RDP to TERM1 and remote control a session, I get the protocol error and disconnect.  If I RDP to TERMTEST and then RDP from there to TERM1, then I can remote control just fine.  A pain, but workable.  The bigger problem is that I have support staff that I now have to explain how to use the old client.....





    Wednesday, December 9, 2009 3:10 PM
  • indeed...the workaroud works but its a pain the .... to used

    don't understand, this should be an easy fix for the guys works on this.
    Wednesday, December 9, 2009 5:23 PM
  • Client machine - Windows XP Pro
    Terminal Server - Windows 2003

    Symptoms - exactly as described.  This isn't a Windows 7 issue, or a Windows 2008 issue.  It is a BUG in the RDP client.  When can we expect Microsoft to deliver a repaired RDP (MSTSC) program? 

    The sympotom appeared after a Microsoft Update - I guess that teaches me for accepting an update from a notoriously unreliable software company.  I use Remote control nearly every day - someone on the terminal server needs something done.
    Note - all of my Terminal Server users are running RDP sessions from Wyse V90 thin clients running Wyse WNOS software.

    The "Work-around" in the article can not be applied - because the Registry Keys do not exist in Server 2003. 
    Adjusting settings on the client does not work - I ve changed them multiple times and get consistent errors - nothing that works.

    Since my employees using Terminal Server are Geographically dispersed by hundreds of miles from here, I can't exactly stop by their desk to fix issues.  This is a CRITICAL INCIDENT BUG that needs a HIGH PRIORITY patch.

    Friday, December 18, 2009 4:03 PM
  • Hi, Doc_M,

    Wyse recently posted a KB to address a problem with connecting WTOS devices to a terminal server. Can you take a look and see if this issue relates to you?

    Go to www.wyse.com/manuals and search for KB 18695

    Regards,
    Christa


    Christa Anderson [MSFT] Want the Windows Server 2008 Terminal Services Resource Kit? Click here.
    Friday, December 18, 2009 10:44 PM
    Owner
  • Hello, I'm Brazilian and I can not speak English well, excuse the errors.

    I'm having the same problem when connecting to a TS server from a Windows 7 Ultimate can not do remote control in the User session, already ran all the alternatives overdimensioned this forum and not had success. Not content with that I called Microsoft support and they ended up talking trash saying that the problem could be in windows 2008 server and they do not support unless you have a support contract or want to pay for the hours of an engineer to resolve the issue.

    This unfortunate situation!
    Wednesday, December 30, 2009 9:59 AM
  • Hi, Doc_M,

    Wyse recently posted a KB to address a problem with connecting WTOS devices to a terminal server. Can you take a look and see if this issue relates to you?

    Go to www.wyse.com/manuals and search for KB 18695

    Regards,
    Christa


    Christa Anderson [MSFT] Want the Windows Server 2008 Terminal Services Resource Kit? Click here.

    I did tested with some of my Wyse device it works fine

    As for Windows to Windows RDPing ... i still can't do sh*t !!!!


    Thursday, December 31, 2009 12:06 AM
  • I have the same issue when using vista business to sbs2003 and remote controlling ts users sessions.

    ITs not operating system based issue, its an rdp update.  in my case the update that caused the issue is KB969084.  When uninstalled all my issues go away.

    Just a pain that i have had to block what is potentiallly a useful update and that microsoft have yet to roll out a fix for this issue.

    If anyone has a better way of resolving this other than uninstalling and blocking the update please let us know!

    p.s for what its worth, i only get the issue controlling thin clients (axel terminals) too, PC base TS users dont cause me an issue..

    Wednesday, January 6, 2010 10:57 AM
  • I as well have the same issue as everyone above.  Cannot remote shadow any of my terminal server users on Terminal Server 2003.  This is a huge priority one issue.  I cannot help any of my users.  I also noticed I pushed out the new RDP 7 client to a few XP machines for testing and I cannot remote shadow from those machines either.  So if you are using Microsoft XP do not update your RDP client otherwise you will no longer be able to remote shadow any of your terminal server users that connect via thin client.  A huge problem microsoft has to release some patch for this to take care of this major issue.
    Thursday, January 7, 2010 8:50 PM
  • I as well have the same issue as everyone above.  Cannot remote shadow any of my terminal server users on Terminal Server 2003.  This is a huge priority one issue.  I cannot help any of my users.  I also noticed I pushed out the new RDP 7 client to a few XP machines for testing and I cannot remote shadow from those machines either.  So if you are using Microsoft XP do not update your RDP client otherwise you will no longer be able to remote shadow any of your terminal server users that connect via thin client.  A huge problem microsoft has to release some patch for this to take care of this major issue.
    This info is not 100% correct; I solve the problem you are reporting in XP SP3 clients by updating to Remote Desktop Connection 7.0 client:

    Description of the Remote Desktop Connection 7.0 client update for Remote Desktop Services (RDS) for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;969084#appliesto

    There is also an update for Vista/2008 clients:

    A terminal server session that is shadowed is incorrectly disconnected when the terminal server session that is shadowing stops shadowing on a computer that is running Windows Vista or Windows Server 2008
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;976110

    I'll give some feedback about Win 7 asap

    cheers,
    Monday, February 1, 2010 2:59 PM
  • amlopes that is not the problem I am reporting.  The issue is after you do update your XP clients to the new RDP 7 protocol you can no longer remote shadow a WIN2003 terminal server connection created by a thin client.  For example if I was an admin connecting to a terminal server via an XP machine with RDP 7 installed and I had to remote shadow one of my users on a thin client it will disconnect my session with an RDP protocol error.   So upgrading XP clients to RDP7 puts them in the same boat as using Windows 7.

    Tuesday, February 23, 2010 8:18 PM
  • Does anyone knows if microsoft already fixed this problem ? It's getting a little bit irritating.
    Thursday, March 18, 2010 4:20 PM
  • I am seeing this issue when RDP'ng from my Win7 desktop to a Windows 2003 TS. I can get into the TS just fine as administrator; however when I go to remote control a users session, I get kicked out of the TS with the protocol error.

    version of mstsc on Win2003 server: 6.0.6000.16459

    Version of mstsc on Win7 Desktop: 6.1.7600.16385

         I am experiencing this exact same problem when remoting in from my Windows 7 Professional Retail 64 bit workstation to a Windows 32 bit 2003 Terminal server.  The only way i can get this to work is to remote into one terminal server and from there remote in to the other one. Than it will work.  This is really a pain when you have to do this all the time.  Any fix for this from microsoft yet.

    -Ian

    Friday, April 9, 2010 8:39 PM
  • I have not heard of any fixes yet other than changing your RDP client to the old version or connecting through a terminal server and then through another.  I would like to know if microsoft is aware and looking into fixing this issue.  What a huge pain!!!
    Wednesday, April 14, 2010 3:30 PM
  • I am getting the same thing under the following scenario:

    1.  2008R2 server with RDS role on

    2.  Connecting from WinXP client

    3.  Join the WinXP session by domain Admin (defualt release of -cntl + [tab] accepted)

    4.  Joined session works fine, when release initiated, both session get the protocol error and both sessions are terminated.

    Tried applying the GP of "balances memory and network bandwidth" and can't join a session at all.

    Anyone know of any MS movement on this problem?

    Sunday, May 2, 2010 4:28 PM
  • What about this issue? Any fixes published? TS hopping for remote shadowing is not a real pleasure. :-D
    Thursday, May 6, 2010 12:36 PM
  • All,

    Hm.. have been through everything here, but don't find anything that matches my situation which is:

    Connecting to a Win 2008 standard server (virtual 32 bit) the remote user client gets disconnected when as administrator taking remote control "Your desktop connection is by the administrator....".

    However this only happens when I connect from one of two Win7 ultimate. machines, and both of them are using the same mstsc. and mstscax. (ver. 6.1.7600.16385).

    Thanks,

     ASA-HP

     

    Thursday, May 13, 2010 11:08 AM
  • Not sure if it applies here, but we were getting this error on Remote Desktop for Administration connections to a specific server (using Windows 7 to 2003). Workaround was go to the properties Remote Desktop Connection > Experience > Allow the following and deselect all. Able to connect without error.
    Thursday, May 13, 2010 6:13 PM
  • same here : disable every experience checkboxes and it works fine.  (on servers TSE 2K3, 2K8 & 2K8R2)

    but an update from microsoft for MSTSC is required anyway, it's not a normal behavior to disable all the experience

    Tuesday, May 18, 2010 1:35 PM
  • Still nothing from MS on this? I recently downgraded my files but now I have a new laptop with Win 7 64 bit and I cannot get it to work with the new files.
    Tuesday, June 15, 2010 12:43 PM
  • I cannot beleive we let microsoft get away with this - there are two admins in our company both of which are using windows7 product and neither of us can administrate our own damn servers

    I have tried unticking all of the options in experiance with no avail this just moves the problem to mouse clicking.

    Have also tried to downgrade my RDP exe with no avail as win7 will not let me change the system32 folder

     

    HAS ANYONE MANAGED TO FIX THIS ISSUE YET?

     

    Thanks

    Friday, July 16, 2010 3:26 PM
  • Our workaround on win7 desktops is to use mstsc.exe version 6.0.6001.18000. In detail:

    - a folder containing mstsc.exe (v.6.0.6001.18000) and mstscax.dll (v.6.0.6001.18266)

    - a subfolder "de-DE" (or "en-US"... etc.) containing mstsc.exe.mui and mstscax.dll.mui

    Running mstsc.exe out of that folder prevents disconnecting the session while shadowing another one on a terminal server.

    Regards

    Andi

    Monday, July 19, 2010 6:50 AM
  • Our workaround on win7 desktops is to use mstsc.exe version 6.0.6001.18000. In detail:

    - a folder containing mstsc.exe (v.6.0.6001.18000) and mstscax.dll (v.6.0.6001.18266)

    - a subfolder "de-DE" (or "en-US"... etc.) containing mstsc.exe.mui and mstscax.dll.mui

    Running mstsc.exe out of that folder prevents disconnecting the session while shadowing another one on a terminal server.

    Regards

    Andi

    I tried the above, and it still does not work.

    On Windows 7 Premium 64, connecting to Server 2003 R2, try to shadow users on Wyse V10L.  Get disconnected immediately.

    Shadowing users on XP machines works fine, but as soon as I try to shadow someone on a Wyse, it disconnects me with the error message.

    Microsoft really needs to fix this ASAP.  It is seriously affecting my ability to support users.

     

    Tuesday, August 10, 2010 10:24 PM
  • Our workaround on win7 desktops is to use mstsc.exe version 6.0.6001.18000. In detail:

    - a folder containing mstsc.exe (v.6.0.6001.18000) and mstscax.dll (v.6.0.6001.18266)

    - a subfolder "de-DE" (or "en-US"... etc.) containing mstsc.exe.mui and mstscax.dll.mui

    Running mstsc.exe out of that folder prevents disconnecting the session while shadowing another one on a terminal server.

    Regards

    Andi

    I tried the above, and it still does not work.

    On Windows 7 Premium 64, connecting to Server 2003 R2, try to shadow users on Wyse V10L.  Get disconnected immediately.

    Shadowing users on XP machines works fine, but as soon as I try to shadow someone on a Wyse, it disconnects me with the error message.

    Microsoft really needs to fix this ASAP.  It is seriously affecting my ability to support users.

     


    It's a pity. It still works for me. Win7 Enterprise 32bit --> Server 2003 SP2 32bit --> Wyse S10

    And I think the origin of the mstsc 6.0.6001 files was an 32bit XP pro.

    Wednesday, August 11, 2010 7:47 AM
  • Hi,

    Wyse has a KB document that says to upgrade thin client OS firmware to at least 6.5.0_30 in order to fix this problem.

    http://www.wyse.com/manuals

    Search for 19555

    Please see if updated firmware solves the issue for you.

    Thanks.

    -TP

    Wednesday, August 11, 2010 8:14 AM
    Moderator
  • I updated my Wyse V10L to the lastest OS stated above

     

    I used the Wyse to connect to a 2003 R2 Terminal server

     

    from my Windows 7 x86 machine i try to remote control to my test user which is connected to the TS

     

    Got disconnect with protocol error...therefore problem is not fixed

    Wednesday, August 11, 2010 3:05 PM
  • For the issue "In a Win7 client machine, remote control to a thin client TS session will be disconnected", a hotfix (KB2273487) is available. Please contact Microsoft Product support services to get the hotfix package.
    Thursday, August 26, 2010 6:48 PM
  • Hi,

    What is the KB number you are referring to?  We would need to reference that when contacting Product support.

    Thanks.

    -TP

    Thursday, August 26, 2010 6:51 PM
    Moderator
  • Hi,

    What is the KB number you are referring to?  We would need to reference that when contacting Product support.

    Thanks.

    -TP


    exactly, because if you search, it doesnt exist !
    Thursday, August 26, 2010 7:31 PM
  • Anybody already obtained and installed this hotfix?

    Regards

    Andi

    Friday, September 17, 2010 6:35 AM
  • After struggling with this issue, I have a clue as to what the problem is, which might lead all of you to resolution in this matter.

    During our latest storm of protocol errors,  I had two reusable sessions logged in on my Windows 2008 server. One was working, and one would consistently deliver a protocol error when minimizing/maximizing windows, especially those with large tracts of uniform color, e.g. white space.

    After implementing the 'compression:i:0' fix in an RDP file on my Windows 7 (v.7600) client, the behavior was reversed: the session that was working, stopped working, and the session that was broken, started working.

    This suggests the following:

    In hour heterogeneous environment, desktop sessions may be opened and reopened via RDP by any number of administrators running different RDP clients, with different settings. It appears to me that each open session is tuned to the initiating client. Attempting to reopen an existing  session with a different client MAY cause this problem. This is not 100% consistent, which leads me to believe that TS does attempt to tune the session to the client, but does not correctly do this for (perhaps) the compression settings.

    This suggests why users who copy the XP RDP client onto their Windows 7 machines stop seeing the protocol error - because they have made the RDP clients uniform, and therefore all their logged-in sessions are 'compatible' when reopened by another user.

    Most of our sessions are initiated by Windows 7 (v7600) clients, and protocol errors are few. I have been able to end our protocol error storms by logging off all sessions, and pre-opening and then disconnecting a number of sessions using the Windows 7 (v7600) client. These are then available for re-use by down-level RDP clients.

     

    Tuesday, September 21, 2010 8:15 AM
  • I have downloaded the patch on Windows 7 x64 and it works.  I have not received an RDP error connecting to any of my TS sessions created by Wyse thin clients.  Boy this was one long wait, now I do not have to rdp into one server then RDP into another just to shadow my clients anymore.

    Thursday, October 21, 2010 7:30 PM
  • I've got this working finally!!!  For anyone who's interested, this is what I did.

    Find a windows XP machine.  Copy onto a USB pen drive (or something like that:

    mstsc.exe
    mstscax.dll

    then create a subfolder called en-US and copy into it
    mstsc.exe.mui
    mstscax.dll.mui

    Now copy these files onto your windows 7 machine.  It doesn't matter where, so long as the en-US folder you've created follows it.
    go into the properties of mstsc.exe and set the compatability options to windows xpsp3 and run as administrator

    Now double click on mstsc.  I've just tried remote controlling a user and it worked.

    I'm now off to change my file associations to point at this older version of mstsc.exe
    This solution works perfect on any Win 7 machine (Professional or Ultimate 32 bit or 64 bit) using to remote into Terminal Server and attempting to remote control a user from there. I can't believe Microsoft has not come out with a fix. It seems as though this problem has been an issue for so long and it has not been addressed.
    Glen
    Saturday, January 8, 2011 7:14 PM
  • The Hotfix is not needed anymore

    Windows 2008 R2 Servicepack 1 is released and it looks like this fixes the problem.
    We had the same problem using Wyse Clients for the user and Windows 7 Clients for the Admins connecting to Windows 2008 R2 RDS Server
    after installing the SP1 on the 2008 R2 the problem was fixed

    We did not install the SP1 on the Clients until now

    Update: on Admin-Clients without Windows 7 SP1 you still need the Hotfix (sometimes) :)

    Tuesday, February 22, 2011 1:13 PM
  • Try this: Open RDP, click on the Experience tab. Deselect the Desktop composition box. Works for me!!!!
    Wednesday, February 23, 2011 6:54 PM
  • We have WS2008R2 with SP1, clients (Windows 7 RTM) still experience this problem.
    MCITP: EA, EMA, VA; MCSA
    Friday, February 25, 2011 7:26 AM
  • as i wrote you need the SP1 on client and Server installed
    else you have to install the hotfix http://support.microsoft.com/kb/2273487

    we use thinclients from wyse with WyseOS 7 (Linux) and Windows 7 RTM Admin-Clients
    after installing the SP1 on the server AND the admin-clients the problem was gone

    Tuesday, March 1, 2011 4:30 PM
  • I have a similar issue which will not seem to go away.

    We have  Server 2008 Standard (32 bit) running as a TS.

    I use Win 7 64 Bit Pro - I have updated this to SP1

    My issue is that before loading SP1 on the Win 7 PC I had the protocol error now and then.

    Since SP1 whenever I try and shadow a user it just disconnects them. If I do the same on the Server 2003 users all works fine.

    I have checked a bunch of things but this one has me screwed - I am nearly at the point where I need to remove Win 7 SP1 as at least I could shadow now and then.

    Anyone with a clue as to what I should try next?

    Thursday, March 10, 2011 11:37 PM
  • I'm in the exact same boat as flyingkiwi.  I didn't have the problem until recently.  I'm wondering if it is one of the hotfixes/windows updates that was released that caused this.  I was fine for about 2 months.  Now my users and I get the disconnect.  They lose their work, and I get frustrated because I can't assist.  Calling all MS guru's on this one!!!

     


    JimPonder
    Wednesday, March 23, 2011 3:44 PM
  • I have this same problem.

    - Server 2008 standard with SP2 running terminal service.

    - When I shadow a user connected with an older version of mstsc I recieve "Because of a protocol error, this session will be disconnected. Please try connecting to the remote computer again."

    I have also tried the "Work Around" suggested here and I still recieve the same error.

    Is there somthing I am missing here?

     

    Monday, May 2, 2011 7:29 PM
  • Hi, flyingkiwi,

    What you have seen is a bug we are aware of. In Win7 SP1 some new features are added to RDP but we need to fix something in Server 2008 side (Win7 server/Server 2008R2 already had the fix so it won't happen if you use them as terminal server) to make shadow works. A hotfix (for Server 2008) will be released soon to fix the issue.

    Thanks.

    Wednesday, May 4, 2011 6:39 PM
  • I look forward to that as its a real pain having to have a spare PC or XP Virtual mode just to be able to help users.
    Wednesday, May 4, 2011 9:53 PM
  • Hi, flyingkiwi,

    What you have seen is a bug we are aware of. In Win7 SP1 some new features are added to RDP but we need to fix something in Server 2008 side (Win7 server/Server 2008R2 already had the fix so it won't happen if you use them as terminal server) to make shadow works. A hotfix (for Server 2008) will be released soon to fix the issue.

    Thanks.


    I know that SP1 for Server 2008 R2 supposedly fixed this issue; I however still have this.  Not just with R2, but also with one of my 2008 servers as well.  Any news on this hotfix?  Also is there anyone else out there still experiencing this?  We have struggled with this for far too long. 
    Tuesday, May 24, 2011 8:49 PM
  • I agree - its been going far far too long - even this thread was opened nearly 2 years ago!

    The process we go through now is to use anything but Vista / Win 7 to RDP into our TS just to be able to assist users when shadowing them.

    Seems crazy we refer back to old technology Windows XP for this to work correctly.

     


    Tuesday, May 24, 2011 9:36 PM
  • Psteve_uk, 

    I took what you explained above and put it all into a RAR file here: http://www.stevesig.net/test/Applications/RDP-XPSP3/RDP-XPSP3.rar

     

    Thank you for your additional guidance on this. 

     

    -Steve Signorelli


    • Edited by Steve Signorelli Friday, May 27, 2011 4:49 PM forgot to create proper link
    Friday, May 27, 2011 4:48 PM
  • Yes same problem.

     

    However, I get no server errors and the user to be controlled gets disconnected.

     

    XP mstsc.exe works fine.

     

    Is there still no solution to this?????

     

       Tom

     

    Friday, June 17, 2011 7:57 PM
  • Apparently it's THIS hotfix everyone is looking for.

    http://thehotfixshare.net/board/index.php?showtopic=15195

     

    I have NOT tried it yet. My work around was RDP to one terminal server.

    Within the RDP session RDP to ANOTHER terminal server, and THEN remote control.

    Because originally RDP to one terminal server and then remote control to user, DISCONNECTED USERS and I when remote controlling.

    so RDP to terminal server and RDP WITHIN that terminal server to another term server and then remote works fine.

     

    RDP>RDP within term serv>Remote=Works

    RDP to term serv>Remote=Fails

     

    Friday, June 24, 2011 5:58 PM
  • Friday, June 24, 2011 7:00 PM
  • Hello,

    Confirmed hotfix  http://support.microsoft.com/kb/2523307 It works. Please set mark as answer it.

    Thank you,

    Serkan


    Microsoft bu servisi kullanıcılarına yardım etme, Microsoft ürünleri ve teknolojileriyle ilgili bilgi bankasını genişletme amacıyla ücretsiz sunmaktadır.
    Bu içerik olduğu gibi benim tarafımdan hazırlanmış olup Microsoft tarafından herhangi gibi bir sorumluluk üstlenildiği anlamına gelmez.
    Facebook Üzerinden Takip Et!
    Twitter'da Takip Et!


    Wednesday, July 6, 2011 10:58 AM
  • Wish I could use this hotfix!  I have tried all three of their files available (they all say Vista, despite the hotfix being for Server 2008; and yes I read the section that states that the files for 2008 are included in the installer).  So as of now I'm still sitting unable to properly shadow my users.


    Matt Cetlinski
    Monday, July 25, 2011 8:52 PM
  • I downloaded the kb2523307 hotfix and cant install it on my Win7 box either. People have claimed that having SP1 on server + Win7 side clears things up but it hasnt for me. Still getting "because of a protocol error, this session will be disconnected" with my win7 sp1 + server 2008 R2 sp1 when I try to shadow a user session that is using a Wyse V10L with firmware 7.x.
    Tuesday, August 9, 2011 1:03 PM
  • I believe you need to have Server 2008 SP2 loaded on the server side - not just SP1

     

    Windows 7 Sp1 is Ok

     

    Try loading SP2 on your server and try it again.

    Tuesday, August 9, 2011 10:13 PM
  • Hi flyingkiwi,

    Server 2008 and Server 2008 R2 are different.

    SP2 for Server 2008 is not compatible with Server 2008 R2!

    We have Server 2008 R2 and when I login with RDP from a Win7 client and another user logs in from an xp client and I remote control the xp-client RDP session and then quit remote controlling it then the xp client session on the Remote desktop host (= Terminalserver) gets disconnected - still to this day 15.Sept. 2011.

    Sincerely

    Andreas


    Andreas
    Friday, September 16, 2011 9:29 AM
  • Hey everyone,

    Like Andreas, I am still experiencing these errors.

    I have both 2008 and 2008 R2 servers to support. The hotfix http://support.microsoft.com/kb/2523307 works great for windows 2008, but _not_ for 2008 R2. Even though the article specifies that the hotfix is for 2008 R2 / Windows 7, The "View and request hotfix downloads" button points  you to the resources for Windows Vista and 2008. I tried downloading it onto a 2008 R2 server to install the hotfix and it would not run; the error indicated that it was not for this operating system. 

    <Rant> Come on, Microsoft, you can do better than that! It is sheer sloppiness! </Rant>

    Montanageek

    Friday, November 11, 2011 10:00 PM
  • I am still having the issues as well.  I have found a workaround that works sometimes, and with some clients.  Wish I could nail it down to all of the time.  One common theme however with the servers that have the issue persist regardless of what I do is that they are Server 2008 R2.  If with the work around completed, the users only ever connect from one client then the issue is resolved.  However if they move to another client (XP, or Win 7) the issue returns.  I will continue to watch this thread as well as many others in the hopes that MS will one day perhaps redeem themselves and fix their broken product.

     

    At one point I had a ticket open that made it into the Server development team (or so I was told after 2 months of work on it) and was informed that the issue occurs because there is an error that does not reach the surface that essentially reflects the error that we do see that does state the same, "Access Denied" when the failure occurs.  At that point I was essentially told that I could begin working on getting a step by step procedure on how to reproduce the issue from step 1 of designing, configuring hardware, and installing the os all the way through to the point where I begin receiving the errors.  After 2 months I had to throw in the towel as there were too many other issues to apply time to doing the work that Microsoft should be doing themselves.

     

     


    Matt Cetlinski
    Friday, November 11, 2011 10:21 PM
  • I know one thing - it is doing my head in trying to shadow other users on TS 2008.

     

    Its got to to stage where I have to use the VM XP to support them as using Win 7 Sp1 is an epic fail.

    Sunday, November 13, 2011 10:56 PM
  • This is a bad koke from beginning to end.

     

    My Scenario

    Two New Dell Blades each running windows server 2008 R2 64 fully updated.

    Each blade  hosting two 2008 Svr 64 hosts

    1 Guest is a Terminal server with 44 paid up liscences.

    Another VM is an SQL 2008 server hosting a business critical com application used by the terminal servers.

    Build is pretty far on and the CEO of the client who is pretty tech aware is on having a look - I go to shadow his session and it disconnects

     

    (He has a new Dell laptop running 64 Windows 7 Pro fully updated, I am connecting in from a Win  7 64 bit.)

    WHAT HAPPENS? He disconnects!

     

    How whatever excuse for an MS employee who has been ignored this for two years rap you head around this:

    I am your customer

    That CEO is your customer

    Dell is your customer

    And you just made all three of us look like fools.

    What we spend is what pays you.

     

    So what about your glorious hotfix.

     

    Well it's listed as VISTA. So I should just ignore that and install it on my 2008 servers?

    After all it's not like at the stage of Microsofts decomposition into complete chaos and anarchy that anyone should actually believe KB/Hotfix descriptions. Like IT pros we will just keep using our psychic powers to keep second guessing around the completely disfuctional breakdown between MS dev and Support.

     

    Fire someone, if it happens to be the same person that put Network Location Awareness in server products you will have done every single IT pro that spends money with MS a huge favor.

     

     

     

     

     

     

     

     

    1)The issue was well documented here TWO YEARS ago. Changing local policy as decribed DOES NOTHING

     

     

    Thursday, January 19, 2012 4:17 PM
  • Installed hotfix on the two 2008 64 machines....Windows6.0-KB976110-x64.msu

     

    tried to install it on W7 64 bit laptop - result - not applicable to this computer.

     

    Tested and it disconnected

     

    Cleared off all sessions on 2008 64 terminal server and rebooted.

    Tested and disconnected.

    Fire someone. Fire them now.

     

    Thursday, January 19, 2012 4:46 PM
  • I would agree. Fire someone!  I am STILL dealing with this issue as well.  I am continuing to chime in here because we HAVE to get someone with half a brain at Microsoft to get this resolved.


    Matt Cetlinski
    Thursday, January 19, 2012 9:32 PM
  • Not sure if it applies here, but we were getting this error on Remote Desktop for Administration connections to a specific server (using Windows 7 to 2003). Workaround was go to the properties Remote Desktop Connection > Experience > Allow the following and deselect all. Able to connect without error.


    Hi all,

    I tried to deselect all check-boxes on both sessions. It has no effect, still disconnecting.

    Further more some other option that was helpful on another server when starting Task Manager for elevated rights check on the Processes tab the "Show processes from all users" check box. Try it, it might help.

    In the meantime, hey Microsoft guys, we are paying a lot of money on the licenses, why do we have to pay more money to another software to do what embedded features in your soft is supposed to do? It worked on windows 2003, even on 2008 but for some reason it stopped working at one moment, it think it is a nasty update.
    I have 4 TS's on 2008 32 bit and I need TeamViewer to remote connect in my own yard! Come on!!! This is outrageous!!! Please DO YOUR JOB!!!
    Daniel Lupu
    • Edited by Daniel Lupu Friday, January 20, 2012 7:58 AM
    Friday, January 20, 2012 7:49 AM
  • This is still an issue?  When is MS going to fix this? 
    Tuesday, February 21, 2012 8:13 PM
  • YEP. still a bug.  Microsoft is probably one of the best at ignoring it's own partners, and customers that develop software for use on their OS's and with their own tools. 

    MICROSOFT > Please do something! 


    Matt Cetlinski

    Tuesday, February 21, 2012 8:25 PM
  • We're seeing this issue now as well.

    Our environment: Terminal Servers either 2003 or 2008.  Our end users connect to these terminal servers via thin client machines using RDP 5.5 or 6.0.  I had previously connected to the same Terminal Servers our end users connect to using an XP 32 bit machine and RDP.  No issues on that front.

    Recently upgraded to a Windows 7 SP1 64 bit machine.  Using RDP to connect to same Terminal Servers.  Whenever I attempt to shadow an end user using Terminal Services Manager, if that end user is connected via RDP 5.5, the session will automatically disconnect and I never get the chance to shadow.  When that end user is using RDP 6.0, we have no issues as long as that end user is on 2003 Terminal Server.

    If that end user is on a 2008 Terminal Server, then the session will disconnect as soon as I attempt to shadow, no matter what RDP version they are using when connecting to one of our Terminal Servers.

    Thursday, February 23, 2012 9:03 PM
  • Hi TP, i had the similar problem and i resolved with this KB publicated in March 2011 related Remote Desktop connections on Windows Server 2008 R2 post service pack 1.

    The error message was:

    Your remote desktop session has ended - The connection to the remote computer was lost, possibly due to.....

    Install this KB and tell us if the problema was resolved:

    http://www.microsoft.com/download/en/details.aspx?id=29169

    Regards,

    Heber Gonzalez


    NOTA: Si llegaste a la solución de tu problema, por favor haz clic en "Proponer como respuesta" así otros visitantes del sitio pueden identificarlo como resuelto en caso de que les suceda lo mismo. Heber Gonzalez Consultor en Infraestructura y Mensajería Microsoft www.xelcon.com.ar http://ar.linkedin.com/in/hebergonzalez

    Monday, March 26, 2012 2:14 PM
  • Thanks Heber,

    However this applies to Server 2008 R2 where I use Server 2008 Std. The bug remains..... :-(

    Monday, March 26, 2012 9:01 PM
  • Has anybody ever found a solution for this?? I still have a Windows Server 2008 32-bits with Service Pack 2 (so no R2), but I've tried every "solution" from this thread but without succes. The only workaround that works is installing Windows XP Mode and starting an RDP session to the server from that, but this is a time consuming option that I don't want. Plus it is not standard available on every PC in our company, so we first have to download it manually.

    Why can't Microsoft find a solution for this after all these years??

    Wednesday, March 28, 2012 6:50 AM
  • Use remote desktop services manager, right click on the user your trying to control and click remote control.  Change the key sequence to back out to Ctrl + * 

    After doing this one time its worked since then with any key sequence to back out of the remote control session.

    Wednesday, April 11, 2012 3:04 PM
  • Thank you, TP!

    I never would have figured this out myself.

    Wednesday, April 18, 2012 6:13 PM
  • Hi,

    I had came across with the similar issue of losing RDP connection post deployment of Service Pack 1 on Windows Server 2008 R2.

    I managed to install the following windows Security Update for Windows Server 2008 R2 x64 Edition

    KB2667402

    Now, I together with other admins, can access via RDP simultaneously.

    Cheers....

    Tuesday, April 24, 2012 12:45 PM
  • Nice. I just stepped through this and now I no longer get dropped from my RDP session after remote controlling a user. Thanks. Very useful.
    Wednesday, April 25, 2012 8:29 PM
  • I have been facing the issues since long time as per Iqbal the patch KB2667402 works for me and RDP issues is now resolved

    Thanks Iqbal for helping me in this:)

    Tuesday, May 8, 2012 6:39 AM
  • Seems the solution is fairly simple - limit the color depth to either 24 or 16 bit.  Set this using GP.  However, this is a workaround as the unwanted consequence is Aero features are disabled.

    What I found:

    1.  RD session to Server 2008 R2 set to 32 bit and client connection (in this case a Win7 client) set to 32 bit - result, black screen on server, client disconnects with protocol error after using hot-key combination to exit.

    2.  RD session to Server 2008 R2 set to 32 bit and client connection set to 16 bit - result, can control, but exiting leaves the server connection unresponsive.  Client is fine.

    3.  RD session to Server 2008 R2 set to 16 bit and client connection set to 16 bit - result, exits correctly.  Client is fine.

    I am no curious to discover whether the problem is depth or Aero, so will have to experiment more.

    BTW - the above patch was already installed.  Looking forward to further discussion!  Thanks,  Duckysan1

    Wednesday, May 16, 2012 12:35 AM
  • Hi,

    Yesterday, I had came across with the similar issue of losing RDP connection post deployment of Service Pack 1 on Windows Server 2008 R2's cloned image.

    I again managed to install the following windows Security Update for Windows Server 2008 R2 x64 Edition :

    KB2667402

    Now, I together with other admins, can access via RDP simultaneously.

    Cheers again....

    Thursday, June 7, 2012 11:52 AM
  • I spent one full day to figure out this problem, finally how did I solve this issue is simply restarting our remote server. 
    Wednesday, July 18, 2012 4:18 AM
  • I have problem with remote control another users sessions (from WIN 7 to WIN XP) or (Windows 7 to Windows 7) on Windows Termilal Server 2008 SP2. 
    When I Install Windows 8 release 9200 ALL PROBLEMS WERE RESOLVED. And I NOTHING reconfigure on terminal server!

    Now I can remote control RDP user sessions of Win XP, Win 7 and Win 8 Client from Win 8 RDP session on terminal server. 


    • Edited by Vlad Lerkin Friday, August 31, 2012 3:26 PM
    Friday, August 31, 2012 3:15 PM