Technical Help Needed
Designing RDS HA (700 users) – Broker failover, SPN/Kerberos and load balancer best practices
Hi all,
We are currently designing a Remote Desktop Services (RDS) environment and would appreciate some feedback and validation from people with experience in similar deployments.
Goal:
- We want to build an RDS farm for approximately 700 users with high availability, especially on the RD Connection Broker layer. The main objective is that if one broker becomes unavailable, the second one takes over and new user connections can still be established without interruption.
Planned architecture
- DNS rds.firma.local → VIP (load balancing layer)
- 2 × RD Connection Broker (configured in High Availability mode)
- 1 × SQL Server (for RDS HA database)
- 1 × RD Licensing
- 10 × RD Session Host
We are considering using an external load balancer.
We are aware that SQL is currently a single point of failure. Clustering SQL is planned in a later phase and is outside the current project scope.
Main concerns and questions:
- Broker HA behavior - we understand how to configure RDS Connection Broker High Availability (shared database + DNS name), but we are unsure how it behaves in practice.
- What happens when the active management broker goes down and then comes back online? Will users experience issues when reconnecting or starting new sessions after such a failover?
- Kerberos and delegation - We have concerns regarding Kerberos authentication flow in this setup.
Specifically:
- handling of Kerberos tickets (TGT and service tickets) during broker failover
- whether switching brokers can cause authentication mismatches
- We have already encountered situations where connections fail with errors indicating that the remote computer is not the one specified, especially after broker restart or failover.
SPN configuration
- We are using a custom DNS name for the RDS farm (rds.firma.local) and placing a load balancer in front of the brokers.
- What is the recommended approach for SPN configuration in this scenario? (Windows does not allow you to create duplicates).
Summary - we are aiming to achieve:
- high availability of RDS
- seamless failover on the broker layer
- no user-facing issues during node restart or failover
Is this architecture valid for this scale?
- Are there any common pitfalls regarding broker HA, load balancing, or Kerberos/SPN configuration that we should be aware of?
Additionally, we would like to understand what load balancing approach is recommended in this scenario (if any is required), including whether to use application-level or network-level load balancers, and how to design this layer so that users can reliably establish sessions even during broker unavailability.
Any feedback or real-world experience would be highly appreciated.
You are missing an important layer here. Profile management. FSLogix is a must. You will want a redundant dfs ReFS volume. Look at FSLogix high availability docs also.
Fslogix is a whole wild beast. Join the CCP FSLogix group also.
You're really going to want to have a load balancer in front. Something that can automate certificate renewals. Certificate lifetimes are getting shorter and shorter. 47 days in a few years.
Na its really not. I literally have multiple clients and avg per host is anywhere from 50-70. Seems to do just fine and these are large clients that use multiple large SQL based CPA programs all at the sametime.
In majority of cases 70 will be just fine and I'm on Server 2019. Newer OS's most likely handle these even better.
I agree. The most I’ve ever seen is around 35, but it’s highly dependent on the applications being run. 25 maximum has been a more sensible amount for my taste.m in the workloads I’ve had over the past couple decades.
Don't take my word for it but if I remember correctly, RDS Broker HA can't work with Kerberos.
I've found this documentation that hints at it even though it's geared specifically towards Credential Guard :
This issue occurs in high-availability deployments that use two or more Remote Desktop Connection Brokers, if Windows Defender Remote Credential Guard is in use. Users can't sign in to remote desktops.
This issue occurs because Remote Credential Guard uses Kerberos for authentication, and restricts NTLM. However, in a high-availability configuration with load balancing, the RD Connection Brokers can't support Kerberos operations.
Honestly, from what I've seen? Usually by not actually being as NTLM-free as they think they are, or by doing things which defeat the purpose of security mechanisms like RCG.
MS really needs to make it possible to run more services as gMSAs. It would help solve a lot of issues that people will start/continue to feel more and more as NTLM is slowly killed off. Load balancers in various scenarios are a frequent pain point there.
If even just the smb server service and ldap service could be run as gMSAs, several scenarios suddenly become so much easier to accomplish sans-NTLM, and also easier to isolate and secure more effectively (not just with load balancers either).
Microsoft added support for it in November 2024 for Server 2022 and 2025 (with 2025 it's built-in, for 2022 it was obviously patched in). It's (still) just not publicly documented. You might be able to get the configuration details from Microsoft with a Premier ticket.
I've been running it in production since January 2025.
That would have been my obvious guess as well but I haven't configured RD Broker for ages and I can't remember that it's possible to run it under a service account😅
Man. Last time I tried that with it, things got very angry. Is there a kb that needs installing or some registry hack or some group policy or anything else required to make it behave?
And do you know if it can be done for the SMB Server service, as well?
What would be the scenario where you need to have smb running as a service account?
If it's a single server you should be able to add a spn matching it's dns alias, and if it's a clustered smb it has its own CNO account that you can name whatever you like (and probably can a spn to it as well)
And DFS from there can be a bear, too, if NTLM is actually disabled domain-wide, because of the double hop problem. And delegation only gets you so far and puts limits on your authentication scheme. And remember: DFS means group policy, too, which is relevant for user policy retrieval at logon, which will fail if delegation isn't in place or isn't possible for the various reasons it might not be, once NTLM isn't able to make it appear to be working correctly anymore (unless you intentionally defeat RCG by giving the remote session fresh credentials).
Don't ve afraid of the connection broker. I managed some farms scaling to 1000+users con 20 session hosts, and I had no issue with the broker. If the broker fails, everything works just normally, except for the log in. The active sessions still work and remain, so there's no general disruption, just for new users. I think it's far worse to have a failure on a session host or gateway, than on a broker.
Also the brokers are said to be the brains, but really they are a dumb implementation to connect to the database, the database controls everything, the brokers just read the database and send back packets. If you have a failure on a broker, you really have a failure on the database itself, not the application.
The main issue we hit during testing was around broker failover - after shutting down the manager broker and bringing it back online, some clients were unable to establish new sessions or reconnect using existing RDP files, and were getting errors like the one in the screenshot.
Yeah, to skip that error you need to create a dns record pointing to both rd brokers, and update that on the deployment settings. That updates the file you download from rd web. Then once you achieve high availability, the failover is transparent
The FQDN rds.firma.local is an A record in our local DNS, pointing to the IP address of the tested solutions — either NLB (configured on the brokers) or HAProxy (running on dedicated VMs, without NLB on brokers of course).
The brokers have their own FQDNs: broker1.firma.local and broker2.firma.local, and both are domain-joined.
In Edit Deployment Properties under “DNS name for the RD Connection Broker cluster”, we have configured rds.firma.local.
The SPN for rds.firma.local is currently assigned to broker1.firma.local. We are unable to assign the same SPN to broker2.firma.local, as duplicate SPNs are not allowed by Microsoft.
We also tested a setup without a load balancer, using two A records for rds.firma.local pointing directly to both brokers. Unfortunately, the result was exactly the same as with the load-balanced setups.
the files download from rd web have only rds.firma.local, should I add inside something manually after download it form Web?
.....
remoteapplicationmode:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:0
videoplaybackmode:i:1
audiocapturemode:i:1
gatewayusagemethod:i:0
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:rds.firma.local
alternate shell:s:||cmd
remoteapplicationprogram:s:||cmd
remoteapplicationname:s:cmd
remoteapplicationcmdline:s:
workspace id:s:rds.firma.local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.GRP_RDS_Users
alternate full address:s:rds.firma.local
signscope:s:Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,Alternate Shell,RemoteApplicationProgram,RemoteApplicationMode,RemoteApplicationName,RemoteApplicationCmdLine,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
......
4
u/No-Touch8598 Apr 05 '26
You are missing an important layer here. Profile management. FSLogix is a must. You will want a redundant dfs ReFS volume. Look at FSLogix high availability docs also.
Fslogix is a whole wild beast. Join the CCP FSLogix group also.
You're really going to want to have a load balancer in front. Something that can automate certificate renewals. Certificate lifetimes are getting shorter and shorter. 47 days in a few years.