Deployment Architecture to Scale Session Manager

This article discusses different deployment architecture scenarios to scale Xton Access Manager (XTAM) utilizing multiple session manager components.

Component Architecture

XTAM contains several components. When XTAM is deployed on a single host all components are installed on the same server and they communicate between each other inside this server.

One of these components is Session Manager.

XTAM communicates with Session Manager using XTAM proprietary protocol through the port 4822.

Session Manager, in turn, communicates with remote computers using RDP, SSH, Telnet or VNC protocols depending of the remote computer.


Session Manager can be installed on a separate host than XTAM WEB application. Then XTAM can be instructed to use this Session Manager instead (or together) with the one installed on the XTAM computer.

This way, RDP (or SSH) session will be established from Session Manager server to a remote server and XTAM will communicate with Session Manager server using port 4822 (the port should be opened in Session Manager Server firewall).

This architecture is not specifically related to RDP. Any protocol will work in the same way.

Session Manager Deployment

There are two applications of this deployment:

  1. Performance optimization.
  2. XTAM can automatically load balance sessions between multiple Session Managers (there could be more than two) each time selecting one with least number of currently active sessions. This architecture also supports high availability requirement.


  3. Network isolation.
  4. XTAM could be configured to select a specific session managers group out of several configured groups (called Proximity Groups) to serve remote computers located on a specific XTAM Vault, in specified IP range or in a specific domain. For example, computers from the network 10.0.0.x/24 could be served by SERVER SM1 or SERVER SM2 (balanced) while computers from the network 10.1.1.x/24 could be served by balanced session managers SERVER SM3 or SERVER SM4.


    For the end user there will be no visible differences – the sessions will open as usual.


Practically, to support this scenario install Session Manager as an individual application on the Session Manager host. To do that, run the regular installer on this host but only select one option: Session Manager.

The installer at some point will ask about certificates. In a test environment ignore it leaving the communication channel between XTAM and Session Manager over the port 4822 insecure.

Alternatively, bring file from $XTAM_HOME folder of XTAM WEB application host.

These certificates are generated during the installation and they keep the communication channel encrypted.


After that, open the XTAM GUI, navigate to the menu Administration / Settings / Proximity Groups, edit Default Group and add a new server (host, port 4822).

Make sure that port 4822 is accessible from XTAM server.

After saving the configuration XTAM will check connection automatically displaying whether the communication channel is established (blue), failed (crossed-out) and whether it is secured (green).

Optionally, remove localhost or keep it so XTAM will load balance between localhost and an external one. Add more proximity groups for remote servers in specific IP ranges of with specific domain masks.

Each proximity group might contain multiple session managers so XTAM will load balance between them inside a group.

Using Proximity Groups with multiple session managers is the way that XTAM scales for large or busy environments.