Disconnections with TSAC

[-=D@n=-]

Hi all

I'm having a problem with a couple of sites that use my product over the
internet using the web-embedded RDP client (5,2,3790,0). I currently have
five client sites, totalling about 30 concurrent users connecting to a site
on IIS. The control is then embedded into this site, which connects to TS on
the same machine.

They are getting disconnected at random times throughout the day, and not
just when the client is idle. This is the error that pops up on the screen:
http://putfile.com/pic.php?pic=10/27910281476.jpg&s=x10 . Like I say, they
can be in the middle of working when this happens. All the workstations are
brand-new XP Pro SP2. Both clients are using different ISP's.

There are no corresponding error messages in the Event Log.

These are the settings on my TS:
http://putfile.com/pic.php?pic=10/30310441899.jpg&s=x11 and I'm using
'Medium' encryption in the RDP Properties.

I applied the KeepAliveEnable registry entry about a week
ago(http://putfile.com/pic.php?pic=10/30310464262.jpg&s=x11 ), but not been
able to reboot yet. Does anyone know if this entry needs a reboot?

Vera kindly pointed me to a possibly dodgy MS Patch
(http://support.microsoft.com/?kbid=898060) but this patch doesn't appear to
be installed on the TS (It doesn't appear with the other patches in
Add/Remove Programs, and there's no c:\winnt\$NtUninstallQ898060$).

Understandably, these clients are getting a bit frustrated with this. If
anyone has any suggestions, I would appreciate anything! (Except telling me
to use Citrix!)

Thanks

 

[Vera Noest [MVP]]

I think that you have searched for the wrong KB number!

KB898060 only describes the issue with the Security Patch MS05-019.
The Security patch itself is described in KB 893066, and that's the
entry that you should search for to see if you did install it.

If users are disconnected in the middle of an active sessions, then
the EnableKeepAlive setting is probably not going to help you.
But you could try to increase the TcpMaxDataRetransmissions
setting.
This problem can have many causes: unstable network, poor
connection, or just a faulty or failing router. You might want to
use "ping" to see if things are failing or "traceroute" to see
where the packets are being dropped.

Check here for info:
How to make your intermittent or flaky terminal services connection
a little more stable
http://terminal.servebeer.com/php/flaky_connections.php

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

 

[-=D@n=-]

I think that you have searched for the wrong KB number!

Hi Vera. D'oh! I can now confirm that 893066 is not installed on this
server.

KB898060 only describes the issue with the Security Patch MS05-019.
The Security patch itself is described in KB 893066, and that's the
entry that you should search for to see if you did install it.

If users are disconnected in the middle of an active sessions, then
the EnableKeepAlive setting is probably not going to help you.
But you could try to increase the TcpMaxDataRetransmissions
setting.

Right. I have had the TcpMaxDataRetransmissions set to 10 for the last week
or so, following recommendations from that
http://terminal.servebeer.com/php/flaky_connections.php
site. I have not rebooted since making any of these changes though, so I
might schedule a reboot for tonight.

This problem can have many causes: unstable network, poor
connection, or just a faulty or failing router. You might want to
use "ping" to see if things are failing or "traceroute" to see
where the packets are being dropped.

Ok, I ran a tracert from the client site to here:

Tracing route to xxx.co.uk [xxx.xxx.xxx.xxx]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms xxx.xx.x.x
2 29 ms 26 ms 29 ms claranet1-hg1.ilford.broadband.bt.net
[217.41.128.72]
3 31 ms 29 ms 29 ms 217.41.128.1
4 29 ms 29 ms 29 ms 217.41.128.106
5 32 ms 29 ms 29 ms t40-dr1-ge-0-3-7.router.uk.clara.net
[195.8.68.235]
6 31 ms 32 ms 32 ms t40-dr2-ge-0-2.router.uk.clara.net
[195.8.86.130]
7 34 ms 35 ms 32 ms t40-cr2-ge.router.uk.clara.net [195.8.86.89]
8 30 ms 32 ms 29 ms t40-br2-ge-7-1.router.uk.clara.net
[195.8.86.145]
9 32 ms 30 ms 29 ms 195.66.224.185
10 32 ms 32 ms 32 ms Intechnology.demarc.cogentco.com
[130.117.19.130]
11 * * * Request timed out.
12 50 ms 47 ms 47 ms xxx.x.x.xx

Trace complete.

I checked with our networking guy, who says this is ok and that the Request
timed out in hop11 is our PIX not allowing the tracert traffic through.

Check here for info:
How to make your intermittent or flaky terminal services connection
a little more stable
http://terminal.servebeer.com/php/flaky_connections.php

I've now tried everything on that site

I've temporarily set the client up with icons on their desktops to use the
normal RDP client, to see how they get on. I will also schedule a reboot for
tonight on the Terminal Server.

Thanks for your help Vera, I'll post back any results.

I wonder if there's any mileage in sticking a trial version of Citrix on the
TS? I know I'll have to completely redo the web-page.....Hmm....

 

[-=D@n=-]

I've temporarily set the client up with icons on their desktops to

use the normal RDP client, to see how they get on.

Great. Now the normal RDP client (mstsc.exe) is only redirecting one if
their two installed printers. Use the web client, they get both their
printers. Use the normal client, just the one printer. Not even their
Windows Default printer.

*sigh*

 

[-=D@n=-]

Great. Now the normal RDP client (mstsc.exe) is only redirecting one
if their two installed printers. Use the web client, they get both
their printers. Use the normal client, just the one printer. Not even
their Windows Default printer.

*sigh*

Updated the client to the latest 5.2 one and the printing is working. One
good thing.

 

[-=D@n=-]

Updated the client to the latest 5.2 one and the printing is working.
One good thing.

But they are still getting disconnected randomly. Ok, I would now say that
this is a network problem. Does anyone know of a tool that I could run at
the client end, that would monitor the connections to our TS here and make a
log of disconnections and perhaps reasons for them?

TIA

 

[Vera Noest [MVP]]

But they are still getting disconnected randomly. Ok, I would
now say that this is a network problem. Does anyone know of a
tool that I could run at the client end, that would monitor the
connections to our TS here and make a log of disconnections and
perhaps reasons for them?

TIA

You could start very simple, with a continuous ping (ping -t)

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

 

[-=D@n=-]

You could start very simple, with a continuous ping (ping -t)

Hmm, I just tried pinging and after eleven successful pings I had a 'Request
Timed Out'. Is it not the case that RDP should be able to deal with the odd
dropped 'packet'? Is this where the registry changes[1] come into effect? I
mentioned earlier, that I hadn't rebooted the TS since making these changes.
I've scheduled a reboot for 23:00 tonight.

I'm also going to run 200 pings and output the results to a text file, right
now.

Thanks for your support.


Dan

[1] http://terminal.servebeer.com/php/flaky_connections.php

 

[Vera Noest [MVP]]

You could start very simple, with a continuous ping (ping -t)

Hmm, I just tried pinging and after eleven successful pings I
had a 'Request Timed Out'. Is it not the case that RDP should
be able to deal with the odd dropped 'packet'? Is this where the
registry changes[1] come into effect? I mentioned earlier, that
I hadn't rebooted the TS since making these changes. I've
scheduled a reboot for 23:00 tonight.

I'm also going to run 200 pings and output the results to a text
file, right now.

Thanks for your support.


Dan

[1] http://terminal.servebeer.com/php/flaky_connections.php

The EnableKeepAlive setting puts a "heartbeat" on the connection.
That serves 2 purposes:
a) it can help to keep the connection alive by making sure that
routers always "see" some traffic (avoiding an idle session time-
out on the routers)
b) if the connection is broken, the TS will notice this much
earlier, and will be able to respond to the situation according to
your settings (disconnect or reset the connection).

RDP is *not* very good at dealing with dropped packets (but it
should be able to automatically reconnect if there is a very short
connection problem).

By having your users (or you) run a continuous ping, you get some
statistics about the number of packets dropped. That could help you
to narrow down the problem.
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

 

[-=D@n=-]

microsoft.public.win2000.termserv.clients:

-=D@n=- wrote:

But they are still getting disconnected randomly. Ok, I would
now say that this is a network problem. Does anyone know of a
tool that I could run at the client end, that would monitor
the connections to our TS here and make a log of
disconnections and perhaps reasons for them?

You could start very simple, with a continuous ping (ping -t)

Hmm, I just tried pinging and after eleven successful pings I
had a 'Request Timed Out'. Is it not the case that RDP should
be able to deal with the odd dropped 'packet'? Is this where the
registry changes[1] come into effect? I mentioned earlier, that
I hadn't rebooted the TS since making these changes. I've
scheduled a reboot for 23:00 tonight.

I'm also going to run 200 pings and output the results to a text
file, right now.

Thanks for your support.


Dan

[1] http://terminal.servebeer.com/php/flaky_connections.php

The EnableKeepAlive setting puts a "heartbeat" on the connection.
That serves 2 purposes:
a) it can help to keep the connection alive by making sure that
routers always "see" some traffic (avoiding an idle session time-
out on the routers)
b) if the connection is broken, the TS will notice this much
earlier, and will be able to respond to the situation according to
your settings (disconnect or reset the connection).

