Slow login to load-balanced Terminal Server 2008 behind Gateway Server

Question

I have a small load-balanced (using Session Broker) Terminal Server 2008 farm behind a Gateway Server which is accessed from the Internet. The problem I have is that there is a delay of 20-30 seconds if the session broker switches the user to another server during login. I think this is related to the fact that I am forcing the security layer to be RDP rather than SSL.
alt text http://www.lytzen.name/blogimages/tsstructure.png

The background
The Gateway server has a public routeable IP addres and DNS name so it can be accessed from the Internet and all users come in via this route (the system is used to provide access to hosted applications to external customers). The actual terminal servers only have internal IP addresses. This works really well, except that with a Vista or Windows 7 client, the Remote Desktop client will negotiate with the server to use SSL for the security layer. This then exposes the auto-generated certificate that TS1 or TS2 has - but since they are internal, auto-generated certificates, the client will get a stern warning that the certificate is not valid. I can't give the servers a properly authorised certificate as the servers do not have public routeable IP address or DNS name. Instead, I am using Group Policy to force the connections to be over RDP instead of SSL.

\Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security\Require use of specific security layer for remote (RDP) connections  

The Windows 7 user now gets a much less stern warning that "the server's identity cannot be confirmed" which I can live with.
I don't have enough control over the end-user's machines to ask them to install a new root certificate either.

TS1 and TS2 are also load-balanced using the Session Broker, which is installed on the Gateway Server. I am using round-robin DNS, so the user's initial connection will go via Gateway1 to either TS1 or TS2. TS1/TS2 will then talk to the session broker and may pass the user to the other server. I.e. the user may get connected to TS2, but after talking to the session broker the user may be passed to TS1, which is where they will run their session.

When this switching of servers happens, in my setup, the screen sits with the word "Welcome" for 20-30 seconds after which it flickers, Welcome is shown again and then flashing through nthe normal login screens (i.e. "wait for user profile manager" etc). Having done some research, I think what is happening is that the user is being fully logged on to TS2 (while "Welcome" is shown) before being passed to TS1, where they are then logged in again. It is interesting that normally when you see the ""Welcome" word, the little circle to left rotates. However, it does not rotate during this delay - the screen just looks frozen.

This blog post leads me to think that this is because CredSSP is not being used, probably because I am disallowing SSL and forcing RDP.

What I have tried

• I enabled SSL again which removes the "Welcome" delay. However, it seems to introduc a new delay much earlier in the process. Specifically, when the RDP client is saying "initialising connection" - this is now much slower. Quite apart from the fact that my certificate problem precludes me using that solution without considerable difficulty.

• I tried disabling the load balancing (just remove the servers from the session broker farm) and the connections do not have any delay.

• The problem is also intermittent in the sense that it only happens when the user gets bumped from one server to another. I tested this by trying to connect directly to TS1 (via the Gateway, of course) and then checking which server I actually got connected to.

• Just to be sure, I also by-passed the round-robin DNS to see if it had any impact and it doesn't. The setup is essentially in line with MS recommendations here: TS Session Broker Load Balancing Step-by-Step Guide

• I tried changing to using a dedicated redirector. Basically, rather than using a round-robin DNS, I pointed my DNS to the Gateway server and configured it to be a dedicated redirector (disallow logons, add it to the farm). Same problem, alas.

Any ideas or suggestions gratefully received.

Solution 1

Sort-of-an-answer;

1. When we started running this setup in production the problem seemed to reduce or go away, so it looks like it only happens with a small user-load. This sort-of makes sense.

2. In the RDP client itself, on the Advanced tab under the "Connect from anywhere" settings, there is an innocous little tickbox called "Bypass RD Gateway server for local addresses", which is ticked by default. Now, in my setup, I just put "hosting" as the server name to try to connect to, so the RDP client tries to find that server locally before trying to connect through the Gateway server, causing a long delay. Simply unticking that box made it a lot faster to connect, at least the bit before you are actually connected to the Gateway server.

Solution 2

For externally accessed rdweb to gateway, use a cert that has external dns registered and internal friendly names. That way it can be used on both the gateway server and the terminal servers in the farm. in my scenario, we have rdweb registerd external address, to gateway. which then points to connection broker. internal access is via internally registered dns alias xyzrdweb this is registered to both terminal servers in the farm, in effect using xyzrdweb brings back which ever record is retreived first via dns. Internal users bypass the gateway. Unfortunately external users in this scenario have an initial slow connection up to 1 1/2 minutes before fully authenticated, but once fully authenticated the applications run instantaneously, with apps such as adobe photoshop etc taking about 3 - 4 seconds to start.

Comments

[We Are All Monica]

Thanks, but that is the way MS recommends you to set it up :); technet.microsoft.com/en-us/library/cc772418%28WS.10%29.aspx‌​. I did test it without the round-robin and it makes no difference, the problem is when one server parses you to the other. Updating the question to clarify.

[joeqwerty]

I've read the article before. It's not a requirement that you use a network layer load balancer with the Session Broker. what I was suggesting is that you set up your "farm" following the "dedicated redirectors scenario", except in your case you'd be using just one redirector. If all incoming connections go to the Session Broker server the Session Broker server should send the incoming connection to the least loaded server thus avoiding the flopping from one server to another. If you say you tried it and it doesn't work then I don't have any other suggestions for you. Sorry.

[We Are All Monica]

I see what you mean, about using the dedicated redirector. I did consider it but haven't tried that particular setup. I'll give it a whirl - thanks for the suggestion!

[joeqwerty]

Glad to help. Let us know how it works out for you.

[We Are All Monica]

Hi Joe, Thanks again for the help. Alas, I have now tried to set it up with a dedicated redirector (the Gateway server) and the same problem happens. All very odd :)

[joeqwerty]

Maybe try logging directly on to each server one at a time to rule out any one server as the cause of the problem.