Can anyone recommend utilities to measure response time of a Windows Terminal Server?

Question

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.

Solution

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.

Comments

[Mitch Miller]

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]

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.

[joeqwerty]

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.

[Mitch Miller]

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]

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.

[joeqwerty]

@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?

[Mitch Miller]

@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.

[Ray Foss]

This is somewhat okay... but it's not very useful to measure different connection methods like over ssh, over VPN or using competing codecs and protocols