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.


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.


Essentially you have two load balancing mechanisms competing with each other. You described the problem exactly as I see it happenening. DNS Round Robin sends an incoming connection to one server and then the Session Broker sends it to the other server causing a delay in the establishment of the session.

My suggestion is to use DNS Round Robin or Session Broker, but not both.

Personally, I would use Session Broker. I would create a single public DNS record that points to the Session Broker server and let it handle load balancing the incoming connections between TS1 and TS2.

  • 1
    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. – Frans Oct 28 '09 at 13:56
  • 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. – joeqwerty Oct 28 '09 at 14:16
  • 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! – Frans Oct 28 '09 at 14:54
  • Glad to help. Let us know how it works out for you. – joeqwerty Oct 28 '09 at 15:06
  • 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 :) – Frans Oct 28 '09 at 23:33


  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.


Maybe a little late for another sort-of-an-answer, but I'll throw it in here anyway. I also have another gotcha in my setup.

I just ran into the exact same issue, and followed the breadcrumbs of logs on all four servers (rdgw, ts01, ts02 and rdbroker). I also use self issued certificates on all servers but the RDGW and the stern warnings actually provide a means to estimating where the delay is apart from looking at logs. My scenario is as original poster that there is a massive delay on the event of a redirect. Certificate promts show that the client is quickly connected to the initial TS/redirector. If this is the TS where the session resides all is OK. If the client gets redirected connecting to the correct TS takes exactly 23 seconds. Every time!

Looking at the step by step explanation from Microsoft (http://technet.microsoft.com/en-us/library/cc772418%28WS.10%29.aspx) in step 6 the initial connection TS issues a redirect command to the client and supplies the IP-adress of the correct TS. Here lies the issue the way I see it. The initial connection through RDGW is done using the internal FQDN of the initial TS/redirector. The redirected connection is done using the internal IP address of the correct TS, not the FQDN. I can actually reproduce this delay by using the internal IP adress of the initial TS/redirector. Or any other stand alone TS in my domain and child domains. In that case I get a 23 second delay in the initial connection as well.

My view on this issue is that

  1. Redirection is done by IP address, not FQDN
  2. RDGW or client implementation has a delay issue using IP address
  3. The gotcha: RDP-client of Windows 8.1 (6.3.9600) fails to connect to the redirected server at all. No logon events are logged at the TS where the user session resides. RDP client just hangs forever trying to connect - doesn't even time out.

edit; But yeah, the "Bypass RD Gateway server for local addresses" did the trick. Kind of stupid as the returned IP address is no where near being on any local subnet on my clients. Luckily I generate RDP-files with a script for my clients so I'll be able to bypass this issue fairly easy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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