locked
Remote Desktop Connection Fails on Some Computers and Not others RRS feed

  • Question

  • This is a Windows 7 Professional 64-bit operating system issue.  Remote desktop is turned on for all Windows Professional computers on the domain.  Firewall (Windows) is set for allowing Remote Desktop connections.  Antivirus firewall set to allow everything.  Group policy set to allow RDC connection through firewall at the domain level) and we have verified the policy is applying properly.  Checked registry setting fdenyTSConnections in registry on remote machines to ensure connections are enabled - it is set to zero (0).  Computers are all joined to the domain and are recognized in active directory as domain computers.

    Computer browser works and I can access machines using computer browser.  Can access machines and view printers from the Network section of Windows Explorer.  Can run mmc and access all components available from MMC by connecting to each workstation using the another computer functionality.  Can obtaining access to those the working and non working machines - including the advanced firewall and services functionality on these machines which I can manage remotely.  Can start and restart services on the remote machine.  I can ping the machine, restart the machine remotely using command prompt, and generally manage the machine in a multitude of ways.

    The problem is that about 1/2 of the workstations on the network refuse to allow remote connections using the RDC connection or mstsc from the run command while the other 1/2 work just fine and allow connections.  Nothing I change seems to affect these machines and allow the access or deny access to the working machines (except for changing the firewall setting to deny which stops the working machines from functioning - as would be expected).  I have logged firewall connections to see if the firewall blocks anything with no deny activity detected.  I have searched endlessly on the web trying to find something that might provide guidance since there are no error messages except for the standard and unhelpful message of:

    Remote Desktop can't connect to the remote computer for one of the following reasons:
    1.  Remote access to the server is not enabled
    2.  The remote computer is turned off
    3.  The remote computer is not available on the network
    Make sure the remote computer is turned on and connected to the network, and that remote access is enabled.

    So let's review the above in light of the non-working computers that refuse RDC connections:

    1.  Remote access is turned on and enabled - checked the registry key (mentioned above) on the remote computer and verified it is set to zero.  Also checked the machines using the System and the remote access link to ensure it was set to the allow connections (at the lowest level - so we are not using the higher security settings at this point in time).

    2.  I can ping the remote computer and can use the MMC connecting to another computer functionality to connect to the machine and make changes.  Obviously it is not turned off if I can do this.  Can also ping the machine.

    3.  The remote computer is available on the network because I can see it in the network area of Windows Explorer, I can ping it using either the computer name or IP address, and I can connect to the computer through MMC to obtain access to services and other functionality.

    I am really hoping that someone else in this forum has beat their head against the wall a bit longer than I have (i am getting pretty bloody here with the head banging) and has run across this problem and knows what the fix for it is.  I makes absolutely no sense to me why basically all the same computers configured in the same manner and installed and setup very consistently have half allowing connections and half not allowing connections.  I know there has to be an answer somewhere but I sure have not been able to find it yet.  Any help greatly and appreciatively accepted.

    Thanks.

    Saturday, June 9, 2012 10:24 PM

Answers

  • The solution was a registry key fix.  The terminal server default port number (3389) on the workstations for the ones I could not connect to had been changed (not sure if this was done by a user or by something else).  Once I changed the default settings in the registry back to the default terminal server port number all the non-working workstations functioned as expected.  Took a while to figure it out but I was able to finally resolve the issue.  I never went any further to figure out the reason the port numbers were changed and no one at the company ever confessed to changing the port numbers but it sure was a frustrating issue to figure out.

    I do not have the knowledge base article reference anymore that tells you were to change the terminal server port numbers in the registry, but I am confident a few minutes of searching will produce the KB number.

    Good luck.

    • Marked as answer by CTS-JohnA Tuesday, December 4, 2012 8:45 PM
    Tuesday, December 4, 2012 8:45 PM

