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.

Users are currently experiencing performance problems when using RDP to connect to Windows Terminal Servers. Even users connected to the data centre directly on fibre link are experiencing problems, so I don't believe the issue is the WAN.

Can anyone recommend a utility that shows the ICMP ping time, vs the time to respond to a SYN request on port 3389 (used by RDP). I hope that this would show periods when the whole Windows Server / Terminal Server is slow responding to packets / dropping packets, versus pinging the router on the same LAN.

I understand that this would not be a true "ping", but assuming that if we measured time for a port 3389 SYN to get a SYN ACK response, we could get an indicator of performance. I'd also want the tool to be tidy and properly end the sessions it establishes, to prevent it from becoming a SYN flood DoS attack...

I can see some tools available designed to perform "http-ping" on port 80 to check health of web servers, but nothing for port 3389.

Any ideas on how to monitor this would be greatly appreciated.

share|improve this question
    
tcping looks good; is there anything ready-made that will act as a polling engine, then be able to store/graph results, so that we could correlate ping times with user experience? I have several servers in the pool to monitor... –  Mitch Miller Feb 16 '11 at 2:31
add comment

2 Answers

up vote 3 down vote accepted

You could try tcping to measure latency to port 3389 of the remote server.

tcping.exe is a small console application that operates similarly to 'ping', however it works over a tcp port.

share|improve this answer
    
Just managed to run 3 DOS prompts on my screen: first was tcping to port 3389, next was a normal ping to the same server, and third was a ping to default gateway on that server's LAN. We could see latency in the port 3389 that wasn't occurring on the "normal" pings; this helped server guys to understand that problem is probably with server performance instead of network... So, thanks, TCPING helped us to show where the problem was. –  Mitch Miller Feb 16 '11 at 3:55
    
@Mitch: I'm not doubting you here, but I'm at a loss to understand how yor results have actually narrowed it down to the server. The fact that running tcping to port 3389 is slower only means that the response is slower from that port. Running tcping to port 3389 isn't putting any load on the server like a real RDP session would. This actually makes me doubt that the test I suggested would be valid either. Are you using any type of load balancing for the TS farm? Any type of proxy for RDP? Any NAT translation for RDP that's different from other traffic? –  joeqwerty Feb 16 '11 at 4:11
    
@Joe The RDP pings were occassionally taking 2 seconds; compared to 20ms pings to the same server and the default gateway for that subnet. The server team accepted that as a "proof" that the problem wasn't network latency and looked into the problem further. It looks like they found a driver problem that was impacting RDP performance. –  Mitch Miller Feb 28 '11 at 4:27
add comment

It could be a server problem rather than a network problem. My suggestion would be to run PerfWiz on the server and analyze the results with PAL.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=31fccd98-c3a1-4644-9622-faa046d69214

http://pal.codeplex.com/

share|improve this answer
    
I agree it is probably a server issue. I work in the Network Team and of course it is being reported by users as a "slow network" issue. We want to 'help' the Server team prove it is a problem with their servers. –  Mitch Miller Feb 16 '11 at 2:41
    
You can "cobble" together a network test by running a packet capture on the client while establishing an RDP session to the server. Then simply look at the capture results. –  joeqwerty Feb 16 '11 at 3:48
    
Hi, the intermittent problems are across 100 users and several TS servers in the farm, so it has been hard to pick a specific place to run WireShark to analyse. –  Mitch Miller Feb 16 '11 at 3:57
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.