Slow smartcard logon through remote desktop (RDP)

For anyone that has deployed smartcards, you have probably noticed at some point that smartcard logons are much slower than password logons. When they are done over remote desktop using local smartcard redirection, it can be horribly slow. In my testing, it appeared that whatever the ping response time was (in milliseconds divided by 100) would directly related to how many minutes it would take for me to log onto a remote machine. 200ms being 2 minutes, 800ms being 8minutes. This can cause logons to drop while they are still being processed. If you go searching for details on this problem, there doesn't seem to be much helpful information. Some suggest driver problems can be a factor, and other results may point you to some KB articles for hotfixes such as:

A smart card logon to a terminal session stops responding server that is running Windows Server 2008 and Windows Server 2008 R2
A program that requires you to use a smart card stops responding in a remote desktop connection in Windows Server 2008, in Windows Vista, in Windows 7 or in Windows Server 2008 R2
You may wait for up to 30 seconds when you use a smart card to unlock a computer that is running Windows 7 or Windows Server 2008 R2
Windows 7-based or Windows Server 2008 R2-based Remote Desktop Services server freezes when you try to log on to or log off the server by using a smart card
RDP 8 upgrade

I tried all of these, but none seemed to help. We eventually ended up going through a microsoft support case for the issue, which gave us some more suggested hotfixes to apply in this specific order (none worked):

"0x80100065" error when you call the SCardConnect function in Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012
A computer that has smart card logon enabled stops responding after you remove and then reinsert a smart card in Windows 7, Windows Vista, Windows Server 2008 or Windows Server 2008 R2
"Interactive Logon: Smart card removal behavior" Group Policy setting doesn't work as expected in Windows 7 SP1 or Windows Server 2008 R2 SP1
PIN dialog box appears unexpectedly when you open an encrypted email message after you remove and reinsert a Base CSP smart card in Windows 7 or in Windows Server 2008 R2
The screen saver grace period does not work as expected if the period exceeds 60 seconds on a computer that is running Windows 7 or Windows Server 2008 R2
Number of incorrect PIN retry attempts is less than expected after you unblock a smart card on a computer that is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2

After further debugging and log analysis, the technician told us that the redirection function happens more than 50 times during the logon, with each request being sent individually. Essentially, with all of this back and forth one by one traffic, network latency causes big impact as we had originally reported to them. This was just marked down as expected behaviour that needed to be accepted. Sadly we were left with this situation, however with some further digging around, I did find one obscure forum post for a registry value that I couldn't find documented anywhere on Microsoft (at that time). This value can be created in HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. The value is a Dword with the name LogonTimeout, and its value is in seconds. You put this value on the server end, and it will allow the connection to stay open longer during the logon process, so you don't have the connection dropping while its showing you the "welcome" screen. Otherwise you need to provide activity into the RDP connection window to reset the default timer, which I believe is 60 seconds. This activity can be mouse clicks or any other input that would go into the remote session. There is another key that you may want to adjust, which is related to timeouts in the smartcard crypto provider. More on this can be found in this article.

Can't connect to terminal services (RDP)

If you do a lot of remote management of servers, you may occasionally come across a machine that does not appear to be responding when you make a terminal services connection to it. This can be caused by configuration issues or sometimes the service has just locked up on bad connections (seen with 2003). If you remote check the services, and the terminal services service is running, you can do some digging in the registry. Here I will point out what is normal for remote desktop in remote administration mode (2 connections + 1 console). Open regedit, use the connect to network registry to access your remote machine. Expand down to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server.

Look for these keys:
Dword TSEnabled = 1
Dword TSUserEnabled = 0
Dword fDenyTSConnections = 0

Occasionally one of these may be incorrect. If you flip it to the correct value it should take effect immediately and allow you access.

As I mentioned earlier, with 2003 servers, I've noticed there are cases that RDP connections can cause problems and screw up terminal services complete. Why this happens, I'm not sure. I've seen it occur when accidentally dragging an icon and it ended up in the RDP window at certain points of the connection. Although one of the terminal services tools allows you to reset the tcp listener (or something similar to this), it doesn't work. Rebooting is the only solution to fix this problem.

Another problem you may frequently run into is too many people connected to the system. In 2008 it gives you a list and option to boot someone off. In 2003, you may see that option when logging into the console session. You can also use these two command line tools to assist with this:

qwinsta /server [name of remote machine]
rwinsta /server [name of remote machine] [session id]

These commands query the sessions and kick the specific session respectively. You can't kick someone logged in at the console though, but there are some tools that you may get to work, such as psshutdown (-o option).

This article covers only some of the problems you may come across. When terminal services (or remote desktop services role) is enabled, you may end up with other problems that have different solutions.