All of our Windows 8.1 computers suddenly refuse Remote Desktop connections.

The problem is when we connect TO Windows 8.1
We don't have the problem when connecting to other Windows versions.

edit: problem solved with the Microsoft update KB2962806. Thanks to Bertrand SCHITS for his answer.

What we found until now:

  • we can always connect as a local user. The problem is only for domain users (admin and regular)
  • we can connect with old mstsc.exe versions. For example we can connect from Windows 2003 and 2003 R2 computers. We can't connect from Windows 7, Windows 8.1, and Windows 2012 R2.
    If we copy the old mstsc.exe (version 5.2.xxxx) from Windows 2003 to a newer computer, we can connect
  • if we connect from an old mstsc.exe version (as stated above), then during several minutes we can connect from whatever version we want. We must use the old version again after a random amount of time (from 30 seconds up to several hours)
  • with the recent mstsc.exe versions we sometime can't connect some users, but this works with other users. This behaviour disappear as soon as we use an old version, and can reappear 2 days later
  • (thanks to Warren's answer) if we manually add enablecredsspsupport:i:0 into the .rdp file, the credentials are not asked before connection (so the behaviour is the same as with old clients), and we can connect with whatever client version. But we can not auto-connect, and the login process involve each time to choose to logon as another user (even if it is the same user)
  • (thanks to Pathum Anjana) we applied the optional update KB2830477 on both sides of the connections

What we tested:

  • we tested from local network to local, and from distant to local. No difference
  • we disabled the firewall
  • we tested disabling every security features with gpedit.msc Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
  • we enabled auditing for logon events, and nothing into the logs. Nothing obvious into other logs (how to enable RDP protocol logs?)
  • we tested on one computer located on another network (the domains are not related), which has only 7-zip installed. No printer drivers, no Group Policies, nothing else. It is only a fresh Windows 8.1 up to date. We have exactly the same problem
  • we asked Google, and he said "I really don't know". He now direct us to this page, which is a very good answer but not really helpfull
  • we removed every updates until february 25 (several days before the problem occured). No improvement, so the problem could be an existing setting set up to a different value by a recent update (and not reverted back when the update is removed, which is probably the usual behaviour)

When we can't connect, the error message is exactly the same as the one we get with a wrong password (but no entry into the security log):
enter image description here

  • every computer has valid licences
  • we use MSE as anti-virus
  • some Windows 8.1 are preinstalled by the manufacturer (Lenovo), while others are installed by us. The only common factor I see is the fact we manage all of them

Any idea about what we can do to troubleshout this ?

  • 1
    @RedShift: we obviously use the same method when it works and when it doesn't. We always use domain\username. Mar 14 '15 at 21:57
  • 5
    Why the down vote on this? The question reads as well researched.
    – jscott
    Mar 16 '15 at 0:25
  • 1
    I would look at how these Win 8.1 computers are being deployed. Is it the same image that is being pushed to these computers? Perhaps the image is corrupted. We need to look for the common factor. Something has to be setup differently on the 8.1 machines. Especially if you don't have any issues using RDP to access other OSs.
    – veel84
    Mar 16 '15 at 1:48
  • 2
    Just adding my findings to this thread.... I am an IT consultant and I am having the same problem at multiple customers sites....all of which started having problems on March 11th. 3 different customers, none of the deployments were imaged, all on different networks, all behind different firewalls, all in different environments. One is a windows 2003 domain, one 2008, and one 2012. All can be reproduced exactly as described above. Only caveat is that RDP works as long as I log in as administrator (local or domain). If I log in as a user, I get the "The login attempt failed" error, even if I ma
    – user276468
    Mar 16 '15 at 2:34
  • 1
    Do you have anything related to this in the event viewer? It would be nice to see a log message abou this. Perhaps a Wireshark trace of the login handshake would also be helpful.
    – MrMajestyk
    Mar 16 '15 at 10:20

Maybe this is related to KB2962806. You should try to apply it.
I don't know how to apply this update because it is not available on the Microsoft site. I only get it with the automatic Windows update but not on every computers.

This update solved a similar problem for me. And since this update is applyed on SOME computers, every others work too. I didn't searched why.

  • I tested on two computers and the problem seems solved. I need more tme to ensure this is ok. Mar 19 '15 at 16:01
  • 1
    I confirm this KB2962806 is the right one for our problem. Thanks! Mar 20 '15 at 14:23

Credential prompt has been driving me mad for the past couple of days, and following the chain of recent events leads me to believe it's related to KB3035017 that our 2012 RDP servers installed recently.

After searching this post and other I've come across something that so far is working around the problem.

Testing RDP icons side my side on the same machine yields credentials prompt error one one, and successful login on the other.


Hope this helps others, I'll continue to monitor and search for a correct fix.


  • I confirm enablecredsspsupport:i:0 partialy solve the problem. Question updated Mar 17 '15 at 12:57

It probably works with the older RDP clients because it forces a protocol version downgrade where whatever issue causes this does not occur.

My guess is that it might be related to screen resolution. Microsoft made quite a few changes related to screen resolution and multi-monitor handling in RDP in Windows 8.1. Although your symptoms do not appear to be related to resolutions, maybe the negotiation fails between the Windows 7 RDP client and Windows 8.1?

That would also explain why it works for some users and not for others - they might have different resolution settings on either the client, or on the target 8.1 system.

See if changing the screen resolution in the RDP client has any effect (in particular, changing between full screen mode and a specific resolution, and also changing the multi-monitor settings).

You can read more about this here: http://blogs.msdn.com/b/rds/archive/2013/12/16/resolution-and-scaling-level-updates-in-rdp-8-1.aspx

  • I just tested with RDP sessions at 1024x768, and disabling printers/copy-paste/etc --> nothing better Mar 16 '15 at 11:22

Given the timing of what you are seeing, the problem may coincide with the patch for CVE-2015-0079. The Microsoft bulletin relating to this vulnerability is MS15-030 and the actual patch for the problem is available here. If this patch has been installed on your systems, you might try removing it from one of them to see if this makes the problem go away.

It would not be the first MS patch to break certain RDP combinations. Have a look at this - in particular about KB2984972.

The problem MS is fixing with the patch is a potential DoS attack - usually not much of an issue in an office environment but still.

  • I tested removing KB3035017 (which is the patch relating to the vulnerability you point to) --> no change. I now remove other pathes from march 11 to see if we have any improvement. Mar 16 '15 at 22:35
  • I removed every patch from march 11, and the 5 before --> nothing better Mar 17 '15 at 1:16
  • Well it was certainly worth a try. It's really too bad when that Google guy doesn't know about things. He's usually very good about things in that respect. Another thing to look at could be time - do your workstations keep time correctly? I would imagine they do if they are part of a domain, but Kerberos is sensitive to time skew, so it might be a place to look - even if it is a bit of a stretch.
    – MrMajestyk
    Mar 17 '15 at 7:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.