At work we were running an RDS server for our customers to be able to temporarily access a piece of software whilst they were being migrated.
At any one time it could have up to 20 users accessing it - there was no separation, the one RDS server was running the licensing, broker and management.
Without any known cause, years into this server being used (almost) without a hitch, users stopped being able to connect.
After gathering some testimonies from the customers and testing, I’d isolated it to users not being able to connect if they already had a session running on the server. If you logged in from fresh, you were fine. If I logged off the user via terminal, they were fine. If you disconnect (or get kicked for being idle, in this case), and tried to RDP back in, you would get a helpfully but typically vague “Unable to connect to remote computer. If problem persists, contact your System Administrator” from mstsc.exe.
With this, on the RDS server, the connection broker complained to the event log:
802: RD Connection Broker failed to process the connection request for user DOMAIN\Username. Error: Element not found.
1296: Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker.
User : DOMAIN\Username
Error: Element not found.
1306: Remote Desktop Connection Broker Client failed to redirect the user DOMAIN\Username. Error: NULL
All the RDS configuration was correct, I had it sanity checked by a few colleagues without any input from me to see if they could spot anything but nope.
Fixing the then-broken Windows Updates and applying them did not fix it.
I removed and re-RDS-licensed the server, that also did not fix it.
I ultimately resorted to sysinternals as any sys admin should, launched Procmon and filtered for a few of the RDS services, but one caught my eye - tssdis.exe (Remote Desktop Session Broker).
It was silently erroring on HKLM:\Software\Policies\Microsoft\System\DNSClient’s key of PrimaryDNSSuffix not being found.
This was a domain-joined server, and the PrimaryDNSSuffix value should contain the DNS suffix of the domain - we could not work out why this key was missing, or when it went missing.
I recreated the key manually (for now), and tested before even restarting the RDS services - but it worked.
No services restarting or server restarting was necessary.
So to fix it ‘properly’ I found where PrimaryDNSSuffix was ‘set’:
PrimaryDNSSuffixSystemPropertiesAdvanced.exeThis populated the above Registry key, and hopefully filled out anything else needed.
RDS sessions continued to be recoverable as they should be.