Monitoring and Logging

This section describes the SGD datastore, how to monitor user activity, and how to configure logging.

This section includes the following topics:

• The SGD Datastore

• User Sessions and Application Sessions

• Using Log Filters to Troubleshoot Problems With an SGD Server

• Using Log Filters for Auditing

• Using Log Filters to Troubleshoot Problems With Protocol Engines

• SGD Web Server Logging

• SGD Client Logging

The SGD Datastore

The SGD servers in an array share information. Each SGD server knows:

• What applications are configured and the applications servers on which they run

• Which users have access to applications

• Who is logged in to SGD

• Which applications users are running

The collection of information is known as the datastore.

Information about users, applications, application servers, and webtops is stored on disk in the local repository. Information about user and application sessions is stored in memory.

The datastore is organized into namespaces which are displayed and used on the command line and log files. The general structure is .../namespace/name-within-namespace. The ... indicates the root of the datastore. The namespace indicates the source of the information, such as DNS. After the namespace, names are written using whichever naming scheme is appropriate to the namespace. Names are written like file system paths (slash-separated and top-down).

The following are some commonly used namespaces.

Namespace Description Example Local SGD objects in the local repository .../_ens/o=Indigo Insurance/ou=Marketing/cn=Cust-o-Dat LDAP Objects in an LDAP directory .../_service/sco/tta/ldapcache/cn=Cust-o-Dat,ou=Marketing,o=Indigo Insurance DNS Machines on the network .../_dns/verona.indigo-insurance.com

User Sessions and Application Sessions

This section describes the differences between user sessions and application sessions in SGD. Using the Administration Console and the command line to monitor and control user and application sessions is also covered.

This section includes the following topics:

• User Sessions

• Application Sessions

• Anonymous Users and Shared Users

User Sessions

A user session begins when a user logs in to SGD and ends when a user logs out of SGD. User sessions are hosted by the SGD server the user logs in to. The user name and password they type determine the type of user they are. See Chapter 2, User Authentication for more details about user authentication.

If a user logs in and they already have a user session, the user session is transferred to the new SGD server and the old session ends. This is sometimes called session moving, or session grabbing.

User sessions can be standard sessions or secure sessions. Secure sessions are only available when SGD security services are enabled. See Secure Connections to SGD Servers for more details.

In the Administration Console, you can list user sessions as follows:

• The Sessions tab, in Navigation View, shows all the user sessions that are running on all SGD servers in the array

• The User Sessions tab for an SGD server shows all the user sessions that are hosted by that SGD server

• The User Sessions tab for a user profile shows all the user sessions associated with the user profile

The Sessions tab and User Sessions tab enable you to select and end user sessions. The User Sessions tab enables you to view further details about the user session. For example, the information that the SGD Client detects about the client device.

On the command line, you use the tarantella webtopsession command to list and end user sessions.

Idle User Session Timeout

You can configure an idle timeout period for inactive user sessions. User sessions are ended automatically if there has been no activity on the AIP connection between the SGD Client and the SGD server for the specified period. The timeout is disabled by default for an SGD array.

Activity on the following devices has no effect on the idle timeout period:

• Serial ports

• Smart cards

• Audio

To specify the idle timeout attribute, go to the Global Settings -> Communication tab of the Administration Console and type a value in the User Session Idle Timeout field.

Alternatively, use the following command:

$ tarantella config edit --webtop-session-idle-timeout secs

Replace secs with the timeout value, measured in seconds. A setting of 0 turns off the user session idle timeout feature. This is the default setting.

You must restart every SGD server in the array for changes to this attribute to take effect.

Application Sessions

An application session begins when a user starts an application and ends when the application exits. Each application session corresponds to an application currently running through SGD.

An application session can be hosted by any SGD server in the array. This might not be the same SGD server that the user logged in to, see Arrays.

Each application session has a corresponding Protocol Engine process. The Protocol Engine handles the communication between the client device and the application server. The Protocol Engine also converts the display protocol used by the application to the AIP, which is understood by the SGD Client running on the client device.

You can use application session load balancing to spread the load of the Protocol Engines among the SGD servers in the array. See Application Session Load Balancing for more details.

Some applications can be configured to keep running, even when they are not displayed. These are called resumable applications.

Each application object has an Application Resumability attribute that determines the application’s resumability behavior. Applications can have one of the following Application Resumability settings.

