RegisterLogin
Add us as preferred source on Google →
Windows Server & Virtualization

Configuring Remote Desktop Connection Broker High Availability (HA) on Windows Server RDS Farms in Pakistan: SQL Server Clustering, DNS Round Robin, and Resilient Workspaces

A comprehensive systems architecture and PowerShell automation guide for deploying highly available Remote Desktop Connection Broker clusters with SQL Server and DNS Round Robin on Windows Server RDS farms in Pakistan.

Enterprise Windows Infrastructure Desk•
Configuring Remote Desktop Connection Broker High Availability (HA) on Windows Server RDS Farms in Pakistan: SQL Server Clustering, DNS Round Robin, and Resilient Workspaces

In enterprise Windows environments, Remote Desktop Services (RDS) provides the mission-critical foundation for distributed workforces, accounting departments running ERPs like QuickBooks and SAP, financial brokerage trading desks, and Business Process Outsourcing (BPO) call centers across Karachi, Lahore, and Islamabad.[1][5] Within an RDS farm, the Remote Desktop Connection Broker (RD Connection Broker) serves as the central orchestration engine: it authenticates incoming sessions, balances connection loads across RD Session Hosts, and directs users back to their existing disconnected sessions.[1]

However, in a default single-broker deployment, the RD Connection Broker represents a catastrophic Single Point of Failure (SPOF).[1] If the physical or virtual host running the solitary broker encounters a kernel crash, hardware failure, or routine patch reboot, the entire remote workspace collapses.[1] New user connections are refused, disconnected sessions cannot be resumed, and remote workers are locked out of their desktop applications.[1]

To ensure uninterrupted operations, enterprise infrastructure architects deploy Remote Desktop Connection Broker High Availability (HA).[1] By clustering multiple RD Connection Broker nodes around a centralized, replicated Microsoft SQL Server database and establishing DNS Round Robin load balancing, organizations achieve automated active-active failover, seamless session persistence, and zero-downtime resilience.[1][2]

This technical guide delivers an end-to-end implementation runbook for designing, provisioning, and validating an RD Connection Broker High Availability cluster on Windows Server 2022 and Windows Server 2025 in Pakistan.[1][2][3]

Architectural Components of an RD Connection Broker HA Farm

An enterprise-grade, highly available RDS deployment distributes roles across distinct infrastructure layers:[1][5]

RDS Architectural Layer Primary Nodes & Roles Function in HA Architecture Failure Mitigation Mechanism
Client Access & Gateway RD Web Access / RD Gateway (rdg01, rdg02) Front-end HTTPS portal and TLS tunnel across WAN External reverse proxy or hardware load balancer distribution
Connection Broker Cluster Active-Active Broker Nodes (rdcb01, rdcb02) Session orchestration, collection routing, load distribution DNS Round Robin under a unified Client Access Name (rdcb.corp.internal)
Shared State Database Microsoft SQL Server (Always On Availability Group) Centralized storage of session states, collection mappings, and endpoints Multi-subnet automated database failover with synchronous replication
Session Host Farm RD Session Hosts (rdsh01, rdsh02, rdsh03) Hosts multi-user virtual desktops and RemoteApp applications Connection Broker redirects traffic away from drained or failed hosts
Profile Storage Centralized SMB Share (FSLogix Profile Containers) Houses VHDX profile disks dynamically mounted at logon Failover clustering or enterprise NAS with dual storage controllers

In this active-active clustering model, all configured RD Connection Brokers are fully operational simultaneously.[1] When an end-user connects through the shared DNS name (rdcb.corp.internal), DNS Round Robin routes the connection request to any available broker node.[1] The broker queries the shared SQL database, verifies whether the user possesses an existing disconnected session, and returns the appropriate session host redirection token.[1]

Phase 1: Database Preparation and Active Directory Permissions

Before configuring the brokers, you must establish a shared SQL Server database and assign the necessary Active Directory machine account permissions.[1]

1. Create an Active Directory Security Group

RD Connection Broker nodes authenticate against SQL Server using their Active Directory machine accounts (COMPUTERNAME$).[1] To simplify permission management, create a dedicated security group in Active Directory:[1]

# Create dedicated Active Directory group for Connection Brokers
New-ADGroup -Name "RDS-Connection-Brokers" -GroupScope Global -GroupCategory Security -Path "OU=Security Groups,DC=corp,DC=internal"

# Add broker computer accounts as members
Add-ADGroupMember -Identity "RDS-Connection-Brokers" -Members "RDCB01$", "RDCB02$"