All replies

  • 1. Connectivity is needed but visibility is irrelevant.

    2. You have not specified if there are any traces in Event log(s) and firewall logs.

    3. Try RDP connection with firewall disabled.

    4. Use network monitor to pinpoint what is the "obstacle" thet prevent you from connecting to other hosts.

    Regards

    Milos

    Sunday, June 10, 2012 6:44 AM
  • My comments are added below in bold text.

    1. Connectivity is needed but visibility is irrelevant.

    The workstations can be connected to through Active Directory Manage function, through Windows Explorer to shares or admin shares setup on the workstations, or through the MMC console from other Workstations/Servers and selecting these machines to connect.  I can even manage the components that I connect using and the changes made are saved as expected.  Every way I have tried to connect works except for RDC.

    2. You have not specified if there are any traces in Event log(s) and firewall logs.

    There are no traces of connection failures in the event logs or firewall logs.  Everything appears to be passing the connection request through successfully.

    3. Try RDP connection with firewall disabled.

    I have and get this error.  I have disabled AV, AV firewall, Windows Firewall, opened ports or pre-configured services as appropriate, tried closing them and reopening them and nothing along this line fixes the issue.

    4. Use network monitor to pinpoint what is the "obstacle" thet prevent you from connecting to other hosts.

    I will look at this to see if it sheds any additional information on the issue but at this point since other means of connecting to these machines work and RDC is the only component which does not, I am not sure if anything new will result from this path.  Will report back on findings of this testing once I have them.

    Regards

    Milos


    Monday, June 11, 2012 12:31 AM
  • Hi,

    May I know what is the difference between both of the 1/2 computers?  Pay attention to the 3389 port.

    Here is an article and one guide about RDP can be referred to.

    Can’t Connect Remote Desktop to Windows 7- How to Fix?

    http://www.sysprobs.com/connect-remote-desktop-windows-7-fix

    Remote Desktop Connection: frequently asked questions

    http://windows.microsoft.com/en-us/windows7/Remote-Desktop-Connection-frequently-asked-questions


    Ivan-Liu

    TechNet Community Support

    Monday, June 11, 2012 3:23 AM
  • The account that you are using to connect does it have local admin on those workstations.

    If it doesn't you will need to add it to the local group remote desktop users.

    Make sure that you don't have two a records in DNS for the computers in questions. For example when you try first time with rdp DNS will give you one ip to connect and then when you try second time round robin kicks in and gives you the second ip for it and then you can connect.

    Monday, June 11, 2012 5:53 AM
  • The account that you are using to connect does it have local admin on those workstations.

    If it doesn't you will need to add it to the local group remote desktop users.

    Make sure that you don't have two a records in DNS for the computers in questions. For example when you try first time with rdp DNS will give you one ip to connect and then when you try second time round robin kicks in and gives you the second ip for it and then you can connect.

    This is somewhat irrelevant because it never gets to the login screen.  The message denying the connection occurs prior to the appearence of the login prompt.  However, to answer your question, I have appropriate user rights either in the local administrator's group and/or in the remote desktop user's group and I even tested it putting several people in both.

    Also, I have the settings such that the authentication protocols are at the lower level allowing older RDC clients to connect which cannot support the higher encryption protocols in Windows 7.  I have however tried it with the higher encryption enabled and the new clients and it still has no effect on the issue.

    Monday, June 11, 2012 11:56 PM
  • All the computers were built or rebuilt using Windows Deployment services.  Hardware is very similar on many of the machines as they were all purchased about the same time.  However there are other machines with different hardware configurations that are not working and some that are.  Of the working machines their are some from the same purchase that are working and their are some that are not.  In addition, the most recent purchased machines also deployed using Windows deployment services inj the exact same way as all the previous machines are working correctly and allowing connections but there are only two of them which were purchased.  I cannot pinpoint anything specific with these machines that would make them work over those that are not because they are identical to the prior machines purchased 6 months previous and they were deployed in the exact same way using Windows Deployment Services.

    I looked at the articles you mentioned above - specifically the Can't connect to remote desktop and all of those items listed in that article have been used in attempting to fix the issue.

    Tuesday, June 12, 2012 12:12 AM
  • More information on this issue.

    Through more research, I have found the following:

    The failure always occurs on computers running Windows 7 Professional whcih were deployed using Windows Deployment Services.

    The failure always occurs BEFORE the password prompt is reached - which in my mind means the computer is not accepting the connection.

    The Windows Firewall is set to allow RDC connections through along with any other communiction on the domain segment of the network

    The antivirus firewall is not blocking any traffic on the trusted (domain) network - I have even disabled the antivirus solution to elimiante it as a possible source of the problem. 

    One of the machines, a Windows XP OS works fine.

    Another machine, the image machine to create the Windows Deployment Service image, allows RDC connections to be made to it

    Two other machines allow successful connections but were added to the network about 3 months after the original network buildout where we used Windows Deployment services to refresh all the computers and put a consistent operating system image across the entire network in place.  These two machines allow RDC connections without any issues.  We believe but do not remember that these two machines were probably setup not using Windows Deployment Services.

    Outgoing RDC Connections from the non-working computers function fine - only incoming RDC connections fail. We have also turned off and turned back on Remote Access on the non-working machines.

    No logs are being triggered for denied connections in Windows Firewall and there is no apparent secondary source for the reason the connections are being lost. 

    What I am begining to believe is that we have a bad file (configuration or system) in the image that did not get created properly during the image build in the Windows Deployment Server.  This image was then rolled out to all the workstations and as a result I have this corrupted file across all the computers built with Windows Deployment services.

    My question is how to fix this.  If the file that controls RDC Connections is corrupt and it is therefore prevening the connections perhaps I could replace the system file from one of the working computers.  If it is a corrupt configuration file, perhaps I can delete the configuration file and it will recreate upon next use.  Or, perhaps I will have to do a repair on the systems affected but that will be super time consuming.

    Anyone have any thoughts on how to address this in a quick and easy way?  I need simple and fast to address this versus the more lengthy process of doing a repair on each of these machines which will take days to complete.  Note:  The machines have been in use for 6 month and pushing a new image to the machines using Windows Deployment services is no longer an option.

    Sunday, June 17, 2012 6:52 PM
  • Were you able to fix the issue? I have the same problem too. However, it happens with both windows XP and 7 machines and the issue appears to be IP specific. 
    Tuesday, December 4, 2012 5:11 PM
  • START->CMD->RUN AS Administrator

    ipconfig /flushdns

    ipconfig /registerdns

    If you have access to DNS server settings , then check for duplicate records for one IP address.

    If there is duplicate records, delete them both, then reboot your PC.


    JanisK Blog

    Tuesday, December 4, 2012 8:07 PM
  • The solution was a registry key fix.  The terminal server default port number (3389) on the workstations for the ones I could not connect to had been changed (not sure if this was done by a user or by something else).  Once I changed the default settings in the registry back to the default terminal server port number all the non-working workstations functioned as expected.  Took a while to figure it out but I was able to finally resolve the issue.  I never went any further to figure out the reason the port numbers were changed and no one at the company ever confessed to changing the port numbers but it sure was a frustrating issue to figure out.

    I do not have the knowledge base article reference anymore that tells you were to change the terminal server port numbers in the registry, but I am confident a few minutes of searching will produce the KB number.

    Good luck.

    • Marked as answer by CTS-JohnA Tuesday, December 4, 2012 8:45 PM
    Tuesday, December 4, 2012 8:45 PM