The security device (smart card) could not be used. Additional details may be available in the system event log. Please report this error to your administrator.

When trying to remote desktop into a 2012R2 server with a smart card, you may run across one of these messages:

[virtual smartcard]
"The security device could not be used. Additional details may be available in the system event log. Please report this error to your administrator."

[physical card]
"This smart card could not be used. Additional details may be available in the system even log. Please report this error to your administrator."

I ran into this sporadically on a range of machines after a 2012R2 rollout. In the event logs on the systems, a variety of smartcard logon event id 5 messages:

1) An error occurred while retrieving a digital certificate from the inserted smart card. The handle is invalid.
2) An error occurred while decrypting a message: The handle is invalid.
3) An error occurred while retrieving some provider parameter: The handle is invalid.

All having "The handle is invalid" as part of the error. After opening a case with microsoft and doing some low level tracing of the logons, they found a timeout in the smartcard crypto provider. The default for this is 1.5 seconds. After adjusting it to 5 or more seconds, the errors went away.

This is configured at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Smart Card Crypto Provider\TransactionTimeoutMilliseconds as a DWORD. A reboot is required for this to take effect. The key can be used on other OS's as well.

I did continue to have problems with at least one machine after this, however the errors were different and quite varied. This system was on a bad network working with highly variable response times and 10% packet loss. On this same type of link, 2008R2 was more reliable for smartcard logons in comparison to 2012R2. So its always good to have some password logon backups to smartcard logons over slow links.

Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer

I had an issue with a server that was failing to connect over RDP with the following error:

Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer

On inspecting the machine via PSremoting, the clock time showed fine. I thought I would try connecting to RDP using the IP address. That let me through with only the normal certificate mismatch warning prompt. Looking around for solutions online usually pointed to the obvious clock problem in the error message. But again, clock time was perfectly in sync and timezone was fine as well. Another possibility given in some people's posts on this topic is the RDP certificate itself. This is located in the computer's certificate store under remote desktop\Certificates. This is automatically generated by the machine and will be recreated if deleted. I checked that, and again no issue with the certificate dates.

After digging around in the registry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, I found a discrepency between this machine and another working machine. My broken machine [freshly build] had the Security value set, while the other didn't. (https://support.microsoft.com/en-us/kb/259129) Additionally this didn't match the defaultsecurity value one level up. After deleting the value and rebooting, the issue went away. Trying to reproduce the problem by putting the same value back in place only gave me the error once, then continued to let me through. So this may be something to look at if all else fails.

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.