Remote Desktop Services, formerly known as Terminal Services, is a technology from Microsoft that allows users to remotely access a session-based desktop, virtual machine-based desktop, or applications hosted in a data center from their corporate network or from the internet.

Multiple RDS servers can be used in a farm. Hence we need to balance the load against them.

There are different ways to achieve this:

  1. using a connection broker

  2. using a load-balancer with the connection broker

  3. using a load-balancer without the connection broker

Of course, our load balancer of choice is HAProxy. In this blog article, we’re going to focus only on the case where a load balancer is used.

The main issue when load balancing multiple Remote Desktop Services servers is ensuring a user has the continuity of his session in case of a network outage. The current article will focus on session high availability for an optimal end-user experience.

HAProxy With a Connection Broker

The connection broker, formerly known as the Session broker, has the main purpose to reconnect a user to his existing session. Since Windows 2008, the connection broker also has had some load balancing mechanisms.

Why Use a Load Balancer if the Connection Broker Can Load Balance?

The answer is simple: security. Since HAProxy is a reverse-proxy, it breaks the TCP connection between the client and the server. HAProxy can be deployed in DMZ to give access to users coming from the internet to an RDS farm deployed in the VLAN dedicated to servers.

Similar Articles:

HAProxy Configuration

Note: this configuration works for Aloha 6.0 and above and HAProxy Enterprise 1.5 and above.

frontend ft_rdp
  mode tcp
  bind 192.168.13.128:3389 name rdp
  timeout client 1h
  log global
  option tcplog
  tcp-request inspect-delay 2s
  tcp-request content accept if RDP_COOKIE
  default_backend bk_rdp

backend bk_rdp
  mode tcp
  balance leastconn
  persist rdp-cookie
  timeout server 1h
  timeout connect 4s
  log global
  option tcplog
  option tcp-check
  tcp-check connect port 3389 ssl
  default-server inter 3s rise 2 fall 3
  server srv01 192.168.13.13:3389 weight 10 check
  server srv02 192.168.13.14:3389 weight 10 check

HAProxy Without a Connection Broker

HAProxy can be used on its own to perform session load balancing and resumption. For this purpose, it needs a stick table where the user-server association is stored. A peers section is added to the configuration. So we can share session persistence information between a cluster of Alohas or HAProxy Enterprise servers.

peers aloha
 peer aloha1 192.168.13.1:1023
 peer aloha2 192.168.13.2:1023

frontend ft_rdp
  mode tcp
  bind 192.168.13.128:3389 name rdp
  timeout client 1h
  log global
  option tcplog
  tcp-request inspect-delay 2s
  tcp-request content accept if RDP_COOKIE
  default_backend bk_rdp

backend bk_rdp
  mode tcp
  balance leastconn
  timeout server 1h
  timeout connect 4s
  log global
  option tcplog
  stick-table type string len 32 size 10k expire 8h peers aloha
  stick on rdp_cookie(mstshash)
  option tcp-check
  tcp-check connect port 3389 ssl
  default-server inter 3s rise 2 fall 3
  server srv01 192.168.13.13:3389 weight 10 check
  server srv02 192.168.13.14:3389 weight 10 check

To know the user-server association, we can simply read the content of the stick-table:

echo show table bk_rdp | socat /var/run/haproxy.stat -
# table: bk_rdp, type: string, size:10240, used:5
0x21c7eac: key=Administrator use=0 exp=83332288 server_id=1
0x21c7eac: key=test-001 use=0 exp=83332288 server_id=2

We can easily read the login used by the user, the expiration date (in milliseconds), and the server ID used for the session.

Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.