none
Event ID 56 TermDD

    Question

  • The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.

    Has anyone come across this and know what this means? from what I can gather from users at remote sites (hardware VPN) they freeze and then it attempts to reconnect - after a minute it reconnects back to the session. Could this be a license cal issue?

    Thanks 
    Thursday, October 16, 2008 2:29 PM

Answers

  • Looks like temporary network problems (sometimes may be permanent) as mentioned above. With HP servers often a new PSP Pack might be the issue.
    Citrix Technology Professional, PubForum Founder http://www.pubforum.net
    • Marked as answer by Metallicabk Wednesday, October 29, 2008 6:03 PM
    Wednesday, October 29, 2008 5:50 PM
    Moderator
  • The NIC's are set to Auto - I have not seen this problem since I posted this. I haven't updated the drivers as I am using a couple of test servers which some users are now using. This will be replaced shortly so - if its not broke then dont fix it.
    • Marked as answer by Metallicabk Wednesday, October 29, 2008 6:03 PM
    Wednesday, October 29, 2008 9:41 AM

All replies

  • I see this error at least once a day with my Server 2008 install.  I'm using Remote Desktop Client for the Mac version 2.0.
    • Proposed as answer by VBA_IT Monday, August 10, 2015 1:26 AM
    Friday, October 17, 2008 2:11 AM
  • It is usually related to network problems. Updating NIC drivers, checking the switches, setting the speed of NIC's to auto might help you to solve the problem. This is not a License problem for definite.
    Citrix Technology Professional, PubForum Founder http://www.pubforum.net
    Friday, October 17, 2008 5:06 PM
    Moderator
  • I see this error as much as once an hour on my Server 2008 install, also using Remote Desktop Client for the Mac version 2.0.

    Wednesday, October 29, 2008 4:35 AM
  • The NIC's are set to Auto - I have not seen this problem since I posted this. I haven't updated the drivers as I am using a couple of test servers which some users are now using. This will be replaced shortly so - if its not broke then dont fix it.
    • Marked as answer by Metallicabk Wednesday, October 29, 2008 6:03 PM
    Wednesday, October 29, 2008 9:41 AM
  • Looks like temporary network problems (sometimes may be permanent) as mentioned above. With HP servers often a new PSP Pack might be the issue.
    Citrix Technology Professional, PubForum Founder http://www.pubforum.net
    • Marked as answer by Metallicabk Wednesday, October 29, 2008 6:03 PM
    Wednesday, October 29, 2008 5:50 PM
    Moderator
  • The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.

    Has anyone come across this and know what this means? from what I can gather from users at remote sites (hardware VPN) they freeze and then it attempts to reconnect - after a minute it reconnects back to the session. Could this be a license cal issue?

    Thanks 


    I found solution for me, when I could not log on to the server 2008 or windows 7 with Network Level Authentication checked.
    On the target computer there were these event logs:

    Name:      System
    Source:        TermDD
    Date:          *theSame*
    Event ID:      56
    Level:         Error
    User:          N/A
    Computer:      *
    Description:
    The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP: *

    +

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          *theSame*
    Event ID:      4625
    Task Category: Logon
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      *
    Description:
    An account failed to log on.

    Subject:
     Security ID:  NULL SID
     Account Name:  -
     Account Domain:  -
     Logon ID:  0x0

    Logon Type:   3

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  *user*
     Account Domain:  *

    Failure Information:
     Failure Reason:  User not allowed to logon at this computer.
     Status:   0xc000006e
     Sub Status:  0xc0000070

    Process Information:
     Caller Process ID: 0x0
     Caller Process Name: -

    Network Information:
     Workstation Name: *client*
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  NtLmSsp
     Authentication Package: NTLM
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0


    My solution:  allow this account [*user*] to log on locally on the client computer [*client*]. I used account which haven't rights to log on to my [*client*] station (change AD property = userWorkstations).

    Tuesday, October 13, 2009 4:55 PM
  • I am getting the same error:

    "The Terminal Server security layer detected an error in the protocol stream and has disconnected the client."

    Has anyone gotten a fix for this?

    When this happens it kicks off the users and they get a black screen.

    Any help would be much appreciated.

    Monday, May 24, 2010 3:44 AM
  • You might check this out:

    http://blogs.technet.com/b/askperf/archive/2010/03/25/the-curious-case-of-event-id-56-with-source-termdd.aspx

    In our case, it's C00000B5 - STATUS_IO_TIMEOUT - the connection has timed out.

    And unlike the previous poster, we don't have any corresponding failures in the Security log, just an indication of a logoff. In most cases, the IP mentioned is that of the router, not a remote site. Also, many of the times are after midnight, which may suggest sessions timing out and being logged off per RDS timing settings. For now, particularly without being able to tie this to any unusual client behavior, I'm assuming this is normal.

     

     

    Sunday, June 06, 2010 2:18 AM
  • This does NOT apply to SERVER - I have an HP g71 340us LAPTOP - Win 7 Pro Ult 64-bit - same problem, I found a NIC driver from Sept 09 that worked instead of the Jan 2010 driver - if you have the Intel(R) WiFi Link 1000 BGN then this link will get you what you need:

     

    http://www.pcpitstop.com/drivers/download/Intel(R)~WiFi~Link~1000~BGN.html

     

    Good Luck and as far as SERVER goes - well try the same - ROLL THE DRIVER BACK!!

     

    -jpw

    Monday, June 07, 2010 10:12 PM
  • We see this error on a Server 2008 R2 when the VPN-Connection between the site with server and the site with the clients goes down.
    Thursday, December 02, 2010 12:11 PM
  • This can be resolved by either:

     

    1) Installing the latest remote desktop client, or

     

    2) Changing the remote desktop setting on the target machine to allow connections from computer running any version of Remote Desktop (less secure)

    Friday, December 31, 2010 9:05 AM
  • I'm having the same issue. In my case users get a message "Access Denied" when they attemp to login to terminal server. All apps which run from this server loose connectivity. I have to reboot the server to rectify this but happens every day.

    Other error showing on the server are CAPI2 Event 512, Group Policy 1054 and 1080.

    In my case this terminal server is part of SBS 2011 domain.

    Any further comments/ resolution are appreciated.

    Shaquile


    Shaquile Mubariz
    Wednesday, April 13, 2011 9:25 PM
  • There is no licensing problem. Check your settings on network cards, any conflict in the settings of the NIC's preventing successful connection.

    Regards.

    Tuesday, May 10, 2011 2:45 PM
  • Hi All,

    I got this issue when connecting from a Vista laptop to a 2008 server via SSTP VPN. This is a RDC error and KB 969084 will generally fix this for you (it worked for me although the RDC connection took a while to get itself together).

    Thursday, August 18, 2011 2:41 PM
  • I had the same problem on XP computers, it appears that KB 969084 update has helped.
    • Proposed as answer by CWMoreland Friday, April 27, 2012 5:30 PM
    Friday, August 19, 2011 9:17 AM
  • Had the same problem and figured out that I HAD DISABLED THE USER ACCOUNT and forget it! Just check if the user account is disable, just like the guest account is.
    Adelino Araujo
    Friday, August 26, 2011 10:03 AM
  • In the end we changed routers from Zxyel to Cisco and experienced far fewer disconnections
    TS GURU
    Friday, December 23, 2011 11:28 AM
  • Getting EventID 56 in the System Event log from TermDD and looking up the last word of the binary data (the error code) via err.exe is key to solving this.

    I had the "LSA could not be contacted" error message, and it turned out to be because I'd set a restriction on which computers an account could log on to. Nothing to do with networking or drivers at all.

    See http://rcmtech.wordpress.com/2012/01/18/remote-desktop-the-local-security-authority-cannot-be-contacted/ for more info.

    Wednesday, January 18, 2012 11:42 AM
  • This can be resolved by either:

     

    1) Installing the latest remote desktop client, or

     

    2) Changing the remote desktop setting on the target machine to allow connections from computer running any version of Remote Desktop (less secure)


    This does not work. I got the same problem with using the latest RDP client and using the most compatible setting.
    Thursday, January 26, 2012 3:43 PM
  • I had this exact same issue. I decided that perhaps I had a bad SID because we had just restored the system state of this server and so I did the only thing I know helpds resolve SID issues - sysprep'd the server (C:\Windows\System32\Sysprep\. After doing this and re-joining the server to the domain, RDP sessions were back in business.
    • Proposed as answer by Roland Beaucage Thursday, February 09, 2012 6:30 PM
    Thursday, February 09, 2012 6:29 PM
  • I used the post above (http://blogs.technet.com/b/askperf/archive/2010/03/25/the-curious-case-of-event-id-56-with-source-termdd.aspx) to find that my error was 80090330 - SEC_E_DECRYPT_FAILURE – the data on the wire got corrupted.

    I was able to fix the problem by deleting a duplicate Certificate, the following site talks about the problem. http://blog.lmello.com.br/?p=22

    • Proposed as answer by Syc0tik Wednesday, February 15, 2012 10:40 PM
    Wednesday, February 15, 2012 10:39 PM
  • When the number varies, figuring this out is a tad more difficult. We also have some Event ID 50's, which I think are related, but these are our Greatest Hits for Event ID 56:

    # for hex 0xc00a0006 / decimal -1073086458 :
    STATUS_CTX_CLOSE_PENDING
    # A close operation is pending on the Terminal Connection.

    # for hex 0xc000020d / decimal -1073741299 :
    STATUS_CONNECTION_RESET
    # The transport connection has been reset.

    # for hex 0xc00000b5 / decimal -1073741643 :
    STATUS_IO_TIMEOUT
    # {Device Timeout}
    # The specified I/O operation on %hs was not completed before
    # the time-out period expired.

    # for hex 0xc00a0032 / decimal -1073086414 :
    STATUS_RDP_PROTOCOL_ERROR
    # The RDP protocol component %2 detected an error in the
    # protocol stream and has disconnected the client.

    Saturday, March 10, 2012 5:41 AM
  • When trying to login on a server with my admin user I received this error. After some troubleshooting I found out that an expired password on my admin user was the reason for this error. 

    Thursday, April 12, 2012 9:53 AM
  • I was having similar problem which was coupled with TermDD event id 56.

    Just now, after lot of hardship I could able to resolve mine by editing RDP-Tcp connection under TS Configuration. After changing "Security Layer" to "RDP Security Layer" problem resolved.

    Hope this will be of some use to oyu and others


    InfoSeeker

    Thursday, April 19, 2012 5:43 PM
  • I was having similar problem which was coupled with TermDD event id 56.

    Just now, after lot of hardship I could able to resolve mine by editing RDP-Tcp connection under TS Configuration. After changing "Security Layer" to "RDP Security Layer" problem resolved.

    Hope this will be of some use to oyu and others


    InfoSeeker


    This was the fix for me.   In Server 2008 R2, open Remote Desktop Session Host Configuration and double-click RDP-Tcp in the Connections block.  In the General tab, change the Security layer pulldown box from Negotiate to RDP Security Layer.
    • Proposed as answer by TomGibson Thursday, April 26, 2012 1:18 PM
    Thursday, April 26, 2012 7:51 AM
  • Additionally for me it was necessary to turn off the group policy setting in Security Settings\Local Policies\Security Options requiring FIPS compliant algorithms, and set the Encryption Level to Client Compatible.
    Thursday, April 26, 2012 1:20 PM
  • I wonder why "RDP Security Layer" should be necessary, as it eliminates the desirable NLA?  I believe this also means that the certificate you have installed isn't even used any longer, which is too bad. This is not a very good solution at all, I think.

    Negotiate: This is the default setting. The most secure layer that is supported by the client will be used. If supported, SSL (TLS 1.0) will be used. If the client does not support SSL (TLS 1.0), the RDP Security Layer will be used.

    RDP Security Layer: Communication between the server and the client will use native RDP encryption. If you select RDP Security Layer, you cannot use Network Level Authentication.

    @Tom, where did you see reference to the FIPS option being involved?  The default is disabled for it already in policy. Are you saying that yours was enabled somehow?  Maybe you once used the "FIPS Compliant" encryption level?  Also, "Client Compatible" is the default in RDP-Tcp.

    Friday, April 27, 2012 1:34 AM
  • @Tom, where did you see reference to the FIPS option being involved?  The default is disabled for it already in policy. Are you saying that yours was enabled somehow?  Maybe you once used the "FIPS Compliant" encryption level?  Also, "Client Compatible" is the default in RDP-Tcp.

    Correct, disabled is the default setting for FIPS Complaint algorithms so this will not be a problem for most people. However in my case I am working with some servers configured to use a set of hardened group policies customized from the MS Security Compliance Manager baselines recommended for Server 2008 R2. The recommendation is to use FIPS compliant algorithms where possible, in my case this changed the encryption level for RDP to "FIPS Compliant". Changing the policy setting did revert the encryption level to default, however if it is required for a particular environment to enforce FIPS compliant encryption algorithms this will prevent older e.g. RDP 6/5 clients from being able to connect to the RDP server as they do not seem to support this type of encryption (tested with a WinCE 6.0 RDP viewer). In my case when I changed the Security Layer to Client Compatible I was still unable to connect, it was only after changing the encryption level as well (having disabled the FIPS compliant GP) that my older RDP client could work.

    Monday, April 30, 2012 2:17 PM
  • I have same issue connecting RDP session..I am using abc user ID to connect RDP to Server1..I have given server1 access to abc account logonto in AD. I am able login locally on domain with abc ID but when I try with RDP its gives error "Local Security Authority cannot be connected"

    I see event 56 with Source termdd..same error code...pls help to resolve this issue.

    Friday, November 16, 2012 11:19 PM
  • This error annoyed the heck of of me. But  I finally found our cause to be the Security layer negotiation, or some function of using SSL TLS

      RDP session host management and changing the Security Layer option from Negotiate to RDP Security Layer has made all Term DDs Event 56 stop happening. I run a 300 user RDP farm so any interruption gets my attention.

    Hoping that MS can provide a fix where we can use SSL TLS 100% . Although it seems to always be the same clients that disconnect, not a random set. So maybe it is some piece on the client side config for SSL TLS.


    • Edited by Homer2112 Saturday, November 17, 2012 12:22 AM
    Saturday, November 17, 2012 12:18 AM
  • Yes...Inspite of RDP security Layer configured...I get the same error..can somebody give the fix for this issue..
    Sunday, November 18, 2012 5:09 PM
  • I was having similar problem which was coupled with TermDD event id 56.

    Just now, after lot of hardship I could able to resolve mine by editing RDP-Tcp connection under TS Configuration. After changing "Security Layer" to "RDP Security Layer" problem resolved.

    Hope this will be of some use to oyu and others


    InfoSeeker


    This was the fix for me.   In Server 2008 R2, open Remote Desktop Session Host Configuration and double-click RDP-Tcp in the Connections block.  In the General tab, change the Security layer pulldown box from Negotiate to RDP Security Layer.

    Hi! This also worked for me, but as far as I can tell, this seems an odd issue, because it's only happening on a single server (2008 R2 - virtual machine running on VSphere). We have many other servers running on the same host, with the same configurations, but this is only happening on this server. No one here on the IT Dept. recalls any configuration change\update that could have caused this to happen.

    The Terminal Services certificate seems fine also.

    Has anyone came to a conclusion on what could be the root cause of this?


    Tiago Viana, MCITP:SA


    Friday, January 25, 2013 11:36 AM
  • I was having similar problem which was coupled with TermDD event id 56.

    Just now, after lot of hardship I could able to resolve mine by editing RDP-Tcp connection under TS Configuration. After changing "Security Layer" to "RDP Security Layer" problem resolved.

    Hope this will be of some use to oyu and others


    InfoSeeker


    This was the fix for me.   In Server 2008 R2, open Remote Desktop Session Host Configuration and double-click RDP-Tcp in the Connections block.  In the General tab, change the Security layer pulldown box from Negotiate to RDP Security Layer.

    Hi! This also worked for me, but as far as I can tell, this seems an odd issue, because it's only happening on a single server (2008 R2 - virtual machine running on VSphere). We have many other servers running on the same host, with the same configurations, but this is only happening on this server. No one here on the IT Dept. recalls any configuration change\update that could have caused this to happen.

    The Terminal Services certificate seems fine also.

    Has anyone came to a conclusion on what could be the root cause of this?


    Tiago Viana, MCITP:SA



    As soon as I changed this setting in TSConfig for Server 2008R2 the issue has been resolved. THANK YOU!
    Friday, August 23, 2013 1:04 PM
  • I was having similar problem which was coupled with TermDD event id 56.

    Just now, after lot of hardship I could able to resolve mine by editing RDP-Tcp connection under TS Configuration. After changing "Security Layer" to "RDP Security Layer" problem resolved.

    Hope this will be of some use to oyu and others


    InfoSeeker


    This was the fix for me.   In Server 2008 R2, open Remote Desktop Session Host Configuration and double-click RDP-Tcp in the Connections block.  In the General tab, change the Security layer pulldown box from Negotiate to RDP Security Layer.

    This also worked for me. Then I changed it back to Negotiate and clicked the default on the SSL certificate section (not sure if it did anything), and it worked correctly. The config must have been corrupted somehow.


    • Edited by Gerard Sexton Wednesday, March 05, 2014 9:31 AM Formatted quote
    Wednesday, March 05, 2014 9:29 AM
  • Note please that this works mainly due to fact that without certificate RDP fall back to legacy mode of authentication, it looks like that underlying problem is somewhere else... 
    Thursday, May 15, 2014 6:28 AM
  • Although I could use the native MS RDP client to connect to client computers, my "mRemoteNG" console would not connect to this ONE Win7 Pro client.  Reducing the authentication layer to "any" did the trick for me.
    Wednesday, January 07, 2015 4:55 PM
  • Hi , It works for me after I reset my admin Id password.

    Thanks

    Thursday, March 03, 2016 2:25 AM
  • Unfortuntaley this does not apply to my server. The clients are running the latest version and the server is already set to use any version of the remote client.
    Wednesday, July 20, 2016 8:27 AM