none
RDP Admin not listening on 3389 RRS feed

  • Question

  • I have just installed 2012 standard onto a Dell R420 server (Broadcom NetExtreme NICs) and cannot get it to listen on 3389 for remote administration.  So far:

    • A netstat -a shows that the server doesn't appear to be listening on 3389.
    • Remote Desktop is enabled by group policy but even if I remove the GPO and disable then re-enable remote desktop it still doesn't make any difference.
    • Windows firewall is configured off for domain networks by group policy.
    • I can ping and open the c$ share with full privs.
    • I can browse the IIS holding page on the server.

    • I cannot connect with the RDP client on Windows 7.
    • I cannot telnet to 3389 on the server (Could not open connection to the host, on port 3389).
    • The port configured in the registry is definitely 3389.

    I've searched high and low for an answer but all the ones pertaining to Server 2008/R2 aren't applicable to 2012.  I have other 2012 servers (Hyper-V guests) which do not exhibit this issue.  I also managed to get this server responding once by reinstalling, connecting RDP, joining domain, connecting RDP again however this then stopped working after applying the available Windows Updates.  Strangely, I have re-installed (including formatting the drive) and the issue has manifested straight out of the box.

    Could anyone help with advice specifically for 2012.  As much info as needed can be supplied.

    Thanks

    D

    Thursday, February 28, 2013 4:08 PM

Answers

  • OK I ended up raising this with Microsoft support and we finally got to the bottom of it.  So for anyone else looking for a fix, this might be it:

    In our group policy we had defined the following services with Automatic startup:

    Computer Configuration > Policies > Windows Settings > Security Settings > System Services

    • Remote Desktop Services UserMode Port Redirector
    • Remote Registry
    • Windows Remote Management (WS-Management)

    After un-defining these settings and running a gpupdate on the affected machines we were able to connect with RDP again.

    This was a bit of a puzzler as these services start automatically by default anyway so we weren't actually changing anything, but it look like the act of defining them somehow caused the server to stop listening.  This was a new one on the MS agent as well so the solution will likely become a support article.

    • Marked as answer by SparkDS Friday, July 25, 2014 10:41 AM
    Friday, July 25, 2014 10:41 AM

