Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I can telnet 192.168.10.10 3389 and get a connection. But RDP client to 192.168.10.10 immedietly bails (less than 1 sec) "connect" button greys briefly, RDP app remains on screen. Have tried these from other nodes on the subnet to 192.168.10.10 with same result.

On 192.168.10.10 Allow Remote Desktop is enabled. On 192.168.10.10 windows firemall is off. I'm connecting from the same subnet, i.e no firewall hardware / routers in the way. AV software is installed but other nodes on same subnet allow RDP connection using exact same AV settings (network group profile) Checked 192.168.10.10 for any additonal AV software or local firewall products. I'm sure none exist. Checked registry to ensure 3389 was the port set for listening.

Seems to be an XP problem (SP3). 2 nodes on the my LAN have this issue, but many others work fine.

share|improve this question

migrated from stackoverflow.com Jan 7 '10 at 13:55

This question came from our site for professional and enthusiast programmers.

    
What OS is running on 192.168.10.10? –  joeqwerty Jan 7 '10 at 14:56
    
from what ip are you initiating the rdp connection? –  redknight May 6 '10 at 20:05
    
I'll bet it's a 2008R2 TS, we've had XP-SP3 machines do the same thing, never figured out why. We're in the process of upgrading everything to Windows 7, which has never had the problem. –  Chris S May 6 '10 at 23:09
add comment

4 Answers

up vote 5 down vote accepted

I've been having this same issue as well.

Port 3389 will be open and accessible via Telnet. When I try to log in it'll seem to have connected but the session disconnects after a brief pause (about a second or two).

After hunting around on the web and reviewing my system logs I discovered that it was caused by a problem in the display drivers. In my case it was caused by the ATI Catalyst drivers but systems with nVidia drivers have been known to suffer the issue as well.

I'd suggest reviewing your Event Log > System for messages such as:

\SystemRoot\System32\RDPDD.dll failed to load

In my case the issue was resolved by rolling back to the basic ATI video driver.

Here's a more in-depth discussion of the issue. http://blogs.technet.com/b/brad_rutkowski/archive/2008/01/04/systemroot-system32-rdpdd-dll-failed-to-load.aspx

share|improve this answer
1  
had the same issue and this fixed it. –  pablo Mar 5 '11 at 9:19
add comment

Using Telnet you open a connection to the port. Using an RDP client that's only the very first stage. It then goes on to negotiate some connection parameters and perform authentication. A fail on any of those and it immediately disconnects.

There may well be an issue on the RDP host but Telnet is absolutely useless for diagnosing such a problem beyond verifying that the port can be connected to. I'd be more inclined to use Wireshark, or similar, to watch what happens when the RDP client tries to connect.

share|improve this answer
add comment

Two things to check:

  1. If your Anti Virus is McAfee Enerprise, check that under "Unwanted Programs Policy" that Remote administration tools is unchecked.

  2. Event Viewer on both of those PCs. Especially the PC you are trying to connect to. See if something fails every time you try to remote in.

share|improve this answer
add comment

RDP requires port 3389 to be open for TCP (and UDP as well for audio/video redirection). RDP will still work if only TCP is accessible.

--- this bit isn't totally correct, but still kind of useful, and I don't want to modify the answer completely ---

The fact that you can telnet to 3389 means TCP is open, but not necessarily UDP.

I had a somewhat similar issue, and it turned out UDP wasn't open due to a firewall issue (I'm aware you have stated there is no firewall in place, but let's see if it is open or not). Try using PortQry and see if it is LISTENING on that port for TCP and UDP. netstat -a on the problematic machine might also help here.

--- end ---

Also check that the users that are allowed Remote Desktop access exist (if you see SIDs instead of the actual user name, the user probably doesn't exist), are valid, and have passwords set - Start -> Control Panel -> Administrative Tools -> Computer Management -> Local Users and Groups in the tree -> Groups -> Remote Desktop Users.

Lastly, also check that the Remote Desktop Users group is allowed to connect remotely - Start -> Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies in the tree -> User Rights Assignment -> Allow logon through Terminal Services in the list on the right.

EDIT: Modified answer so it is correct as per all the comments listed below. Thanks guys.

share|improve this answer
2  
RDP uses TCP, not UDP. –  joeqwerty Jan 7 '10 at 14:38
    
Can also confirm RDP does not require UDP at all, I've got a few hosts behind a NAT, and only TCP 3389 is forwarded. –  LapTop006 Jan 8 '10 at 3:09
    
Technically RDP will attempt to use UDP for audio streaming, but the session uses TCP. –  joeqwerty Jan 8 '10 at 12:50
    
I stand corrected then. Can't really remember what happened in my situation anymore - maybe the audio streaming option is selected, and because UDP wasn't open, RDP failed to connect? –  Sam Jan 12 '10 at 6:10
    
If you're blocking UDP, audio just wont work correctly. It does not drop the entire connection. The newest video features also use UDP (or maybe it was RTSP, my memory is a bit fuzzy). –  Chris S May 6 '10 at 23:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.