RDP is *not* very good at dealing with dropped packets (but it
should be able to automatically reconnect if there is a very short
connection problem).

By having your users (or you) run a continuous ping, you get some
statistics about the number of packets dropped. That could help you
to narrow down the problem.

Thanks for your reply Vera. I rebooted the TS last night, so I guess we'll
see what happens today with this particular client.

Interestingly, I ran some tests[1] from home last night for two hours before
rebooting the server. I ran an automated test for two hours and didn't get
disconnected once. I rebooted the server at 23:30, and have been running the
automated tests since 23:47 until now (9:30) and still had no
disconnections. I will keep my 'test' login running for most of the day and
see how we get on.

I'll keep you posted!

Thanks again

Dan

[1] Signing into the TS, running our application, and carrying out most of
the tasks that the end user would.

 

[-=D@n=-]

Vera Noest [MVP] wrote:
microsoft.public.win2000.termserv.clients:

-=D@n=- wrote:

But they are still getting disconnected randomly. Ok, I would
now say that this is a network problem. Does anyone know of a
tool that I could run at the client end, that would monitor
the connections to our TS here and make a log of
disconnections and perhaps reasons for them?

You could start very simple, with a continuous ping (ping -t)

Hmm, I just tried pinging and after eleven successful pings I
had a 'Request Timed Out'. Is it not the case that RDP should
be able to deal with the odd dropped 'packet'? Is this where the
registry changes[1] come into effect? I mentioned earlier, that
I hadn't rebooted the TS since making these changes. I've
scheduled a reboot for 23:00 tonight.