All replies

  • Are you sure you're running in the correct NLA profile for the firewall - domain rather than public?  Check this in Control Panel -> System and Security -> Windows Firewall.

    I'm working on a problem now where NLA mis-detects the domain network as "public", cutting off Remote Desktop among other things.  In my case, if the machine is set for DHCP everything works fine.  Setting a static IP address creates the wrong profile issue.

    Thursday, February 28, 2013 4:36 PM
  • Hello,

    Check that the remote desktop services is running and set to automatically start in services.msc


    Miguel Fra | Falcon IT Services, Miami, FL
    www.falconitservices.com | www.falconits.com | Blog

    Thursday, February 28, 2013 4:55 PM
  • Thanks both for your replies;

    @TJ Cornish: I was about to say it was definitely not a firewall issue (as previously it was detecting the domain correctly) but just checked and it is showing as being on an unidentified public network. Going to try setting it on DHCP with a reservation on the DHCP server if I can't find a fix for the NLA issue.  Thanks for prompting me to look properly!!

    @Miguel: Thanks, yes, the service is running and on automatic.

    D

    Edit: Didn't make any difference.  I disabled the 2nd NIC and NLA detected the network correctly.  Also tried DHCP with no change in symptoms.  Actually, thinking about this though, netstat doesn't show the server listening on 3389 anyway so I guess the problem lies before the firewall can even be a factor.  This has me completely stumped!!
    • Edited by SparkDS Thursday, February 28, 2013 8:16 PM
    Thursday, February 28, 2013 7:41 PM
  • Next update; Taking the server off the domain re-enables listening on 3389 and I can connect with the RDP client.  Next action: exclude it from group policy!

    Thursday, February 28, 2013 9:01 PM
  • Make sure you're rebooting between attempts.  I can occasionally get my machines to attach to the correct NLA profile, but a reboot returns me to the "public" profile.
    Thursday, February 28, 2013 9:18 PM
  • Update in case anyone else has this problem;

    Seems to be holding so far although I haven't put the windows updates in, and might not for now.  The things I've done so far:

    1. Disabled 2nd NIC (wasn't connected anyway)
    2. Changed the default behaviour of the default network type for unknown networks to Private (Local Security Policy)
    3. Removed from domain
    4. Updated graphics and NIC drivers (i believe this to be inconsequential as it has worked before without doing this)
    5. Re-joined to domain

    I don't know which, if any, of these steps actually fixed it and I'm not convinced that it will continue to hold. Time will tell.  If you have the same issue with 2012 and have found something more concrete than this, please update this post for future reference.

    Thursday, February 28, 2013 9:24 PM
  • I would guess that your Local Security Policy thing made the difference. I would suggest try running rsop.msc on the server in question- it will summarise all Group Policy that is being applied to your server. The whole problem sounds like a policy thing.
    Thursday, February 28, 2013 9:28 PM
  • In my case I'm pretty sure it's not.  I have had an MS pro case open on this for a while, and am at the tech lead level, with no solution so far.

    Thursday, February 28, 2013 9:30 PM
  • Bang on. I excluded it from applying the default domain policy and it survived a reboot (whereas previously after rebooting RDP would become inaccessible again).  I do have RDP enabled, and the firewall is configured in the default domain policy but not the network location location settings.

    Looks like I'm going back to my lab for some further investigation. Must be the network location defaults.

    Thanks everyone for your input.

    • Marked as answer by SparkDS Thursday, February 28, 2013 10:30 PM
    • Unmarked as answer by SparkDS Thursday, February 28, 2013 10:30 PM
    Thursday, February 28, 2013 10:29 PM
  • Out of curiosity, are you using any kind of nic teaming or VLAN trunking on the server or on the switch?  In my case, it seems that something related to trunking (possibly spanning tree) is interfering with NLA's initial check.
    Wednesday, March 6, 2013 6:30 PM
  • I just tried something - I set the Network Location Awareness service to Automatic (Delayed Start).  The machine seems to be coming up better now.  I'm not sure if there are any negative consequences to this that I haven't discovered yet.
    Wednesday, March 6, 2013 6:48 PM
  • Turns out that my issue was Spanning Tree was still in effect on my ports, which delayed connectivity until after NLA timed out.  The correct Cisco command is "spanning-tree portfast trunk".

    Wednesday, March 27, 2013 6:44 PM
  • Hi,

    Found this post while trying to find people who had the issue regarding not able to RDP to a server 2012 on a server 2008 R2 domain after applying RDP settings through GPO.  You seem to be having exactly the same issue as us.  Once the Default Domain policy is applied we cant RDP, if we deny the GPO being applied to the servers then we can RDP! Did you get any further with a fix for this?

    Thanks in advance

    Friday, June 6, 2014 9:24 AM
  • @Slide71: No, haven't yet got a solution for this.  I've opened another thread for that specific issue as I didn't think this one was relevant any longer.
    Tuesday, July 22, 2014 9:47 AM
  • OK I ended up raising this with Microsoft support and we finally got to the bottom of it.  So for anyone else looking for a fix, this might be it:

    In our group policy we had defined the following services with Automatic startup:

    Computer Configuration > Policies > Windows Settings > Security Settings > System Services

    • Remote Desktop Services UserMode Port Redirector
    • Remote Registry
    • Windows Remote Management (WS-Management)

    After un-defining these settings and running a gpupdate on the affected machines we were able to connect with RDP again.

    This was a bit of a puzzler as these services start automatically by default anyway so we weren't actually changing anything, but it look like the act of defining them somehow caused the server to stop listening.  This was a new one on the MS agent as well so the solution will likely become a support article.

    • Marked as answer by SparkDS Friday, July 25, 2014 10:41 AM
    Friday, July 25, 2014 10:41 AM
  • We ran across this same issue with Server 2012 R2. After noticing this post we changed our GPO to not-define all three services, which did fix the issue. We tested this further and were able to define Windows Remote Management (WS-Management) and Remote Registry and RDP would continue to listen on port 3389 even after multiple reboots.

    As soon as we tried to Define Remote Desktop Services UserMode Port Redirector in Group Policy then that is what seemed to have killed the device listening on port 3389. Not sure why this is the case. Very strange bug.

    Hope this additional info helps someone else.

    Tuesday, May 19, 2015 10:15 PM