Setting Description Never The application exits when the user logs out of SGD. You cannot suspend or resume applications that are non-resumable. During the User Session The application continues to run until the user logs out of SGD. While they are logged in, the user can suspend and resume these applications. General The application continues to run even after the user has logged out of SGD. When the user logs in again, they can click the Resume button to display the running application again.

If an application is resumable, it is resumable for a period of time, specified by a timeout. If the SGD Client exits unexpectedly, the timeout period is the configured timeout plus 20 minutes.

Resumable applications are useful for the following reasons:

• Applications that take a long time to start can be left running, even after users have logged out of SGD

• Mobile users can leave applications running while they travel

• Users can easily recover from browser or other crashes

In the Administration Console you can list application sessions as follows:

• The Application Sessions tab for an SGD server shows all the application sessions that are hosted by that server

• The Application Sessions tab for a user profile shows all the application sessions associated with the user profile

• The Application Sessions tab for an application server shows all the applications that are running on that application server

The Applications Sessions tab enables you to view details about each application session. You can also end and shadow application sessions. Shadowing a session enables you and the user see and interact with the application at the same time.

See Using Shadowing to Troubleshoot a User's Problem for more details about shadowing application sessions.

On the command line, you use the tarantella emulatorsession command to list and end user sessions.

Anonymous Users and Shared Users

There are two special cases, as follows:

• Anonymous users. These are users that log in without typing a user name and password. See Anonymous User Authentication.

• Shared users. Also called guest users. These are users that log in with the same user name and password. See Using Shared Accounts for Guest Users.

To be able to distinguish between these users, SGD assigns shared users and anonymous users a temporary user identity when they log in. This has the following effects:

• User sessions do not transfer if the user logs in to SGD more than once

• Application sessions end as soon as the user session ends, regardless of the application’s Application Resumability setting

• If the user does not log out, server resources are consumed

Using Log Filters to Troubleshoot Problems With an SGD Server

When you first install SGD, the default log filters log all errors on the SGD server. If you want to obtain more detailed information, for example to troubleshoot a problem, you can set additional log filters.

You can set additional log filters in the following ways:

• Type the filter in the Log Filter field on the Global Settings -> Monitoring tab in the Administration Console. Each filter must be separated by a Return key press.

• Use the following command:

  $ tarantella config edit --array-logfilter filter...

  Each filter must be separated by a space.

Each log filter has the form:

component/subcomponent/severity:destination

The options for each part of the filter, and how you view the log output, are described in the following sections.

Selecting a Component and Subcomponent

Selecting a component and subcomponent enables you to choose the area of information you want to log from the SGD server.

The following table shows the available component/subcomponent combinations and an explanation of the kind of information produced.

Component and Subcomponent Information Provided audit/glue Audit of changes made to the SGD server configuration, or to your local repository configuration, and who made the changes. For example, you can use this to find out who made changes to a user profile object. audit/session Starting and stopping user sessions and application sessions. For example, you can use this to find out how long a user had a running application session. cdm/audit Authorization of SGD user for client drive mapping (CDM) purposes. For example, you can use this to find out whether a user’s credentials are causing CDM to fail. cdm/server Information about CDM services. For example, you can use this to find out whether a client connection error is causing CDM to fail. common/config How SGD server configuration is stored and copied across the array. For example, you can use this to find out why a global setting configuration change is not being applied to an SGD server. metrics/glue Memory and timings. For example, you can use this to find out how long it took to run an SGD command. metrics/soap The SOAP component of Tomcat’s SOAP proxy. For example, you can use this to trace how long it took a SOAP request to finish. server/billing SGD billing services. For example, you can use this to find out why billing data is being lost. server/common General SGD information. For example, you can use this to troubleshoot DNS errors. server/config Changes to SGD server configuration. For example, you can use this to log changes to SGD server configuration or to find out if the configuration has become corrupt. server/csh The SGD client session handler. For example, you can use this to find out why a user can not restart an application session. server/deviceservice Mapping of users to accessible device data. For example, you can use this to find out why a user can not access client drives. server/directoryservices Connections to Active Directory or LDAP. For example, you can use this to find out why an Active Directory or LDAP user cannot log in. server/diskds Information about the local repository. For example, you can use this to get information about corrupt objects or inconsistencies in the local repository. server/failover Information about array failover. For example, you can use this to troubleshoot problems with an SGD array where the primary server is unavailable. server/glue The protocol used for communication between SGD servers. For example, you can use this to find out why SGD servers cannot communicate. server/install Installation and upgrades. For example, you can use this to investigate problems with an installation. server/kerberos Windows Kerberos authentication. For example, you can use this to find out why an Active Directory user cannot log in. server/launch Starting or resuming applications. For example, you can use this to find out why a user cannot start an application. server/loadbalancing User session and application load balancing. For example, you can use this to find out why an SGD server is not selected to host application sessions. server/logging Logging. For example, you can use this to find out why log messages are not being written to a file. server/login Log in to SGD. For example, you can use this to find out which authentication mechanism authenticated a user and the user profile used. server/mupp The SGD MUltiplePlexing Protocol (MUPP) protocol. Only use this filter if Support ask you to. server/printing SGD printing services. For example, you can use this to find out why print jobs are failing. server/replication Copying data between SGD servers in an array. For example, you can use this to find out why data has not been copied between array members. server/securid Connections to SecurID RSA Authentication Manager. For example, you can use this to find out why SecurID authentication is not working. server/security Secure SSL-based connections. For example, you can use this to find out why the SSL Daemon is not running. server/server The SGD server component. For example, you can use this to troubleshoot SGD server failures, such as Java™ technology runtime exceptions which are not logged elsewhere. server/services Internal SGD server services. For example, you can use this to find out why a service is failing. server/session User sessions. For example, you can use this to find out why a session failed to suspend. server/soap SOAP bean interface. For example, you can use this to diagnose problems with the SOAP beans. server/soapcommands SOAP requests. For example, you can use this to log the SOAP requests received. server/tier3loadbalancing Application server load balancing. For example, you can use this to find out why an application server is not being selected to run an application. server/tokencache Authentication token cache. For example, you can use this to find out why an authentication token is not being created for a user. server/tscal Windows Terminal Services Client Access Licenses (CALs) for non-Windows clients. For example, you can use this to find out why a non-Windows client does not have a CAL. server/webtop Webtop content, if you are using Directory Services Integration. For example, you can use this to find out why an application is not appearing on a user’s webtop.

