A couple months ago I deployed a Windows Server 2012 R2, with the intent of using RDS Gateway on it for a client. I got it working, but there is a 60 second delay during the login process to the RDS Gateway. Specifically, the RDP client hangs on "Configuring Remote Session." This happens 100% of the time from outside the network (but never when connecting to the same server on port 3389 from *inside* the same network that the server is on). It is also important to know that even though there is always a 60 second delay, it still connects successfully 100% of the time. The client is not happy with the 60 second delay though (understandably), and has asked me to to solve the problem. I have done a ton of research, but the few possible solutions I came up with ended up not solving the problem. Here is everything I have done so far:
-My problem is *most* similar to this other post: http://social.msdn.microsoft.com/Forums/en-US/20a68eec-d639-47f7-abd1-3ae10aaf4db8/remote-desktop-to-web-role-gets-stuck-on-configuring-remote-connection However, the problem in that case eventually resolved on its own, & I have already tried the only suggestion mentioned in that thread (disabling port re-direction).....either I did that improperly, or it did not help).
-100% of the time immediately after a 60 delay login, I get this warning in the server's event log:
| SERVERNAME | 20499 | Warning | Microsoft-Windows-TerminalServices-RemoteConnectionManager | Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin |
"Remote Desktop Services has taken too long to load the user configuration from server \\servername.domainname.local for user XXXXXX" (where XXXXXX is an actual username).
The only recommendation I can find after researching *that* warning message is a small registry edit, which I have tried, and it did not help.
-In my research, I came across someone's theory that the problem is related to the SSL certificate, & the fact that the internal domain has a .local extension (which mine does). According to this theory, Microsoft's RDS Gateway (unfortunately) exposes the RDS Session host's computer name (including its .local extension) to the remote/external RDP client, and therefore the 60 second delay is caused by the remote/external RDP client taking time to look for the SSL certificate for the session host, which doesn't exist. The only way to determine whether this theory is the actual cause of the 60 second delay, or not, is to actually purchase a UC Certificate, which supports multiple domain names. There is an additional problem with testing this theory however, in that ICANN has mandated that certificates will no longer support .local (and similar) domain extensions come November, 2015. Therefore, even if I go through all the work to purchase & install the UC Certificate, *and* it happens to solve this 60 second login delay problem (which is a big "if"), that solution would only work for 1.5 more years from now.
I hope you can see I have tried hard to solve this problem on my own, but I am unable to. I really need some outside perspective to cut through the troubleshooting fog in my head regarding this particular problem. It is for that reason that any assistance with this problem would be greatly appreciated! Thank you in advance!