Windows Server 2008: Session Broker Load Balancing

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 […]

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.