This is the second article in a two-part look at some of the frequently asked questions that Windows Thin Client expert Todd Mathers has received over the last couple of months regarding MetaFrame 1.8 Service Pack 2 and Feature Release 1.

This is the second article in a two-part look at some of the frequently
asked questions that Windows Thin Client expert Todd Mathers has received over
the last couple of months regarding MetaFrame 1.8 Service Pack 2 and Feature
Release 1.

What Are the Latency-Reduction Options with FR1?

Whenever users running on a Terminal Server have issues with performance, typically
the source of these problems can be traced to latency in keyboard and mouse
response. Most Terminal Server administrators at one time or another have had
to deal with complaints about sluggish keyboard typing and mouse clicks that
"don't seem to be doing anything."

This, coupled with the growing use of MetaFrame as an application portal via
the Internet (where bandwidth and availability are rarely a certainty), has
prompted Citrix to look at ways to help reduce the effect that latency may have
on the perceived performance of a MetaFrame serverhence the new suite of
latency-reduction options available with FR1.

To properly enable these latency-reduction (LR) options, you will need to perform
some configuration on both the ICA client and the MetaFrame server. For the
LR options to function, the following criteria must be met:

The MetaFrame server must be running FR1 and must have a valid license
installed. The Japanese version of MetaFrame and MetaFrame for Unix 1.0
and 1.1 do not support the LR options.

On a Windows NT 4.0 Terminal Server, you must have Service Pack 4 or higher
installed.

The user must be running an ICA client that supports the LR options. Currently,
only the Win16, Win32, and Linux ICA clients support the SpeedScreen 3 LR
options.

The desired LR options must be configured on both the client and the server.
For example, even though the text echo feature has been enabled for all
applications on a MetaFrame server, unless an ICA client has also been configured
to use text echoing, then it will not be enabled for that client. The reverse
is also true. If a client is set up to use text echoing, but the option
has been disabled for all applications on a MetaFrame server, then text
echoing will not be available to the user.

Server-wide Latency-Reduction Settings

On the MetaFrame server, the latency-reduction options are configured using
the SpeedScreen Latency Reduction Manager (LRM). This can be found under MetaFrame
Tools on the Start menu, or can be started from a command prompt using ss3admin.exe.
Figure 1 shows
the main window for LRM, with a single server icon for the current server. With
the initial version of LRM, you can only modify the settings for the server
that you are currently logged onto. You cannot manage multiple servers from
this single console. Later in this article, I will point out the required registry
and data files for LRM. This information can be manually replicated to other
MetaFrame servers to ensure a consistent server farm configuration.

To view the LR features for this server, you can either double-click on the
server name, or right-click and select Server Properties. The Server Properties
dialog box opens, as shown in Figure
2. Here you will configure the server-wide settings that will determine
whether the LR features are enabled. I will look at application-specific features
shortly.

By default, the Enable Mouse Click Feedback option is enabled for all applications
on the server. The objective of this feature is simple: to immediately change
the user's local cursor to an hourglass in the event that latency is preventing
the immediate processing of the user's mouse click. To the user, it appears
that the mouse click has initiated work on the server, which in turn has resulted
in the hourglass being displayed. This immediate feedback helps to eliminate
the problem in which users perform multiple mouse clicks on an object because
they have not received any visual notification that their request is being processed.

In the lower portion of the dialog box, you will find the latency threshold
options. These settings apply only to those clients that have their LR settings
configured as Auto. In this situation when the high latency threshold is exceeded,
the LR options for the client are automatically enabled. These same options
are automatically disabled if the opposite occurs and the latency drops below
the lower latency threshold.

Depending on your environment, you may want to look at reducing the upper threshold
from 500ms down to somewhere between 250ms and 350ms. Typically, once the latency
rises above 300ms, the client will experience severe performance degradation.
In this situation, the LR options (particularly text echoing) can work very
well to reduce these latency effects.

The final server-wide LR option manages local text echoing. Basically, this
feature works by echoing the text that you are entering locally on the desktop,
matching property attributes such as text color and font, and then transparently
updating the text on the server side as quickly as possible. This eliminates
the impact that latency can have on text input, particularly for users with
high typing speed.

The successful operation of text echoing depends on whether the application
on the MetaFrame server is utilizing standard Windows API calls for text manipulation.
This is necessary to ensure that things such as text boundaries and properties
(font size and foreground and background color) are enforced properly. Some
of the common problems that you may encounter with SpeedScreen text echoing
and a nonstandard application include these:

The text fonts appear incorrectly sized, misaligned, or corrupted when
the user is typing.

The text field's foreground and background colors are appearing incorrectly.

In the most severe case, the application may hang or crash.

