Q.01 I lose connection to TS periodically. How can I
make an intermittent or flaky TS connection a little more stable?
A.01 Before attempting to follow the guidelines presented
here, please be certain that you are running the latest MS
service pack, as well as a recent version of ManageMore. There
have been several major corrections (now in W2k TS Service Pack 2 or
greater) that improves TS stability for database applications like
ManageMore. Furthermore, a known issue with dual
processor servers running ManageMore has been corrected (Version 4.0
Rev D or greater) which also caused ManageMore to exit suddenly
while in a TS session. If you are still experiencing
intermittent TS connection problems after upgrading both TS and
ManageMore, then read on.
Using a few
registry hacks, you can stabilize your terminal services network
connection and reduce the number of disconnected sessions you get
from weak WAN connections. These tweaks will also serve to prevent
disconnects from occurring when network devices kill off sockets
that are idle too long. NOTE: Editing the OS registry should
be done by IT personnel or advanced computer users.
Prerequisites:
•A running terminal server that needs to have its connection
stabilized
•A registry editor, like regedit.exe
Section 1: Indicators:
Many WAN connections can vary in quality and latency, and often
times these two characteristics will manifest themselves in
disconnected terminal services sessions. By doing two relatively
easy registry hacks, you can reduce these disconnects and improve
the overall experience of your users.
Section 2: Keep Alives:
In the registry at HKLM\SYSTEM\CurrentControlSet\Control\Terminal
Server, create or edit the DWORD value of KeepAliveEnable and set it
to 1. This will turn Keep Alives on. This will serve to stabilize
the connection by sending 'heartbeat' packets to the client every so
often. This will cause an idle connection to be probed every so
often just to be sure that the connection is still alive and that
the client is still listening on the other side. This will also help
prevent disconnects by preventing network devices from killing off
sockets that it assumes to be idle. Because terminal services is
such a low bandwidth protocol, when a user is idle, no network
activity will occur. Some network devices will interpret a
connection that is in the idle state for an extended period of time
to be a dead connection, and thus will terminate the socket.
However, when the user comes out of the idle state, the terminal
services client can no longer contact the terminal server because
the socket is dead. By turning on Keep Alives, the connection will
not appear idle, and therefore the network device will not attempt
to terminate the socket.
For more information about Keep Alives, check out this
link.
Two other registry entries to look at are at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval
and HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime.
Both are DWORD entries. These two registry entries typically do not
need to be changed, but I've included them here for completeness.
KeepAliveInterval determines the interval separating keep alive
retransmissions until a response is received. If a response is
received, the delay until the next keep alive transmission is again
controlled by the value of KeepAliveTime. The connection will be
aborted after the number of retransmissions specified by
TcpMaxDataRetransmissions (which will be discussed in the next
section) have gone unanswered. KeepAliveInterval is set by default
to be 1000, which is one second.
KeepAliveTime controls how often TCP attempts to verify that an idle
connection is still intact by sending a keep alive packet. If the
remote system is still reachable and functioning, it will
acknowledge the keep alive transmission. KeepAliveTime is set by
default to be 7,200,000, which is 2 hours.
For more information about KeepAliveInterval and KeepAliveTime,
check out this
link
Section 3: TcpMaxDataRetransmissions:
In the registry at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,
create or edit the DWORD value of TcpMaxDataRetransmissions. By
default it is set to 5, but I would recommend doubling that value,
to 10. The value of TcpMaxDataRetransmissions is the number of times
TCP retransmits an unacknowledged data segment on an existing
connection. TCP retransmits data segments until they are
acknowledged or until this value expires. Basically, when a client
doesn't respond to a packet from the terminal server, the server
will attempt to retransmit the packet up to
TcpMaxDataRetransmissions number of times. By increasing this value,
you are giving the client more time to respond to the server, which
will help improve flaky connections or connections with high latency
or higher than normal packet loss.
If you have numerous servers you need to migrate this out to, you
can hack this registry entry, export the changes to a .reg file,
then silently import it (regedit.exe /q) onto your all your servers.
Q.02 How do I force one login session per user and reconnect them
to their previous session if possible?
A.02 Under TS for Windows 2003 Server, this setting
can be found within the TS Configuration tool. From the Start Menu,
Go to Administrative Tools, Terminal Services Configuration.
Choose the Server Settings Folder from the Tree Console.
On the right pane view, you will see a setting for "Restrict
each user to one session." Click on this and change to Yes.
Q.03 How do I schedule a nightly reboot of Terminal Services?
A.03 Rebooting the Terminal Services Server is a
very good idea to ensure that the system runs at optimum
performance. We recommend that you reboot your server at least
weekly.
Terminal Server comes with a command-line tool called TSSHUTDN
on TS 2000 and SHUTDOWN on TSE 4.0. This command can be used in
conjunction with the Scheduler Service and the AT command to
schedule an automatic shutdown and restart of your Terminal
Servers at any interval you desire.
Q.05 Performance when running the application is great, but I am
experiencing poor remote printing performance using Terminal
Services?
A.05 Unfortunately, printing is probably Terminal
Services biggest weakness.
Printing often seriously
degrades an otherwise economical server based IT environment.
In some cases, the slow performance problem comes from poor
configuration. Terminal Services is not as user-friendly in
this area as its big brother Citrix Metaframe. Improperly
configured printer drivers or incompatible printer drivers can
certainly make print jobs much slower than normal.
However, even if everything is configured correctly, you may
still experience poor printer performance due to unintelligent
bandwidth optimization on Terminal Services behalf.
Due to this, it is not uncommon to experience:
•
Poor application performance due to heavy bandwidth traffic
when transmitting print jobs
•
Heavy load to server resources like memory and CPU caused by
rendering print data
•
Threat to system stability from printer driver conflicts and
incompatibilities
•
Higher online costs from transmitting large print jobs
•
Higher demands on administration for the necessary management
of a multitude of printers
and printer drivers
•
Overwhelmed client machines because of insufficient resources
•
Limited flexibility for mobile users and home offices
If you have tried everything and are still experiencing printer
slowdown, you may have to consider a a third party product on
the market that specifically addresses the printing woes of this
otherwise fantastic operating system. Please look into
ThinPrint from ThinPrint Corporation at
www.thinprint.com
Q.06 While working in TS 2000/2003, I occasionally get an error
message that says "Access denied. Could not get write access to
<Filename> so trying read-only". What is this and can it be
corrected?
A.06 Our research on this indicates that TS
sometimes has problems with following its own security policies.
By forcing explicit write permissions to all the files contained
inside your data folder, this error message seems to go away.
Although this is not a confirmed issue with TS, it appears that
setting rights at the folder level only doesn't always propagate
correctly.
Also, in TS 2003, you have to set the rights at both the NTFS
level and also in the Sharing security options.
Q.07 Any references to other common Terminal Services Issues?
A.07 There are plenty of great references on the
internet for implementing Terminal Services and Citrix correctly.
