If you’ve ever had to join a XenApp server(s) to your farm across a WAN link, you’ve probably experienced the frustration of waiting a long time for the server’s IMA service to start and come online. Depending on the speed or latency of the WAN link, joining a new server to the farm could take up to 10 minutes, sometimes longer!  As a result, administrators might turn to configuring SQL data store replication at each remote site to allow for member servers to point to their local SQL subscriber and avoid the sluggishness of traversing over the WAN. However, as your farm geographically expands, the overhead of administering SQL subscribers at each of your sites quickly becomes a burden.

XenApp 6.5 introduces the Dynamic Data Center Provisioning feature that allows XenApp servers to join a farm in significantly less time with substantial bandwidth savings. In XenApp 6.5, servers can be configured in Session-host mode (also known as Session-only mode). Default XenApp servers (or Controllers) are similar to XenApp servers as we know today, whereas Session-only XenApp servers run in a light-weight mode whose sole function is to host XenApp sessions and nothing more. As I explain in this series of blogs, deploying a farm with this model makes the addition of new servers a quick and easy process, regardless of their geographic location.

How it works
When a XenApp server joins a farm, it performs numerous read and write operations to the IMA data store as well as a download of the farm data to its Local Host Cache (LHC). In previous releases of XenApp, all member servers of the farm were required to download all farm data to their LHC during a join, resulting in an excess amount of data store transactions and bandwidth consumption. In XenApp 6.5, a select few servers are dedicated as XenApp Controllers which are responsible for farm management tasks, while the remaining member servers are Session-only servers whose sole task is to host user sessions. XenApp Controllers need to sync all of the farm data while Session-only servers only need to sync a subset of the information to their LHC. These changes result in fewer database transactions, less bandwidth consumption, and faster IMA startup performance.

Session-only XenApp servers are limited in what functionality they can provide. While these servers can host XenApp user sessions, they cannot perform the role of data collectors, nor can they participate in or trigger a data collector zone election. The XML service does not run on Session-only XenApp servers, therefore they cannot be used by Web Interface to perform application enumerations. Additionally, any management tasks such as AppCenter discovery or Powershell tasks can not be run directly on a Session-only server. However, with proper planning and placement of XenApp Controller servers, leveraging the Session-only model can optimize your farm performance and reduce IMA bandwidth and server provisioning time.

The configuration of the XenApp server mode is done through the Server Role Manager at the time of joining a farm. In order to switch a server mode from Session-only mode to Controller or vice versa, the server must disjoin and rejoin the farm.

The table below shows the functionality of the Controller vs. Session-only roles.

Session-Host Mode support

 

Check out Part Two of this blog where I show you enterprise design considerations when deploying XenApp 6.5 using the Session-only model.