Deploy in a high-availability or load-balancing environment

By adhering to these guidelines, you can ensure a robust and secure high-availability or load-balancing deployment.

Key considerations

• IP allowlisting and blocklisting: These features require validation of the client IP address to ensure security and compliance, usually with the X-Forwarded-For header which needs to be enabled in Administration – Server settings – Security.

  

  
  Also include the X-Forwarded-For header in IIS logs to ensure accurate tracking of client IP addresses.
• HTTP response headers: Each server node should add a unique, non-descriptive identifier to the headers of HTTP responses. This identifier, which could be as generic as "node1" or "node2", serves to track the path of requests across different servers without disclosing sensitive server details like the fully qualified domain name (FQDN). This practice is crucial for not only mapping the request journey but also for maintaining operational security, as it limits the exposure of infrastructure details that could be exploited. Organizations focused on heightened security should consider additional precautions such as using randomized or hashed values as identifiers to further obscure server identities.
  
  This is not required for functionality, and each load balancer may have its own method for achieving it. However, identifying the server than responded to the request can be a helpful troubleshooting step.
  
  Please follow Identify the server answering on a high-availability topology for more information.

Architecture

Load balancer

• X-Forwarded-For and SSL certificates: When implementing load balancing, also account for SSL certificates and the X-Forwarded-For header.
  Utilize any load balancing technology that can add the X-Forwarded-For header via intervening proxies or devices. This header should be stripped if received from a client, and only set by your network equipment.
  Proper configuration of these elements ensures secure connections and accurate client IP tracking across multiple servers. See the key considerations above about IP allowlisting and blocklisting.
• Client affinity rules: Assigning client affinity rules ensures that when a client first connects, future requests from the same client are directed to the same web server, maintaining consistency.
• Load balancing options: If you are not using a dedicated virtual or hardware load balancer in front of the web servers, DNS load balancing can be a practical alternative. In this approach, multiple DNS records (A, AAAA, or CNAME) are configured for the same domain. When a client connects, the DNS provider selects one of these records at random to respond to.
  For example, if dvls.mycorp.com has two A records pointing to different IPs for each web server, the DNS will respond to one of these records, effectively distributing the load across the servers.
  However, DNS load balancing has limitations. Since it lacks health checks, if a server goes down, the DNS provider may still direct traffic to the offline server, resulting in failed connections. This example is explained in this DNS records Cloudflare article.

Web servers / application servers

In a typical configuration, two servers are set up with IIS, each running an instance of Devolutions Server. Key considerations include encryption, IP forwarding, SQL failover, and SSL consistency.

• Synchronizing encryption keys: Each server requires matching encryption keys to decrypt data in the shared database. After installing the first server, export its encryption keys and import them onto the second server to ensure proper decryption capabilities.

• Configuring X-Forwarded-For: Set up the X-Forwarded-For header to maintain accurate client IP information across servers. This is essential for tracking and security purposes. See the key considerations above about IP allowlisting and blocklisting.

• Configuring SQL database failover: In the Devolutions Server Console, follow the steps below for each instance of Devolutions Server.

  1. Select the Devolutions Server instance.
  2. Go to Server – Edit.

     

  3. In Database, click on Advanced settings.

     

  4. Click on More settings.

     

  5. Set the Value of the MultiSubnetFailover setting to True.

     

  6. Click Ok to save your changes and close the windows.

  This setting enables the application to connect to multiple SQL database servers in the Always On availability group,ensuring quick failover when necessary.

• Ensuring SSL certificate consistency: Since both IIS servers serve the same URL through a load balancer (unless you are using IIS ARR with a DNS round-robin or other load balancing scheme), it is crucial that all SSL certificates match and are properly served throughout the whole chain. Ensure that the load balancer and both IIS servers have matching SSL certificates to provide a secure, unified connection for clients.

Database servers

• Setting up SQL Servers in an Always On availability group: To ensure high availability, configure two Microsoft SQL Servers in an Always On availability group. This setup follows an Active → Passive model with a quorum (or "witness") to monitor server health and trigger failover if one server goes down.

• Enabling contained database mode: The Devolutions Server database needs to operate in contained mode, allowing authentication to travel with the database instead of being managed at the server level. Follow these steps to enable contained mode (can also be done using T-SQL commands):

  1. Open Microsoft SQL Server Management Studio.
  2. Right-click on the Devolutions Server database and select Properties.
  3. Go to Options and set the Containment type to Partial.

  This setting allows database users to move with the database across servers in the availability group.

• Creating contained users: With contained mode enabled on the database, you can create users that are directly tied to it.
  These can be:

  • SQL users with passwords: Created specifically within the contained database.
  • Windows users: Integrated without needing an MSSQL server login associated with the master database.

  For enhanced security, it is recommended to use Windows authentication instead of SQL users with passwords. However, keep in mind that if you use Windows users, Devolutions Server's infrastructure vault feature will not be able to manage these users, as it currently only supports SQL-authenticated users.

• Remote Desktop Manager client: When using the Remote Desktop Manager client with a Microsoft SQL Server in a high-availability (HA) setup, enable the multi-subnet failover configuration. This setting is specifically beneficial for Microsoft SQL Server HA installations and not required for Devolutions Server.
  To configure Multi-Subnet Failover in RDM:

  1. In Remote Desktop Manager, navigate to File – Data sources.
  2. Select the Microsoft SQL Server data source in the data source list, then click Edit data source.

     

  3. In the Advanced tab, click on More settings.

     

  4. Set the Value of the MultiSubnetFailover setting to True.

     

  5. Click Ok and Save to save your changes and close the windows.

  This configuration allows the Remote Desktop Manager client to handle multiple subnets, ensuring quick failover between SQL servers in a high-availability environment.

Verification process

• Email validation: Verify that any system-generated email contains the correct public URI, rather than the server's name. This can be checked using the Devolutions Server messaging feature.

  

• Login history and attempts: The LoginHistory table contains the IP address for the client, not any intervening servers. The LoginAttempts table also lists the IP address, but there are more scenarios:
  • Login failures (e.g., bad credentials)
  • Blocklisted IPs
  • IPs identified as a TOR exit node