Selecting the Severity

You can select one of the following levels of severity for each log filter.

Severity Description fatalerror Logs information on fatal errors. Fatal errors stop the SGD server from running. When you first install SGD, all fatal errors are logged by default. error Log information on any errors that occur. When you first install SGD, all errors are logged by default. warningerror Log information on any warnings that occur, for example if system resources are running low. When you first install SGD, all warnings are logged by default. info Informational logging. Useful for problem solving and identifying bugs. moreinfo Verbose informational logging. auditinfo Logs selected events for auditing purposes, for example changes to SGD server configuration. For details see, Using Log Filters for Auditing.

The fatalerror severity level produces the least amount of information. The moreinfo severity level produces the most information.

Selecting a severity level is not cumulative. For example, selecting info does not mean you also see warningerror or fatalerror log messages.

To log more than one level of severity, use a wild card.

Using Wildcards

You can use a wildcard (*) to match multiple components, subcomponents, and severities.

For example, to log all warning, error, and fatal error messages for printing, you can use a server/printing/*error log filter.

Selecting a Destination

When selecting a destination for the logs, you can specify that the output goes to one of the following destinations:

• A log file

• A log handler

These destinations are described in the following sections.

Using Log Files

If you direct the output to a log file, you can output to the following types of file:

• filename.log

  SGD formats this log output so that it is easy to read.

  This format is required by the tarantella query errlog command. This command only searches log files that have names that end error.log.

• filename.jsl

  SGD formats this log output for automated parsing and searching.

  This format is required by the tarantella query audit command.

The file extension of the destination file controls the format of the file.

You can also create a separate log file for each process ID, by including the %%PID%% placeholder in the file name.

The log files are output in the /opt/tarantella/var/log directory. You cannot change the location of the log files, but you can use a symbolic link to redirect the logs to a different location. Alternatively, you can use the syslog log handler described in Using Log Handlers.

Using Log Handlers

A log handler is a JavaBeans component used as the destination for the log messages. When specifying a log handler, you must use its full name. SGD provides the following log handlers:

• ConsoleSink. The ConsoleSink log handler writes log messages in a easy-to-read format to standard error. This log handler is enabled by default and logs all fatal errors.

  The full name of this log handler is:

  .../_beans/com.sco.tta.server.log.ConsoleSink

• SyslogSink. The SyslogSink log handler writes log messages to the UNIX or Linux platform syslog facility.

  The full name of this log handler is:

  .../_beans/com.sco.tta.server.log.SyslogSink

Examples of Using Log Filters

The following are some examples of commonly used log filters:

• To debug user logins:

  server/login/*:login%%PID%%.log
  server/login/*:login%%PID%%.jsl

• To troubleshoot CDM:

  cdm/*/*:cdm%%PID%%.log
  cdm/*/*:cdm%%PID%%.jsl
  server/deviceservice/*:cdm%%PID%%.log
  server/deviceservice/*:cdm%%PID%%.jsl

• To troubleshoot printing problems:

  server/printing/*:print%%PID%%.log
  server/printing/*:print%%PID%%.jsl

• To get timing measurements for server performance:

  metrics/*/*info:metrics.log
  metrics/*/*info:metrics.jsl

• To send all warnings, errors, and fatal errors to syslog:

  */*/*error:.../_beans/com.sco.tta.server.log.SyslogSink

Viewing Log Output

To view the log output, you can do either of the following:

• Open the .log files in a viewer or text editor

• Use the tarantella query command

If you use the tarantella query command, use the following command options:

• tarantella query errlog – To see only the errors and fatal errors for specific SGD server components

• tarantella query audit – Searches the logs for any messages relating to a person, an application, or an application server

Using Log Filters for Auditing

SGD enables you to set log filters to provide an audit of the following system events:

• Starting and stopping an SGD server

• Starting and stopping SGD security services

• Changes to object configuration in the local repository

• Changes to global and SGD server configuration

• Unsuccessful attempts to log in to an SGD server

• Logging in and out of SGD

• Starting and stopping an application session

To audit these events, you must set a */*/*auditinfo log filter.

You can use any of the standard destinations as a destination for the output, but you must direct the output to a .jsl file if you want to view the audit information from the command line.

See Using Log Filters to Troubleshoot Problems With an SGD Server for more information about setting log filters.

For each of the events, the log filter records following:

• The date and time of the event

• The type of event

• The result of the event, whether it was successful or it failed

• The identity of the user responsible for the event

• Any other relevant information about the event, for example what was changed and to what value

Viewing Audit Log Information

You can use any of the standard methods for viewing the log output. However, the following command is the most useful:

# tarantella query audit --format text|csv|xml --filter "filter"

If you select the text format, SGD formats the log output so that it is easy to read on screen, but it does not show every detail logged. Using the csv format shows every detail logged, but it is only suitable for outputting to a file.

The "filter" is an RFC2254-compliant LDAP search filter. The command searches the log fields in the log files for matching entries to display. For auditing purposes, the most useful log fields are shown in the following table.

Log Field Description log-category For auditing purposes, the log-category is always *auditinfo, but this can be any of the standard log filter component/subcomponent/severity settings. log-date The system date and time when the event took place. The format is yyyy/MM/dd HH:mm:ss.SSS. log-event The name of the event. log-ip-address The IP address of a client or server associated with an event. log-keyword The keyword identifier for the auditable event. log-localhost The peer DNS name of the SGD server where the event took place. log-pid The process ID of the event. log-security-type The type of security used on a connection, std or ssl. log-systime The system Coordinated Universal Time (UTC) time, in milliseconds, when the event took place. log-tfn-name The full name of an object associated with an event. For example, starting an application session might record the name of the user, the application, and the application server.

The following table below shows all the log-keywords, and their corresponding log-events, together with a description of the event.

Log-Keyword Log-Event Description createFailure createFailure A user tried to create an object in the local repository but failed. createSuccess createSuccess A user created an object in the local repository. deleteFailure deleteFailure A user tried to delete an object in the local repository but failed. deleteSuccess deleteSuccess A user deleted an object in the local repository. loginFailure loginResultReconnect The SGD server requested the client to reconnect on a different port. loginFailure loginResultFailed None of the enabled authentication mechanisms authenticated the user. loginFailure loginResultRejected User was denied a login by a login filter. For example, this might be because logins are currently not enabled for that particular server, or because the user is currently not allowed to log in. loginFailure loginResultDisabled The SGD server is not currently accepting connections. loginFailure loginResultNoAmbig An ambiguous login failed because the SGD server does not support ambiguous logins. loginFailure loginResultAmbiguous An ambiguous login failed because the user did give enough disambiguation information. loginFailure loginResultAnonymous An anonymous login failed because the SGD server does not support anonymous logins. loginFailure loginResultNoSecurity Login failed because the user requires a secure connection, but the connection was made to the standard port. loginFailure loginResultUnresolveable Login failed because the SGD server was unable to resolve which user had logged in. loginFailure loginResultUnknown Login failed because the SGD server was unable to process an unexpected login result. loginSuccess webtopSessionStartedDetails Started a user session for a user. logout webtopSessionEndedDetails Stopped a user session for a user. modifyFailure modifyFailure A user tried to change an object in the local repository, to change global settings, or to change the configuration of an SGD server but failed. modifySuccess modifySuccess A user changed an object in the local repository, changed global settings, or changed the configuration of an SGD server. renameFailure renameFailure A user tried to rename an object in the local repository but failed. renameSuccess renameSuccess A user renamed an object in the local repository. serverStart serverStart The SGD server was started. serverStop serverStop The SGD server was stopped. sessionEnded sessionEndedDetails Stopped an application session for a user. sessionStarted sessionStartedDetails Started application session for a user. sslStart securitySSLStart Started SGD security (SSL) services. sslStop securitySSLStop Stopped SGD security (SSL) services.

Examples of Using Log Filters for Auditing

To search for failed log in attempts, use the following filter:

--filter "(&(log-category=*auditinfo)(log-keyword=loginFailure))"

To search for changes to made to the SGD server configuration by the Administrator Bill Orange, use the following filter:

 --filter "(&(log-category=*auditinfo)(log-keyword=modifySuccess)(log-tfn-name=.../ens/o=Indigo Insurance/ou=IT/cn=Bill Orange))"

Using Log Filters to Troubleshoot Problems With Protocol Engines

When you first install SGD, the default log filters record all errors for protocol engines (PEs). To obtain more information about PE activity, you can set additional PE log filters.

PE log filters can be set for individual PEs, and for the Protocol Engine Manager (PE Manager) process. You configure a PE log filter by setting one of the attributes shown in the following table.

PE Filter Attribute Protocol Engine --tarantella-config-auxserver-logfilter PE Manager --tarantella-config-execpeconfig-logfilter Execution Protocol Engine --tarantella-config-xpeconfig-logfilter X Protocol Engine --tarantella-config-tpeconfig-logfilter Character Protocol Engine --tarantella-config-ppeconfig-logfilter Print Protocol Engine --tarantella-config-cpeconfig-logfilter Channel Protocol Engine

You can only set a PE log filter from the command line. Use the following command:

$ tarantella config edit --PE-filter-attribute filter...

where PE-filter-attribute defines the PE filter attribute you want to configure, and filter defines the log filter. For multiple log filter definitions, use straight quotation marks to separate each filter parameter.

Each log filter has the form:

component/subcomponent/severity

The following table shows the available component names for PE logging.

Protocol Engine Component PE Manager pem proxy Execution Protocol Engine execpe launchhelper X Protocol Engine xpe pem Character Protocol Engine tpe pem Print Protocol Engine ppe pem Channel Protocol Engine cpe pem

For subcomponent, type * to include information on all subcomponents.

You can select the following levels of severity:

• * – Includes all error and warning messages.

• *info – Includes info, moreinfo, and auditinfo messages.

• *error – Includes error, fatalerror, and warningerror messages. This is the default severity.

Changes to the Execution, X, Character, Print, and Channel PE log filters take effect when a new PE is started.

Changes to the PE Manager log filters require an SGD server restart.

Examples of Using PE Log Filters

The following are some examples of how to use a PE log filter.

• To troubleshoot CDM for X and Windows applications:

  --tarantella-config-xpeconfig-logfilter "xpe/cdm/*"

• To troubleshoot problems with X and Windows applications:

  --tarantella-config-xpeconfig-logfilter "xpe/*/*" "pem/*/*"

• To troubleshoot application launches, you must first enable debugging in the SGD login scripts, as shown in An Application Does Not Start. Then, configure the Execution Protocol Engine log filter as follows:

  --tarantella-config-execpeconfig-logfilter "execpe/*/*"

