• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3367
  • Last Modified:

Terminal Server Farm Connections

I have a 2008 Terminal Server FARM that works great, but I have two issues I'd like to throw out there.

1. Users are reporting double logins since the FARM was implemented.  They literally will enter credentials, probably get moved to the other server, and have to enter credentials again.  No errors.

2. One of my Terminal Servers in the FARM is not quite as beefy as the others.  Can anyone explain the session broker weight settings to me in plain english?  If I want to make sure for instance that his particular Terminal Server never gets more that X connections, how would I do so?  I would still obviously need to be able to get in with a /admin console session.  

Thanks Everyone!
  • 3
  • 2
4 Solutions

regarding your first problem - what type of clients are connecting to the farm (domain vs non-domain, Windows or non-Windows, RDP versions allowed)?

Regarding the maximum nuber of sessions on a specific machine you would have to set a UserSessionLimit parameter in the HKLM\System\CurrentControlsSet\Control\Terminal Server registry key on your "not so beefy" terminal server.

When this parameter is set to a value other than 0 the TS will deny logon to new sessions after the number of sessions on the server reaches the value set in registry. However, this will still allow the administrator to logon to the console - either directly or using the /admin switch (works through TS gateway too). Another thing to know is that the console session even when established through RDP isn't counted into active sessions when checking new connections against UserSessionLimit parameter.

What I can suggest regarding setting up, tuning and tweaking the session broker is a few really nice articles on ThinComputing and TechNet:
- A closer look at Session Broker load balancing in Windows Server 2008
- Terminal Server Session Broker
- WS2008: Terminal Server Session Broker Overview
- WS2008: Session Broker Load Balancing

The idea behind the weight parameter is that it's a relative parameter describing the share of farm sessions that a single server can take. I'll give you an example with 3 scenarios.

Let's say you have a farm with 3 servers - TS1, TS2 and TS3. Let's say that resources on TS1 and TS2 are about the same and that resources on TS3 are "not so beefy" :)

Scenario 1 - the resources on TS3 are twice as bad as on TS1 and TS2 but the total number of sessions that might connect to the farm is lower than what servers are able to handle.

In this scenario, you could set up relative weights as below:

TS1 = 100
TS2 = 100
TS3 = 50


TS1 = 200
TS2 = 200
TS3 = 100

Both of these configurations actually determine that servers TS1 and TS2 will each get twice as many sessions as TS3 at any given time. You may wonder why I posted two options. Since the default setting is 100 for any new server it means that in first option you would only have to reconfigure TS3, and in the second option you would have to reconfigure both TS1 and TS2.

Basically I suggest that you leave the setting of 100 on configuration that could be described as your "standard farm server". That way you won't have to reconfigure the setting for most new servers added, but only those better or worse than standard.

Scenario 2 - the resources on TS3 are twice as bad as on TS1 and TS2 but the total number of sessions that might connect to the farm is higher than what servers are able to handle.

The relative weight should be set as in scenario 1. However, you should also set the UserSessionLimit on each server to the maximum number of sessions that server can handle without major degradation of performance.

After you post the answers regarding clients I'll try to give you pointers on double login problem too.


tarkmylerAuthor Commented:

Wow, this is the most complete answer I've gotten from Experts Exchange yet.  Thanks for the detail.  I really appreciate it.  The Terminal Server in question has been in drain mode since this post and I have finally gotten around to reading your post and making the configuration changes.  It's only a 2 server environment so I will go ahead and configure the slower box with a value of 50 and see how it goes.

Most of the clients that connect are doing so from domain joined machines.  Its almost like they connect and authenticate with the server that has the "highest load" and just before they log in are directed to the other server by session broker load balancing.  They then get another login prompt..  Strange.  There are a few thin cliennts out there that seem to do the same thing.  Obviously these are not joined to the domain and just serve up the RDP client funciton.

As far as the registry change to limit the number of connections...  I have one question.  Say that a user is connecting the the farm, and is directed to this server by session broker because it just happened to work out that the servers weight and availability dictate that it should..  If I have a hard coded limit in the registry, will session broker know and not push the user over to that server?  Or will the user get forced over there and get the login error?  Hope I asked this clear enough.  Have a great thanksgiving and let me know if you want me to clear any of this up.

Adam Tyler
Resource One, Inc.