I'm also going to run 200 pings and output the results to a text
file, right now.

Thanks for your support.


Dan

[1] http://terminal.servebeer.com/php/flaky_connections.php

The EnableKeepAlive setting puts a "heartbeat" on the connection.
That serves 2 purposes:
a) it can help to keep the connection alive by making sure that
routers always "see" some traffic (avoiding an idle session time-
out on the routers)
b) if the connection is broken, the TS will notice this much
earlier, and will be able to respond to the situation according to
your settings (disconnect or reset the connection).

RDP is *not* very good at dealing with dropped packets (but it
should be able to automatically reconnect if there is a very short
connection problem).

By having your users (or you) run a continuous ping, you get some
statistics about the number of packets dropped. That could help you
to narrow down the problem.

Thanks for your reply Vera. I rebooted the TS last night, so I guess
we'll see what happens today with this particular client.

Interestingly, I ran some tests[1] from home last night for two hours
before rebooting the server. I ran an automated test for two hours
and didn't get disconnected once. I rebooted the server at 23:30, and
have been running the automated tests since 23:47 until now (9:30)
and still had no disconnections. I will keep my 'test' login running
for most of the day and see how we get on.

I'll keep you posted!

Thanks again

Dan

[1] Signing into the TS, running our application, and carrying out
most of the tasks that the end user would.

Well, the particular user had one disconnection yesterday. So, problem not
solved, but seems to be a lot better. She also did some testing from her
home location last night, and didn't have any disconnections. It's looking
more and more like an issue with her ISP, but I haven't got a clue where to
start if it is. I've emailed the ISP, and they've assured me they don't do
any bandwidth throttling or traffic shaping for non-standard ports. But,
they'll carry out a line test on the ADSL line. I don't expect any results
from that.

Another option we have, we might move the TS outside of the PIX firewall
temporarily to see if that makes a difference.

Dan