Text echoing does introduce some minor text overrun if users are rapidly entering
text in a Web text entry field, as shown in Figure
3. This is simply because the text fields on a Web page are not standard
Windows text controls. When the echoed text is actually transmitted to the MetaFrame
server, the control will update properly and the overrun text will display properly.

The potential problems that text echoing can introduce are the main reason
why this option is not enabled by default on either the client or the server.
Citrix recommends (and I agree) that text echoing not be enabled for all applications,
but instead should be enabled and configured on an application-by-application
basis.

Of course, this will depend on how many applications you are running and how
severe your latency issues are. It certainly may be more effective to enable
text echoing for all applications and then selectively disable it for those
applications that are having issues.

Regardless of which approach you may decide to take, if you are planning to
implement text echoing, you should be sure to perform your initial testing in
either a nonproduction or a limited production environment.

Application-specific Local Text Echoing Options

In addition to configuring server-wide settings, you can configure local text
echoing options on one or more specific applications. Mouse click feedback can
be enabled or disabled only for a server and cannot be configured on a per-application
basis. Figure 4
shows the RADIUM MetaFrame server application-specific settings for Paint Shop
Pro and Microsoft Word.

A new application is configured by either selecting New from the Application
menu or right-clicking on the server name (RADIUM) and selecting Add New Application.
This initiates the Add New Application Wizard, which provides a straightforward
method of creating a new application entry. Under normal circumstances, the
wizard is sufficient to either enable or disable text echoing for the particular
application. You will not need to further customize these settings unless you
are having issues with the application using normal text echoing and want to
try to remedy the problem with some specific tuning.

In this case, you can access more detailed settings by opening the Properties
dialog box for a specific application, as shown in Figure
5.

Detailed latency settings for a specific application in the Latency Reduction
Manager.

On the Application Properties tab, you can configure text echoing options that
affect all text input fields in the application. Besides enabling or disabling
text echoing, you also have the option of explicitly setting how echoed text
will be displayed. The default is for echoed text to appear in place, and I
have yet to encounter an application in which this has had to be changed. You
would probably want to change this option only if echoed text is appearing corrupted,
overlapping or outside a text boundary.

In the extreme case, you can specify that the echoed text will appear in a
floating bubble and can be moved independently of the application. An example
of this is shown in Figure
6, with the Internet Explorer application configured with this option. As
you can see, this should probably be used only if you must provide text echoing
in a high-latency situation and the standard text echoing options are not working
properly for the appthis option is almost certain to cause user confusion.

If you click the Advanced button, a dialog box opens with one option that can
be selected. From here, you can force SpeedScreen to operate in safe mode when
processing all input fields in this application. This option affects SpeedScreen
regardless of whether text echoing is enabled, and it is available even if text
echoing is disabled. This option would be used if you were experiencing text
corruption in an application even though local text echoing is not enabled.

Besides configuring text echoing for the entire application, you can configure
it for specific text input fields. This is done from the Input Field Configuration
tab, as shown in Figure
7.

The options available here should really be considered as the last-resort options
when trying to get text echoing to function with an application. Certainly the
number of input fields in the application and the problems that you are encountering
will play a large factor in whether the granularity available from this tab
is worth the effort to configure. The process itself is quite straightforward.
You simply start the application that you want to modify, click the New button
on the Input Field Configuration tab, and then follow the wizard to select the
specific field. Contrary to what you might believe, you will typically not be
able to narrow the functionality to a single text input field. As a simple example,
I have set up local text echoing for the REGMON utility, available from www.sysinternals.com/.
After launching REGMON, I select the New button and follow the wizard prompts
until I am asked to select the desired input field. I decided that I would like
to choose the Include field in the filter configuration dialog box, as shown
in Figure 8.

Selecting a specific input field to configure in the Latency Reduction Manager.

After selecting the field, the wizard populates the field class information,
but no field name is defined. Continuing on with the wizard, I then select the
Low option so that the text bubble automatically appears. After I complete the
wizard, my new field is shown in the field list (see Figure
9).

If I then launch REGMON and open the filter dialog box, I see the local text
echo bubble appear as expected (see Figure
10). But I see the same bubble appear regardless of which edit control I
select in this dialog box. So, even though I wanted to configure only the specific
Include text field, I inadvertently set it for all three text input fields.
Now this may not appear to be a very big deal because in this case we probably
would want it set for all three. But it does demonstrate how some unexpected
behavior may occur.

The additional options for a specific text field (refer back to Figure
9) all relate to issues with SpeedScreen incorrecting detecting properties
for a text field, such as font size, text or background color, and whether the
field is a password field. If any of these options are appearing corrupted or
incorrect for a field, you can manipulate these options to try to correct the
problem.

