Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Day Twenty-Five. It's Monday morning - hopefully those of you returning from your weekends got some time to rest and relax. Only two days to go until the launch of Windows Server 2008. Today we're going to continue on from yesterday's post on Terminal Server Session Broker and look specifically at Session Broker Load Balancing. So sit back, grab your coffee or tea (or if you're like me, your bottle of water) and let's begin ...
Windows Server 2008 Session Broker provides the same cross-server session reconnection capability as Windows Server 2003 Session Directory. Windows Server 2008 Session Broker provides some additional features such as a load-balancing capability as well as the ability to gracefully "drain" servers prior to scheduled maintenance. Windows Server 2008 Session Broker can be run with Session Broker Load Balancing disabled - which would then function in a similar mode to Windows Server 2003 Session Directory.
The Session Broker Load Balancing (SBLB) in Windows Server 2008 is managed based on the number of sessions. However, SBLB does more than just count the user sessions. It also has built-in black hole protection (logon throttling) and a max-session count. SBLB has two ways to protect a server against the Black Hole effect. The first is to artificially make the server load higher during a logon to prevent a Terminal Server from being inundated by new logins. Once the logon process has finished, the server load returns to normal. The Session Broker itself can guard against the Black Hole effect by limiting the outstanding connections to the same Terminal Server. For example let us assume that the terminal servers are configured to host no more than ten concurrent user logons per server. The max-session count means that ever server in the farm has determined a maximum amount of sessions that it can host. This prevents a degraded user experience for the users already connected to a Terminal Server should other servers in the TS farm not be available. Yes, there is a trade-off here. By protecting the currently connected users' experience, other users may not be able to establish a Terminal Server session at all. However, if the administrator knows his system(s) well, then this should not be a long-term issue. The unavailability of servers in the farm should be a short-term phenomenon (hardware replacement, troubleshooting etc). The max-session limit is something that needs to be manually configured - it is not automatically calculated by Terminal Server. In fact, the max-session limit is disabled by default. This setting is not configurable via the GUI - you will need to create and set the UserSessionLimit value in the registry to the maximum number of sessions you want to allow on the server. This value would be set in the HKLM\System\CurrentControlsSet\Control\Terminal Server key.
OK, let's take a look at the Load Balancing aspect now. SBLB is generally deployed using one of two technologies - TS Load Balancing, or Network Load Balancing (NLB). In order to use the SBLB feature to load balance sessions, you must configure DNS entries - something that you do not have to do with NLB. Within the TS Farm, the IP Address for each Terminal Server must be registered to a single DNS entry for the farm. This creates the DNS Round Robin configuration. All incoming TS clients will try to connect to the first IP address for the DNS entry. If that fails, then the client tries the next address in the list and so on. This provides a measure of fault tolerance in the event that a server is unavailable. It is important to note that even though clients may connect to the first IP address initially, they are redirected to an appropriate server in the farm according to the load balancing configuration. If a server in the farm is not available or is congested, the session redirects to a server that can accept the connection. There are four basic steps that must be performed to configure a system for Load Balancing:
Let's briefly talk about Network Load Balancing (NLB). NLB is not aware of what application it is load balancing, whereas SBLB is an application level load balancing solution - it is smarter, but must be deployed with a network level load balancing solution to distribute the initial connections to the farm.The easiest network level solution to deploy is DNS Round Robin as shown above. This solution complements SBLB well - however, DNS Round Robin does not provide any sort of detection mechanism for offline servers. There can be a delay of 30 seconds if a server that is offline is picked from the DNS Round Robin list. Using some sort of NLB provides better detection of offline servers.
To recap, there are some different deployment possibilities when dealing with Load Balancing:
The last thing to briefly cover before wrapping up our two day overview of Session Broker is how to enable Session Broker Logging for troubleshooting. To enable trace logging of Session Broker, you will need to add a TraceOutputMode DWORD value to the following registry key on the Session Broker server: HKLM\System\CurrentControlSet\Services\Tssdis\Parameters. There are four different values that can be set to define the logging options:
Entries related to the following Session Broker events are added to the log file:
Also, any errors that result in event log entries are included in the log file. Unless there is a specific issue that you are troubleshooting, I highly recommend not configuring debug logging. Once the troubleshooting is completed you should set the TraceOutputMode value to 0 and restart the service.
And with that, our penultimate post in the launch series comes to an end. Tomorrow we'll wrap up our series of posts with an overview of Windows Server 2008 Terminal Services Gateway. Until next time ...
- CC Hameed
thank you very much for your sensational articles. It's a pleasure to read them.
Great article! I'm using it right now to troubleshoot a crazy issue!
I have 3 x 2008 TS clustered via NLB and Session Broker. However, whenever I login it kicks me out and asks me to login again. I do and then it goes in fine. Why do I have to login to it twice!?
You should not WHERE the logs are kept btw. ;)
The article was very enlightening
I have one question:
In a previous post it was stated that in order to have a redundant session broker, the service needs to be installed on a cluster.
And yet I found out today that the tssdis service won't start when the cluster service is started.
It exits and the log just states the following:
4444: 20:26:54 INFO: Session Broker plugin is not registered
4444: 20:26:54 Unable to find the resource with service name tssdis
When the cluster service is down, the tssdis service starts splendidly.
Also there is no documentation on how to cluster the session broker on 2008 server.
Any input would be greatly apreciated
Hi. Can you guys tell me why the TS Broker service suddenly "stops" working? We have 3 Terminal servers in our farm the terminal server broker role installed on one of the domain controllers.
It works great in a couple of weeks and the load (sessions) is evenly diveded between the 3 servers but suddently it seems like one of the servers is no longer a part of the farm and all sessions is placed on the 2 remaining servers.
The only solution i have found is to restart the server which isnt getting any sessions and restart the TS Broker service on the domain controller.
The servers all run server 2008 standard
I have looked in msdn about Win32_SessionDirectorySession class (its description is in the file
%systemroot%\system32\wbem\tssdwmi.mof file) in Windows Server 2008 DataCenter.
When I am using WMI query: SELECT * FROM Win32_SessionDirectorySession
I receive error: "80041024 Provider is not capable of the attempted operation."
In the same time queries to such classes as Win32_SessionDirectoryCluster and Win32_SessionDirectoryServer
are executing fine.
But there are some differences of the (Win32_SessionDirectoryCluster, Win32_SessionDirectoryServer) and Win32_SessionDirectorySession interface in the file tssdwmi.mof.
Maybe I need to install smth for working of Win32_SessionDirectorySession class?
TS Session Broker is installed and works with queries on the classes Win32_SessionDirectoryCluster and Win32_SessionDirectoryServer.
Have you any ideas about that?
Any help would be appreciated!
Maybe I need to install smth for working of Win32_SessionDirectorySession class.
Can we find a parser for the Session Brocker log file? Would be very helpful.
Terminal Services Session Directory logging service does not write any logfile on W2008R2.