PE Log File Destinations

PE log files have the file name extension .log. SGD formats this type of log output so that it is easy to read.

PE log file names include the name of the PE component and the process ID. For example, messages for a PE Manager running with process ID 4512 are stored to a file named pemanager4512.log.

Error messages with a severity of error, fatalerror, or warningerror are stored to a PE log file with a name that ends error.log. For example, error messages for a Character Protocol Engine running with process ID 2256 are stored to a file named cpe2256_error.log. Files such as this are used by the tarantella query errlog command, which only searches log files that have names that end error.log.

PE log filter output is directed automatically to log files in the /opt/tarantella/var/log directory on the SGD host. You cannot change the location of the log files, but you can use a symbolic link to redirect the logs to a different location.

Viewing PE Log Output

To view the PE logs, do either of the following:

• Open the .log files in a viewer or text editor.

  On each SGD server in the array, the .log files contain messages for PEs running on that specific SGD server.

• Use the tarantella query errorlog command to show error messages for PEs.

  This command can be used to search all PE error logs in the array.

  For example, to display X Protocol Engine error messages for all SGD servers in the array, use the following command:

  $ tarantella query errlog xpe

  For example, to display X Protocol Engine error messages for the SGD server boston.indigo-insurance.com, use the following command:

  $ tarantella query errlog xpe --server boston.indigo-insurance.com

