Intermittent disconnect/reconnect problems with TS on Win2K

[Eric]

We are experiencing a very strange problem with TS on
Win2K (latest SP), used for remote admin only, so only 1
or 2 sessions at any time. We run an in-house application
in one session; it runs fine and does not have any
adverse effect on TS. Then we disconnect. Most of the
time, this works fine, but sometimes (seemingly after
we've been disconnected for several hours, although this
may be anecdotal), attempting to reconnect to the session
results in either a new session being created (because TS
thinks the old one is still active) or a timeout after a
couple of minutes (with a non-descript error message that
says "try again later"). In TS Manager, the original
session shows active, and at that point, the only way
to "recover" is to reboot the machine (TS Manager will
not allow a reset, disconnect, or remote control). I'm
not sure if TS had a problem disconnecting or
reconnecting. I've been through all the TS articles in
the MS KB and read all the posts to this newsgroup--no
change (those things that looked like potential fixes had
no effect). There's nothing unusual about the application
we're running in the session, other than that it makes
extensive use of COM objects and interfaces to PCI
hardware in the computer via a local service. Note that
when the TS problem shows up, the application is still
running fine in its session. Has anyone seen anything
like this? Any ideas on what I might try or what path I
might go down next? Tnx!

 

[Matthew Harris [MVP]]

When you disconnect, does the session (viewable through
tsadmin) go into the disconnected state, or stay in the
active state?

-M

 

[Guest]

It stays in the active state. After that, using TS
Manager, you can see the connection, but resetting it
(which it does allow) fails after a long timeout with an
error that says the session is currently connecting,
disconnecting, or resetting. No other options (like
Disconnect) are enabled in TS Manager for the session.

 

[Matthew Harris [MVP]]

Hmm...so when you are in that session and disconnect from
it, what process(ed) do you go through? Do you hit the X
box on the client or do you go to the start menu and hit
disconnect?

-M

 

[Guest]

I think I usually hit the X. That's what I've always
done, and I've never had a problem with it until lately.
Is there some issue with the X? What's different from
using the X vs. Start/Disconnect?

 

[Guest]

On a related question, what do you make of KB article
216783 (discusses adding KeepAliveEnable parameter to the
registry to "completely disconnect a TS connection"? I
did this, and it had no effect, but from what I
understand about what it does, it seems like a good thing
to do anyway. Your thoughts?

 

[Matthew Harris [MVP]]

Hitting the X closes the RDP client, but it doesn't tell
the server directly that the client wants to go to the
disconnect state. There isn't any problem in
this...except that the server then has to manually
determine whether the client is active or disconnected.

By going to the start/disconnect, you are telling the
server to put your session into the disconnected state.

-M

 

[Matthew Harris [MVP]]

I would use that registry entry if you are having the
problem where your session isn't going into the
disconnected state correctly. Putting this registry entry
into your terminal server's registry isn't a bad thing,
but do realize that using keep alives makes terminal
services consume a tiny bit more bandwidth. RDP is
normally an extremely lightweight procotol in that it
avoids using excess bandwidth (and it stays silent most of
the time) and that turning on keepalives defeats this
functionality.

Having saif that, you might also want to check out this
link:

http://terminal.servebeer.com/php/flaky_connections.php

-M

 

[Guest]

Since you mentioned this as a potential issue, I made the
point to start a new session on a freshly-rebooted server
and disconnect using start/disconnect. I then waited
several hours (since the problem doesn't seem to show up
right away) and tried to reconnect to the session. It
propmptly timed out! However, from the TS Manager on the
other machine, I can see it create a new session--not
reattaching to the existing one. After the client times
out, the sessing shows "Disconnected", but then never
goes away. However, it seems that I can now reset the
disconnected session. I have not been able to do this
before--maybe the result of start/disconnect?

Some other things I've noticed:
1) The computer I reconnected from was a different one
than I established the original session from; shouldn't
be an issue, but maybe it's relevant.
2) I tried to establish a new session under a different
login, and that worked, although it took over a minute to
come up; I was watching it in the TS Manager from another
computer, and it took a long while to show the session,
then it came up with a blank name, then it
finally "stabilized". Note that there is an application
running in the original session, but it us using less
than 1% CPU.
3) In TS Manager, when selecting the target server, it
takes over a minute to "collect data from the TS"; other
machines that are not running an application or don't
have an active session, come up instantly.

What would cause TS to establish a new session when the
same user already has an existing session?

What could my application program be doing to "interfere"
with TS?

Thank you for all your help and ideas!

Regards,
Eric

 

[Matthew Harris [MVP]]

answers are inline...

-----Original Message-----
Since you mentioned this as a potential issue, I made the
point to start a new session on a freshly-rebooted server
and disconnect using start/disconnect. I then waited
several hours (since the problem doesn't seem to show up
right away) and tried to reconnect to the session. It
propmptly timed out! However, from the TS Manager on the
other machine, I can see it create a new session--not
reattaching to the existing one. After the client times
out, the sessing shows "Disconnected", but then never
goes away. However, it seems that I can now reset the
disconnected session. I have not been able to do this
before--maybe the result of start/disconnect?

I doubt that this behavior is from doing a
start/disconnect, but I can't think of a good reason why
this has changed.

Some other things I've noticed:
1) The computer I reconnected from was a different one
than I established the original session from; shouldn't
be an issue, but maybe it's relevant.

This might be a problem. The terminal server might not be
able to determine that you want to connect to disconnected
session, so instead it just creates another session.
However, once that session is established, you can connect
to the disconnected session by using the connect.exe
command line tool.

2) I tried to establish a new session under a different
login, and that worked, although it took over a minute to
come up; I was watching it in the TS Manager from another
computer, and it took a long while to show the session,
then it came up with a blank name, then it
finally "stabilized". Note that there is an application
running in the original session, but it us using less
than 1% CPU.

Hmmm...Maybe it was having some problems sharing the
profile between the two sessions.

3) In TS Manager, when selecting the target server, it
takes over a minute to "collect data from the TS"; other
machines that are not running an application or don't
have an active session, come up instantly.

Not quite sure why this is happening.

What would cause TS to establish a new session when the
same user already has an existing session?

See my earlier comments.

What could my application program be doing to "interfere"
with TS?

I doubt your problem is doing that much. Heck, we can
prove this pretty easily. Just start a session and then
disconnect it. Then reconnect from a different computer
using the same user account. Does it take long to login?

-M