sorry for the delay.

Let me answer your second question first, the one regarding the registry setting - you are safe there. If a RDS host (terminal server) is a member of a load balanced farm then it will inform the session broker that it can't accept any more sessions in any scenario - even if it happens to be the redirector (or the server that the farm name resolves to in DNS query and as a consequence the first server that client tries to connect to).

Regarding the double login bit there may be many causes but I'll try to cover some basic possibilities. It's important to understand what happens when RDP client accesses load balanced RDS farm (or TS farm, I'm using the new terminology).

The operational log of TS Session Broker in the Event Viewer nicely shows all the steps of "handshake" between the client, redirector, session broker and target RDS host so look there for better insight and troubleshooting.

If you've read the articles I've hyperlinked above then you are aware that:
1) at least one authentication takes place and this is in scenario when the first RDS host (terminal server) that client connects to as a result of DNS resolution of farm name (so called redirector) happens to be the server chosen by session broker to service the session,
2) a least two authentications take place if server other than redirector is chosen by session broker to service the session.

And by authentication - I don't mean user logins (user entering credentials). I just mean RDS host checking the credentils supplied to it in some way (even by directly setting them in RDS host configuration).

RDS hosts in a farm may be set to always prompt users for credentials on connection (this can be set in Always prompt for password field on Log on Settings tab of connection properties in RDS Host Configuration administrative tool on each host, or through group policy by enabling the Always prompt for password upon connection policy in Computer configuration > Policy > Administrative Templates > Windows components > Remote desktop services > Remote desktop session host > Security).

If this is the case then the only scenario in which user doesn't get prompted for credentials twice is when the redirector gets chosen as a host by sesion broker (I won't consider setting fixed login credentials for all users in server configuration). If a different server gets chosen by session broker and that server is set to always request the password - there's a double login. So if you have clients with RDP6.0 and above with double login problem (and you haven't tampered with client RDP files or other RDS GP settings) then you should check the above settings.

Even if the above settings are OK (meaning RDS hosts aren't set to always prompt for password) you may still get double logins if the session broker doesn't assign the connection to redirector (the first RDS host that client contacted):
1) When using RDP clients supporting only RDP protocol versions lower than 6.0 (or up to 5.2).
2) When using RDP clients supporting RDP protocol versions 6.0 and above but setting RDP connection parameters (through server settings or directly in RDP file) to disable credential prompt on the client prior to any connection is attempted with the farm.

The first situation usually happens when using thin clients, non-Windows clients or Windows clients older than XP SP3. But none of these situations is a "showstopper". The trick is to somehow force the RDP client to collect and send user credentials to RDS farm. With Windows CE based thin clients or non-Windows this can be solved by writing a simple wrapper around RDP client that collects user credentials and then calls RDP client with credentials as parameters. Furthermore, some thin clients already have wrappers developed by thin client manufacturer and deployed as standard app on the TC (e.g. HP thin clients have such RDP/ICA wrappers built in). The same could be done for Windows based computers and if OS on those is XP the best way is to upgrade to SP3. More savvy users can even use Edit instead of Open on RDP client file and enter credentials on General tab before clicking Connect button.

And when client computers run RDP client supporting RDP6.0 and above then it's enough to check in the settings that user credentials are collected by the client before connection attempt (this can be set in group policy too) and make corrections if not so.

If all this is checked and corrected (you may ping me here if you need more detailed instructions on particular step) and the problem still persists then there may be issues with authentication mechanisms, possibly name resolution or certificates but in that case I don't think I'll be able to help without loads of logs posted here or direct connection to your machines and much more time (which I probably won't have).

Hope this helps you out.


I forgot to mention that if you have an option to set up a dedicated redirector in your farm (a RDS host that doesn't service any sessions itself but is the only server initially contacted by RDP clients - single mapping to farm name in DNS) you may set it to either use fixed credentials (less secure option) or set it up to accept saved client credentials. At the same time if you save usernames/passwords in all clients, and force all other RDS hosts in the farm to always prompt for password you should get a single log on.

However, I don't recommend this solution because of administrative overhead on the clients and low redundancy because your redirector becomes the new SPOF (single point of failure) just like your session broker is in case it isn't clustered.

tarkmylerAuthor Commented:
Didn't get to test this out and see if it resolved the double login issue, but it is allot of great information!

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now