Packet loss and Terminal Services 2000

[Guest]

One of our remote offices (of 3) is having serious issues staying connected
to our terminal services server. We have noticed moderate packet loss at some
points. The ISP that services this office continues to state they can
discover no packet loss, but they cannot explain why the users drop, other
then 'must be your server.' What is the maximum packet loss that TS can
manage with? And has anyone else had a issue with this, that might have a
idea that is non-standard?

 

[Guest]

One of our remote offices (of 3) is having serious issues staying connected
to our terminal services server. We have noticed moderate packet loss at some
points. The ISP that services this office continues to state they can
discover no packet loss, but they cannot explain why the users drop, other
then 'must be your server.' What is the maximum packet loss that TS can
manage with? And has anyone else had a issue with this, that might have a
idea that is non-standard?

As an addum, there is little to no ping time / trace route time between the
two locations, with some exceptions at various times, but not enough to
explain the user disconnects.

 

[Mike Monaghan]

Hello Csmith,

A couple of things to look at. First, Have you checked the packet loss outside

your firewalls? We've hit a few that when they get warm, or the firmware
decides it is "packing dropping day" will cause many problems. Have you
tested with in both networks to make sure the packet loss is _really_
on the ISP's link? Is it possible that the loss is occurring at a Peering
Point BETWEEN your ISPs?

RDP is pretty robust for short duration outages but anything over a few seconds

may cause disconnected sessions. There is a keep alive mechinism that is
designed to combat this, but the defaults might be too low for your situation
or in some cases we've found it to be off.
Take a look at http://www.prcontrol.com/kb/index.php?page=index_v2&id=52&c=4.

For a recent wireless installation we used 12 retries at 5 seconds (or 60
seconds before giving up). That gives RDP a lot of time to recover from bad
network conditions. The default is 5 seconds before giving up.

Mike