I have a Citrix Delivery Controller (DDC) and a Server VDA (SVDA) in my lab, as part of my XenApp 7.11 environment. Both servers are 2012 R2 servers. I have Terminal Services role enabled by default on my SVDA because when you install Citrix software (Virtual deliver Agent or VDA) on a Server 2008 R2 or 2012 R2, the Terminal Services (TS) role is automatically installed, since it is a pre-requisite for the VDA. The DDC doesn’t have the Terminal Services Role installed by default (unless you install the VDA software on it, which is not considered Best Practices by Citrix), but Microsoft allows two RDP connections to a Server even if the Terminal Services role is not installed. Of course it is limited to local or domain administrators. One of the reasons this is possible is to allow either the local admin or the domain admin to install the full blown Terminal Services role if needed. Recently, I have been unable to RDP into the DDC but had no problems RDP-“ing” to my SVDA.
After checking firewal settings and making sure they were disabled, I tried tel-netting via port 3389 from my SVDA to my DDC and was unable to do so. However, I was able to telnet from another server to my SVDA via port 3389. So I suspected that my RDP listener on the DDC had an issue.
Sure enough, I compared the RDP listener registry key settings between the SVDA and the DDC. On my DDC there were a few binary values that did not match my SVDA. Obviously some of the values should be different since one server has the TS role installed (SVDA) and the other (DDC) doesn’t, but the vast majority of the binary values on the RDP listener registry key should be quite similar on both 2012 R2 servers. The registry key for the RDP listener is located here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
These two keys particularly intrigued me:
fDisableExe -> set to 1 on the working SVDA but set to 0 (zero) on the non-working DDC
User Authentication – set to 1 on the working SVDA but set to 0 (Zero) on the non-working DDC
I changed both flags to 1 on the non-working DDC, to mimic the SVDA and VOILÁ, the RDP connection started to work again, MAGICALLY!
Note 1: After changing the two binary values on the registry, I rebooted the DDC for the changes to take effect.
Note 2: I did not test the behavior by only changing one binary value entry due to my own laziness, so it is quite possible that only one binary value change could have done the trick as well. If I were to guess I suspect the User authentication binary value could be the one, but that is only my guess!
Microsoft installs the RDP listener on all Windows machines by default when the Windows software is installed on a computer. This is for management purposes in case you want to manage the computer remotely.
So you should be able to see RDP listener registry key on all Windows computers regardless of being a Server or Desktop OS. The RDP listener is not a very popular component and most end users don’t really know much about this component or that it even exists (unless you are an IT administrator). However, when corrupted, modified or customized, it will cause disruptions to a remote connection to the computer, like the disruption I had, so beware!
The only mysteries I did not solve was
- How the binary values changed on the DDC (since I’ve never touched that registry key myself before)?, or
- If it did not change (which is quite possible as well) what triggered the issue then? and
- What roles do those two binary values (User Authentication andfDisableExe) have?
- Why did I decide to choose those two binary values since there were other values that also did not match. Was it my gut, my instinct? or pure luck? or would any value change do it?
These are all answers to be discussed and hypothesis that could be tested and discussed on another blog article . If you know the answer please share!
This is a good command to test if the RDP protocol is listening on port 3389, the default RDP port:
Telnet [hostname or ip address or FQDN] 3389 – If you get as an answer the cursor blinking on the top left of the CMD prompt screen, that is a good thing. That means the connection to that computer via RDP is enabled and the RDP protocol is listening on that port. If you get an message: “Connecting to [hostname]…could not open connection to the host, on port 3389: Connect failed” it really means that port 3389 is not opened on the destination host name
During my troubleshooting, telnetting within the server itself it worked (telnet localhost 3389) but it failed from any other computer telnetting into the DDC
Some IT shops change the default port of RDP from 3389 to another number to prevent end users from accessing the computer remotely or to prevent intrusions
I hope this helps!
*** === ***
used when something is being presented or shown to someone
- “Voilà!” said the magician as he pulled a rabbit from the hat.
- Add a little oil and vinegar to the lettuce, and voilà—you have an easy salad. (source Merrian Webster dictionary)