Hello,
This is my first post, and it's more of a "this is what worked for us and I couldn't find this fix ANYWHERE" thing.
We have recently setup a new RDS environment to replace a pathetic wheezing old TS system.
We are running 9 session host servers in three pools hosting three collections - A, B and C. All the session host servers appear in the pools, accept new connections, and apps are configured and working. No problems here.
We have 2 web front end servers in our DMZ, Port 443 is open, things work fine.
We have 2 gateway servers, also in our DMZ in a gateway farm. Work great, no problem. Connectivity is excellent, internal firewalls on but the necessary configuration has been done so everything is talking and happy.
We have two connection broker servers in a high availability configuration and a different namespace for the front end than the domain (we can't use our internal domain name for our externally facing RDS farm).
However, we would get intermittent failures upon logging in, no matter what collection we were accessing.The web servers present the login page and we could successfully authenticate (using ADFS proxies in our DMZ back into the domain) against AD - I verified
this in the logs on the broker servers. The user would still fail to connect to the remote computer. The error we received was a generic "unable to connect to remote computer. If problem persists, contact your System Administrator" and the connection
broker would record the following 3 alerts:
Event 802: RD Connection Broker failed to process the connection request for user domain\username. Error: Element not found.
Event 1296: Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker.
User : domain\username
Error: Element not found.
Event 1306: Remote Desktop Connection Broker Client failed to redirect the user domain\username. Error: NULL
The user can try again, but the same error would likely be thrown, although sometimes they can log in and connect.
I googled constantly. Some had success modifying GPO Default Domain Policy: Computer Configuration / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host / RD Connection Broker / Use RD Connection Broker load
balancing - ENABLED. Didn't help; backed it out.
Others had success modifying a registry key on the broker servers: HKLM – System – Current Control Set – Control – Terminal Server – WinStations – RDP-TCP – Security Layer changed from 1 to 0.I didn't like doing this (not fully aware of the security "feature(s)"
this disabled). Made no difference - backed it out.
Deleting and recreating collections did not help. Tried adding the server farm to the "Windows Authorization Access Group" (really only helpful for systems that began as Win 2k boxes). No go.
Put in a call with Microsoft. They give me a hotfix (which makes me a bit dubious - I didn't install it), and about 7 patches to run (which had been - our servers were up to date). I wasn't feeling it.
So I fired up procmon and monitored tssdis.exe on the broker servers. According to procmon, everything was a success - except for two keys missing from the registry on both broker servers: HKLM\Software\Policies\Microsoft\System\DNSClient. Procmon showed
that key could not be read. Googling was useless, so I decided to manually create the key. Failed - procmon showed the key name as "New Key #1" no matter what I called it. Deleted it and used the following powershell command to successfully create
the key: New-Item -Path HKLM:\Software\Policies\Microsoft\System -Name DNSclient -Value "Default Value"
The key was created. YAY! I still didn't know what needed going in there, it was just an empty key. I ran procmon again, and got a clue: tssids was trying to read a value: "PrimaryDNSSuffix" and returning blank. OK - inside of the "DNSclients"
new key I created a new string value containing our internal domain name, doing this on both connection broker clients. The end result looked like this:
HKLM:\Software\Policies\Microsoft\System\DNSClient - "PrimarydnsSuffix" "yourdomainname.com"
INSTANTLY, everyone connected. I could access everything using my acct and my testing accounts. The errors cleared up in the event logs. The sun began shining and the IT gods were, for awhile, placated.
OK - if you are getting 802, 1296, and 1306 errors in RDS 2012 R2 - before lessening security, and before modifying global GPO settings, just check procmon against tssdis.exe on the broker service and see if that key is missing. It's the only thing that
worked for us.