What is the RDP Cookie algorithm?

Short answer

On an L7 TCP vService, RDP Cookie selects a server by hashing the value of the cookie in the first packet of the RDP connection; this way, the same user goes to the same RDP server on every connection and can reconnect to a dropped session. The algorithm is self-persistent; a separate Persistence setting is not required. The name of the cookie to be read is written in the required RDP Cookie Name field (mstshash for Microsoft RDP clients); if the cookie is not found, the connection is distributed to the servers in turn.

How Does It Work?

1. If a user name has been entered, the Microsoft RDP client sends a line in the format Cookie: mstshash=user in the first packet of the connection.
2. TR7 reads and hashes the value of the cookie specified in the RDP Cookie Name field (the cookie name is not case-sensitive).
3. The hash result is mapped to a server taking the Weight values of the Backend Services into account; the same value goes to the same server.
4. If there is no cookie (e.g. the client did not send it), the connection is distributed with Round Robin and there is no persistence for that connection.

In TR7

• Location: L7 TCP vService → Details → LB Algorithm → Algorithm → RDP Cookie (Self-persistent).
• RDP cookie name: It is a required field and has no default value; mstshash is written for Microsoft RDP clients.
• Hash consistency: It is the switch that appears in the same box (off by default); when it is turned on, most users stay on their own server when servers are added and removed, and no server receives more than 1.5 times the average load (What does the Hash Consistency option do in hash-based algorithms?).
• L7 TCP only: This algorithm does not exist on HTTP and Network vServices.
• Also used as a condition: The RDP cookie can be checked in Conditional Backend Services or in actions with the RDP Cookie condition.
• Monitoring: The Load Balancer Management screen of the vService states that the algorithm pins the client to a server by itself.

RDP Cookie Algorithm or Hash Persistence?

	RDP Cookie algorithm	Persistence → Hash (Hash key: RDP cookie)
Server selection	Determined by the cookie hash	Determined by the algorithm selected on the first connection
Mapping	Recalculated on every connection; no table is kept	Kept in a device-specific mapping table in TR7
Duration of persistence	As long as the cookie value stays the same; if the number of running servers changes, some of the users change place (fewer if Hash consistency is on)	The record in the table is deleted if no request arrives during the Hash Key Expire Time (default 7 days); in addition, the table is reset each time the vService configuration is reloaded

The docs recommend this algorithm for RDP persistence (L7 TCP · Persistence).

Common Misconceptions

• "RDP Cookie replaces the Remote Desktop Session Broker." TR7 selects a server only by the cookie value; it does not know on which server the sessions are open.
• "I can leave the cookie name empty." RDP Cookie Name is required.
• "All clients send a cookie." The connections of clients that do not send a cookie are distributed in turn and have no persistence.
• "It is also used on a Network vService." It exists only on L7 TCP.

How it is done in the documentation

• L7 TCP vService · RDP Cookie
• L7 TCP vService · Algorithms
• L7 TCP vService · Session Persistence
• Conditions · RDP Cookie

Related questions

• Can I load balance an RDP server farm?
• What do the entries marked "(Self-persistent)" in the algorithm list mean?
• Which persistence options are available for an L7 TCP vService?