Latency-Reduction Registry Settings

The server-wide latency-reduction settings are maintained in the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\ss3.

The six registry values are shown in this table:

Value

Description

ConfiguredApplicationCount

The number of application-specific LR settings that exist on this server.
This value is used to determine whether data needs to be read from the
ss3config data directory (discussed later).

CurrentVersion

SpeedScreen 3 version.

EnableLocalTextEcho

Server-wide text echoing; 1 is enabled, 0 is disabled.

EnableMouseFeedBack

Server-wide mouse feedback; 1 is enabled, 0 is disabled.

StartThreshold

The upper threshold for enabling LR on Auto-configured clients.

StopThreshold

The lower threshold for disabling LR on Auto-configured clients.

Because all of these options are configurable through the GUI tool, you should
not directly modify them through the registry. This key can be exported and
then imported into multiple MetaFrame servers to duplicate the Latency Reduction
configuration. If application-specific settings exist, then the ss3config data
directory will also need to be replicated.

Latency-Reduction File Settings

While the server-wide latency settings are maintained in the registry, any
application-specific settings are maintained in individual files located in
separate subdirectories under %SystemRoot%\system32\ss3config.

Each application that you configure will have its own subdirectory corresponding
to the executable name (minus the .EXE extension). For example, if I have defined
application latency settings for Microsoft Word, then a directory called WinWord
will exist. Within the application directory will exist one of two subdirectory
names: either BaseName, which corresponds to a configuration that affects all
instances of the application, or FullPath, which corresponds to an application
in a specific location.

Within this subdirectory you will find a file with an ss3 extension. This file
contains the specific latency options that you have configured for the application.
Figure 11
shows the filename for a latency configuration file for a specific installation
of PaintShop Pro (psp.exe). The full pathname for the executable is used as
the filename, except that the backslash and colon characters have been substituted
with their ASCII character equivalent and are preceded by the percent sign (%).
In this example, the characters :\ would be converted to %3A%5C.

The contents of the ss3 file itself are generated by the LR Manager and should
not be manually edited. By replicating the appropriate registry key and the
ss3config directory to another server, you can automate the process of replicating
the latency-reduction changes to all of the SP2/FR1 MetaFrame servers in your
environment.

Client Latency-Reduction Settings

As I mentioned earlier, to take advantage of the SpeedScreen 3 Latency Reduction
features, you are required to run an ICA client that supports these options.
Currently only the 6.0 ICA clients for the Win16, Win32, and Linux platforms
are supported.

The client-side LR options must be configured separately for each individual
application set or custom ICA connection that is created. These options cannot
be configured as client-wide defaults. Figure
12 shows the Default Options tab for an application set's properties. The
options available here are identical to those found on the Options tab for an
individual custom ICA connection.

SpeedScreen latency options for an application set on the Win32 client.

The one difference between the properties for an application set and a custom
ICA connection are the default LR options when the object is created. The defaults
are as follows:

ICA Connection Type

Default SpeedScreen Latency

Reduction Options

Application set

Off

Custom ICA connections

Auto Mouse click feedback is enabled. Local text echo
is disabled.

Changing the setting from Auto to On will force the client to use latency reduction,
regardless of how low the latency might actually be on the connection. As I
mentioned earlier, local text echoing must be enabled on both the client and
the server for it to actually be used.

Besides managing the LR options through the client GUI, you can also make the
changes directly within the APPSRV.INI or PN.INI files. As with other APPSRV
and PN settings, you can customize them for use within a preconfigured ICA client
installation, thereby ensuring a consistent client configuration for deployment.

Two new values have been created for use in the .INI files:

ZLKeyboardMode

ZLMouseMode

The ZL prefix in the value names is short for "zero latency."

The integer numbers from 0 to 2 are the only valid values that can be assigned
to these variables. The different integer values have the following meanings:

Value

Meaning

0 (zero)

Disabled

1 (one)

On

2 (two)

Auto

For example, if you wanted to configure the LR settings for Auto with both
mouse feedback and keyboard echo enabled, then any of the following three pairs
would be valid:

ZLKeyboardMode = 2 ZLKeyboardMode
= 1

ZLMouseMode = 2 ZLMouseMode
= 2

ZLKeyboardMode = 2

ZLMouseMode = 1

When reading the settings from the .INI file, only one setting is required
to be set to 2 to enable the Auto option. So, for example, to have Auto with
only mouse feedback enabled would be as follows:

ZLKeyboardMode = 0
ZLMouseMode = 2

You may have noticed that these values can also be found in the WFClient portion
of the APPSRV.INI file. Unfortunately, modifying the values in this section
does not provide client-wide changes to the latency-reduction options.