2. Provision the SQL Server Database and Grant Permissions

Log in to your SQL Server instance via SQL Server Management Studio (SSMS) or SQLCMD and execute the following configuration script:[1]

-- 1. Create the dedicated RDS Broker database
CREATE DATABASE RDS_Broker_DB
ON PRIMARY 
( NAME = N'RDS_Broker_DB', FILENAME = N'D:\SQLData\RDS_Broker_DB.mdf' , SIZE = 1024MB , FILEGROWTH = 128MB )
LOG ON 
( NAME = N'RDS_Broker_DB_log', FILENAME = N'E:\SQLLogs\RDS_Broker_DB_log.ldf' , SIZE = 512MB , FILEGROWTH = 64MB );
GO

-- 2. Create SQL Server Login for the Active Directory Broker Group
CREATE LOGIN [CORP\RDS-Connection-Brokers] FROM WINDOWS;
GO

-- 3. Assign db_owner role on the RDS database
USE RDS_Broker_DB;
GO
CREATE USER [CORP\RDS-Connection-Brokers] FOR LOGIN [CORP\RDS-Connection-Brokers];
GO
ALTER ROLE db_owner ADD MEMBER [CORP\RDS-Connection-Brokers];
GO

[!NOTE] The db_owner permission on RDS_Broker_DB is mandatory. During the initial initialization phase, the active broker creates system tables, views, stored procedures, and schema constraints required to track session tokens and host loads.[1]

3. Install the Microsoft ODBC Driver on All Brokers

Each RD Connection Broker server requires the 64-bit Microsoft ODBC Driver for SQL Server (ODBC Driver 17 or 18) installed locally to communicate with the database.[1]

# Install ODBC Driver silently via PowerShell
Start-Process msiexec.exe -ArgumentList "/i C:\Installers\msodbcsql_17.10.6.1_x64.msi /quiet /qn /norestart IACCEPTMSODBCSQLLICENSETERMS=YES" -Wait

Phase 2: Configuring High Availability via PowerShell

With the database online and permissions established, configure High Availability on the initial broker server (RDCB01.corp.internal).[2]

1. Initialize High Availability on the Primary Broker

Execute the Set-RDConnectionBrokerHighAvailability cmdlet to convert the standalone deployment into an HA cluster:[2]

# Define parameters
$ActiveBroker     = "RDCB01.corp.internal"
$ClientAccessName = "rdcb.corp.internal"
$SQLServerFqdn    = "sql01.corp.internal"
$DatabaseName     = "RDS_Broker_DB"
$DbFilePath       = "D:\SQLData\RDS_Broker_DB.mdf"

# Construct SQL Server ODBC Connection String
$ConnectionString = "DRIVER=ODBC Driver 17 for SQL Server;SERVER=$SQLServerFqdn;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=$DatabaseName;"

# Configure High Availability
Set-RDConnectionBrokerHighAvailability `
    -ConnectionBroker $ActiveBroker `
    -DatabaseConnectionString $ConnectionString `
    -DatabaseFilePath $DbFilePath `
    -ClientAccessName $ClientAccessName

2. Join the Secondary Connection Broker Node

Once the primary node initializes the database schema, join the second broker node (RDCB02.corp.internal) to the cluster using Add-RDServer:[4]

