TS unusual behavior



I am on an NT 4 domain with 3 W2K and 1 W2K3 Terminal Servers (We will be
upgrading to AD shortly). Our license server is W2K3 server. Each terminal
server has the termservice/parameters registry key pointing directly to the
W2K3 license server. Most of our users communicate to these servers through
RDP sessions across a private WAN.

This has happened twice already and I have no idea as to why: Users in
remote subnets are unable to connect to 1 or more of the Terminal servers.
The logon screen does not even appear. They generally get a ‘connection
timeout error’. Users who have already connected earlier in the day remain
logged on and do not experience any issues. I can, however, successfully log
on from any client on the local subnet.

There are no event log errors on the client machine, terminal server, or
license server. We have plenty of available TS Licenses. The only way I have
been able to resolve this issue is a complete uninstall/reinstall of Terminal
Services on the problem servers.

Any ideas?



When this happens, is the user able to successfully ping the
TS that they are attempting to connect to?

Are they able to telnet to port 3389?

Have you tried using netmon or a third party packet sniffing
software to see what packets are going back and forth
when this problem occurs?

Does rebooting the router at one or both ends change the
user's ability to logon?

What happens if the user reboots their machine, are they
still unable to connect to the TS?




Network connectivity is just fine. For example: User A logs on at 9am and
stays connected throughout the day. User B at the same location tries to log
on at 10am and recieves the error. If user A logs off, they are unable to
reconnect. The problem is resolved when Terminal Services is reinstalled on
the server.


The point of what I am asking you to do is to gather
more precise information about what is going on.

For example, having them telnet to port 3389 when
they are unable to connect may not help much if they
are successful, but if they are not it helps point us in a
direction quicker.

Having an actual packet capture of the communication
between a problem client and the server at the time of
a connect problem can help as well. Also router logs
during this time would potentially add to the picture.

For example, we may look at the packet capture
and say:

- The packets left the client okay
- They made it through the routers okay
- They were received by the server okay
- The server didn't respond at all

Then we might take a closer look at this group of initial
packets as compared to a group that works. We are
limited to a certain degree because the packets are
encrypted (although we could temporarily make RDP
packets from the server unencrypted), but we may
be able to see enough to figure it out.

Depending on what you find you could submit an
incident to PSS, and if it was a bug there would be
no charge.

If you don't have network capture software you can
install netmon on the server and workstation(s) for free.

Now, if you feel that there is no need to find out more
about the communication between the clients and
server, I respect that. In that case I'm not sure if I can
be of much help; hopefully one of the super experts
will jump in and help you.




I understand what you are asking, and I am aware that the first place to look
is network connectivity. However, since the proble is resolved by
uninstalling and reinstalling Terminal Services on the server, this would
point to the direction of some kind of protocol or registry corruption, or
some unknown issue with licenses.

I forgot to menion in my original post that the first time this happened, I
rebooted the problem server and was not able to connect via RDP from
anywhere, local subnet included.

Thank you.


Do you the following in the event log

Event ID 55

Attempt to Send message to Disconnected communication port
Event Type: Error
Event Source: TermService
Event Category: None
Event ID: 55
Date: 24/05/2005
Time: 09:37:09
User: N/A
Attempt to send a message to a disconnected communication port.
0000: 00 00 00 00 00 00 00 00 ........
0008: 00 00 00 00 00 00 00 00 ........
0010: 00 00 00 00 00 00 00 00 ........
0018: 00 00 00 00 00 00 00 00 ........
0020: 00 00 00 00 00 00 00 00 ........
0028: 00 00 00 00 00 00 00 00 ........
0030: 00 00 00 00 00 00 00 00 ........
0038: 00 00 00 00 00 00 00 00 ........
0040: 00 00 ..

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question