Resetting a PE Log Filter

As log filters can create large amounts of data, it is good practice to reset the filter to its default configuration after you have finished with it.

The default PE log filter configuration sets a severity level of *error for all subcomponents of the PE component. The following table shows the default configuration for each log filter.

Protocol Engine Default Log Filter Configuration PE Manager pem/*/*error proxy/*/*error Execution Protocol Engine execpe/*/*error pem/*/*error launchhelper/*/*error X Protocol Engine xpe/*/*error pem/*/*error Character Protocol Engine tpe/*/*error pem/*/*error Print Protocol Engine ppe/*/*error pem/*/*error Channel Protocol Engine cpe/*/*error pem/*/*error

For example, to reset an X Protocol Engine log filter use the following command:

$ tarantella config edit \
--tarantella-config-xpeconfig-logfilter "xpe/*/*error" "pem/*/*error"

SGD Web Server Logging

SGD web server messages are recorded in the following logs:

• Tomcat JSP technology container logs

• Apache web server logs

Tomcat JSP Technology Container Logs

Log messages for the Tomcat JSP technology container component of the SGD web server are written to the following files in the /opt/tarantella/webserver/tomcat/tomcat-version/logs directory on the SGD host:

• catalina.out – This log file is rotated when full, or when the Tomcat JSP technology container is restarted, and the contents are appended to catalina.out.sav.

• localhost_log.date.txt – This is a daily log file, where date is the date that messages were recorded.

You can read these log files with a text editor.

The Tomcat JSP technology container log files can be used to diagnose problems with the following:

• Starting and stopping the Tomcat JSP technology container

• Starting the AJP 1.3 Connector

• Loading the SGD webtop web application

• Webtop JSP software exception errors

Logging properties for the Tomcat JSP technology container are configured in the /opt/tarantella/webserver/tomcat/tomcat-version/conf/logging.properties file. See the Tomcat documentation for details of how to configure logging for a Tomcat JSP technology container.

Apache Web Server Logs

Log messages for the Apache web server component of the SGD web server are written to the following files in the /opt/tarantella/webserver/apache/apache-version/logs directory on the SGD host:

• errors_log – Logs error messages for the Apache web server

• access_log – Logs all access requests processed by the Apache web server

You can read these log files with a text editor.

The Apache web server log files can be used to diagnose problems with the following:

• Starting and stopping the Apache web server

• Client requests for SGD webtop pages

• Web server authentication

See the Apache documentation for more details about these log files.

SGD Client Logging

By default, log messages for the SGD Client are stored to a file, tcc.txt, in the following locations on the client device:

• Microsoft Windows client devices. A user-specific writeable directory.

  On Microsoft Windows XP platforms, for example:

  C:\Documents and Settings\username\Local Settings\Temp\tcc\version

  On Microsoft Windows Vista platforms, for example:

  C:\Users\username\AppData\Local\Temp\tcc\version

  The actual location depends on the user’s privileges, the operating system, and the version of the Java Plugin tool being used.

• UNIX, Linux, or Mac OS X platform client devices. The user’s home directory:

  $HOME/.tarantella/tcc/version

Users can view the contents of this file with a text editor.

The SGD Client log file can be used to diagnose problems with the following:

• Starting the SGD Client and the SGD Client Helper

• Loading the SGD webtop page

• Client devices, such as CDM, printing, and smart card services

• Connections between the SGD Client and the SGD server

Users configure the logging level for SGD Client messages by changing the Logging Level setting in their client profile. The available logging levels, arranged in increasing level of verbosity, are:

• No Logging – Turns off SGD Client logging.

• Errors only – Records error messages. This is the default setting.

• Errors and Warnings only – Records error messages and warning messages.

• All – Records all messages, including error messages, warning messages, and information messages.

Client device information is shown on the Info -> Detailed Diagnostics page of the user’s webtop.

Administrators can use the Administration Console to view client device information for a user session. Select the user session in the User Session List table and click the View Details button to show more details.