# Add secondary broker to the RDS deployment
Add-RDServer `
    -Server "RDCB02.corp.internal" `
    -Role "RDS-CONNECTION-BROKER" `
    -ConnectionBroker "RDCB01.corp.internal"

3. Verify Cluster Health and State

Inspect the cluster configuration using Get-RDConnectionBrokerHighAvailability:[3]

Get-RDConnectionBrokerHighAvailability -ConnectionBroker "RDCB01.corp.internal"
ActiveManagementServer     : RDCB01.corp.internal
ConnectionBroker           : {RDCB01.corp.internal, RDCB02.corp.internal}
ClientAccessName           : rdcb.corp.internal
DatabaseConnectionString   : DRIVER=ODBC Driver 17 for SQL Server;SERVER=sql01.corp.internal;...
DatabaseSecondaryConnectionString :

The output confirms that both RDCB01 and RDCB02 participate in the active broker pool.[3]

Phase 3: Configuring DNS Round Robin Load Balancing

To distribute client routing requests evenly across all brokers, configure DNS Round Robin in your internal Windows Server DNS zone.[1]

Create multiple Host (A) records matching the designated ClientAccessName (rdcb.corp.internal), with each record resolving to an individual broker’s IP address:[1]

# Configure DNS Round Robin on the primary domain controller
Add-DnsServerResourceRecordA -ZoneName "corp.internal" -Name "rdcb" -IPv4Address "10.0.1.21" -CreatePtr
Add-DnsServerResourceRecordA -ZoneName "corp.internal" -Name "rdcb" -IPv4Address "10.0.1.22" -CreatePtr

When client workstations or RD Gateways resolve rdcb.corp.internal, the DNS server rotates the order of returned IP addresses, distributing initial connection traffic symmetrically between the two nodes.[1]

Phase 4: Failover Testing and Session Persistence Validation

To verify the fault tolerance of the HA deployment, conduct a controlled node isolation test:[1]

  1. Establish Active Sessions: Have multiple users connect to the RDS farm and launch RemoteApp applications (e.g., ERP software).
  2. Simulate Broker Outage: Stop the Remote Desktop Management Service and Remote Desktop Connection Broker service on RDCB01:[1] 
    Stop-Service -Name tssdis, Rdms -Force
  3. Initiate New Client Logins: Have additional users sign in via the RD Gateway or web feed. The DNS client resolver and gateway seamlessly fall back to RDCB02, querying the shared SQL database and routing users to their target session hosts without delay.[1]
  4. Test Disconnected Session Recovery: Disconnect an existing user session (simulate a network drop). Reconnect from the client terminal. The secondary broker queries RDS_Broker_DB, identifies the active disconnected session ID on the specific session host, and restores the user’s workspace with zero data loss.[1]

Infrastructure Imperative: Dedicated Bare-Metal Servers vs. Virtual Hypervisors in Pakistan

When architecting a high-availability RDS farm for enterprise clients in Pakistan, the physical underlying hardware tier determines uptime predictability.[1][5]

In multi-tenant, shared cloud VPS hosting, database transactions and RPC synchronization between Connection Brokers and SQL Server are vulnerable to hypervisor CPU scheduling latency.[1] When multiple virtual machines on the same host compete for disk I/O, SQL database lock contention escalates. If a broker fails to write session state tokens within timeout thresholds (RPC timeout 30 seconds), client connection requests fail, throwing The remote computer disconnected the session errors.[1]

For enterprises running mission-critical operations, deploying on high-performance infrastructure is essential.[1] By deploying unshared dedicated servers and localized dedicated servers in Pakistan, organizations secure dedicated multi-core Intel Xeon and AMD EPYC compute processors, enterprise NVMe RAID-10 storage for SQL Server transactions, and unthrottled 1Gbps / 10Gbps private network backbones with domestic latencies under 15ms across all major Pakistani cities.[1][5]

Sources & Official References
  1. Microsoft Learn. (2026). Add the RD Connection Broker Server to the Deployment and Configure High Availability. Retrieved from https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-connection-broker-cluster
  2. Microsoft Learn. (2026). Set-RDConnectionBrokerHighAvailability — RemoteDesktop PowerShell Module Reference. Retrieved from https://learn.microsoft.com/en-us/powershell/module/remotedesktop/set-rdconnectionbrokerhighavailability
  3. Microsoft Learn. (2026). Get-RDConnectionBrokerHighAvailability — RemoteDesktop PowerShell Module Reference. Retrieved from https://learn.microsoft.com/en-us/powershell/module/remotedesktop/get-rdconnectionbrokerhighavailability
  4. Microsoft Learn. (2026). Add-RDServer — Add a Server to a Remote Desktop Services Deployment. Retrieved from https://learn.microsoft.com/en-us/powershell/module/remotedesktop/add-rdserver
  5. Microsoft Learn. (2026). Welcome to Remote Desktop Services — Architecture and Component Roles. Retrieved from https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/welcome-to-rds

Eliminate Single Points of Failure with Enterprise High-Availability Hosting

Protect your corporate remote workforce, ERP applications, and call center desktops from server outages and connection lockouts. Nextgen provides enterprise-grade bare-metal dedicated servers and high-speed NVMe VPS solutions engineered for Microsoft RDS clustering, SQL Server Always On, and zero-downtime virtualization.

Explore Dedicated Servers Explore Pakistan Dedicated Servers

Disclaimer: This post is for informational and educational purposes only, accurate to the best of our knowledge at publication. It does not constitute advice. We do not guarantee accuracy or completeness and accept no liability for any decisions or losses resulting from reliance on this content.

Disclaimer: This post is for informational and educational purposes only, accurate to the best of our knowledge at publication. It does not constitute advice. We do not guarantee accuracy or completeness and accept no liability for any decisions or losses resulting from reliance on this content.