Remote Desktop Login Error - Because of an error in data encryption, this session will end


  • I have been using a remote desktop connection with a VPN for one of my clients for several years without problem on an XP machine.  I just purchased a Windows 7 machine and am now getting this error. 

    "Because of an error in data encryption, this session will end. "

    My XP machine still connects to the VPN and RDP without problem on the same VPN and network and the new Windows 7 machine, everything is the same.  The only thing different is Windows 7 OS. 

    In addition (and this may also be a clue), I can make a connection to the client's SQL database without problem in SQL 2008 on the XP machine, but again, not with Windows 7.

    The Win 7 is 64 bit Windows 7 Professional, the server I am connecting to is Windows 2008 64 bit.   The Win 7 machine is new so I've done little to change it except installing the programs I work with. 

    Any help would be greatly appreciated. 

    Tim Conway

    Tim Conway

    Thursday, November 15, 2012 2:51 PM

All replies

  • Hi,

    Please refer to the link below and check if it helps:



    TechNet Community Support

    Monday, November 19, 2012 9:47 AM
  • Hi Spencer

    Thank you very much for your response.  I did see this in my early search for answers and it was tantalizingly close.  But it did not provide enough information for me to implement. Possibly though, you or someone can shed some additional light on the successful answer.  The original question was identical to my problem; all RDP connections work between the existing Client and Host, except when you attempt RDP to the host with a Windows 7 Client, leading that poster to believe it to be a setting on the Win 7 Client creating the problem. 

    Here is the answer that fixed the problem for the other poster that I could not understand:

    I did this to fix the issue:

    Change Security layer of the RDP-TCP session to "RDP Security Layer".  That seemed to allow us to bypass the schannel errors we were seeing in the logs.  Seems like when you have a second IP it does something to break the SSL host-specific certificate.

    Here are my questions. 

    Change Security layer of the RDP-TCP session to "RDP Security Layer". 

     -  Where? Is this on the client or the host?  I don't have access to alter the host, but if I can do something on the Client, that would be what I can do.  But where is this.  I tried looking at my Local Group Policy Editor on the Win 7 client, but could not find any settings that looked promising. 

    Seems like when you have a second IP it does something to break the SSL host-specific certificate?

     -  I'm not sure the Host I'm logging into uses a certificate, I just RDP in to an IP after connecting to a "bare bones" Windows VPN, no special settings. 

    Finally, I am unfortunately limited to my Client machine for making changes.  If the above all applies to the Host, is there anything I can do on the client to rectify the problem. 

    Thanks for any help on this.


    Tim Conway

    Monday, November 19, 2012 3:15 PM
  • Hi,

    Change Security layer of the RDP-TCP session to "RDP Security Layer".  This function can be found at Group Policy. You can locate at Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security\Require use of specific security layer for remote connections.

    Hope this helps. 


    TechNet Community Support

    Tuesday, November 20, 2012 2:09 AM
  • Hi Spencer

    Thanks for clearing that up for me.  I found the setting at last and tried it.  Alas, to no avail, still getting the same error...unless I need to reboot for the group policy to take effect.  But, I've been instructed (by my wife) to stop working now, so I'll try that tomorrow. 

    Your response has been much appreciated. 


    Tim Conway

    Tuesday, November 20, 2012 3:24 AM
  • I'm having the same experience.  with a new Dell laptop connecting to a client.  I have 2 laptops at my location and one can connect as the other cannot.  The issue has to be on my work laptop, as the person laptop connects without error.
    Thursday, December 13, 2012 10:54 PM
  • I have still not worked it out and am working on my old computer for the customer where I can't connect.  I should point out, I do almost all remote work, only on the combination of this customer's network and my new Dell desktop do I have the problem.  Everywhere else is fine. 

    I tried everything on the desktop I could find from searching for posts.  But I have no access to change the server. 

    So clearly, it can be resolved by doing something on the desktop, as my other destop is fine. 

    Network card: Intel(R) 82579LM Gigabit Network Connection

    OS: Windows 7 SP1

    Router: NetGear WNR3500L

    Tried too many things to list here.  Nothing seems to help. 

    Let me know if you find anything out. 


    Tim Conway

    Thursday, December 13, 2012 11:27 PM
  • You could try something different.

    Use Chrome remote desktop. It runs in a browser window and can go full screen.

    I can even stream Netflix with it.

    Friday, December 14, 2012 3:20 AM
  • I have a Lenovo Windows 7 64 bit machine that connects to the problem client without issue. 
    Wednesday, January 30, 2013 6:38 PM
  • I have the exact same NIC in my laptop. 

    Network card: Intel(R) 82579LM Gigabit Network Connection

    OS: Windows 7 Professional 64 bit SP1

    I worked with Dell who refused to own the problem.

    I am in the process of re-loading the OS to see if it is a bad load.

    We have another remote co-worker with a Dell machine and the same symptoms.

    My Lenovo continues to connect without issue.

    Tuesday, August 6, 2013 9:56 PM
  • I know this is old but I'm having the same issue and it randomly started a few weeks ago.  Did anyone find a solution to this?

    I do have that name NIC... 82579LM in a Dell Latitude

    Monday, November 18, 2013 5:15 PM
  • MY SOLUTION!!!!!

    I was also experiencing Windows 7 RDP issues and I was also confident it was on my client side...

    I edited in the following in the Group policy

    Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client\Configure server authentication for client.

    I "enabled" this and chose "always connect even when authentication fails".  Effect seems to be immediate and require no reboot.

    Thursday, January 9, 2014 3:59 PM
  • I got into this issue as well. I know the cause of it but can't seem to figure out why.

    I have two networks running at the office and both connect to RDP via VPN. Sometimes, when one of the networks is slow, our staff often "jumps" from one network to another. Usually, it works just fine but today, one of the computers got this issue after "jumping". This computer first got into an IP conflict because I didn't reserve the IP to it and some other device got this IP first. So I changed the shortcut to avoid the IP conflict. And this is where this issue occurred. I tried all the above suggestions and those that are posted in the links shared here but none of this worked. Sometimes, I got past the logging in screen on the remote computer but as soon as I click on it to start working, it gave the error message. I even tried to bind this computer's MAC's address to both networks' IP but it didn't help.

    It's worth noting that other computers in the office are working fine and they're able to "jump" from one network to another.

    I don't know if it helps if I share here how the network switch works:

    C:\Windows\System32\netsh.exe interface ip set address name=LAN static 1

    The 2 networks are 192.168.10.x and 192.168.1.x on the 1 24port switch. I basically create 2 shortcut on desktop for the above command line with specified IP to each network on each computer.
    It works very well until today and it really annoyed me that only one computer suddenly got into this problem while the others are fine.

    Very appreciate if anyone can give me an insight on the issue.

    Monday, March 24, 2014 10:13 AM