| Exit Print View | |
Oracle Secure Global Desktop Administration Guide for Version 4.6 |
|
|
|
|
3. Publishing Applications to Users
Configuring Windows Application Objects
Creating Windows Application Objects on the Command Line
Configuring Microsoft Windows Terminal Services for Use With SGD
Licensing Microsoft Windows Terminal Services
Microsoft Windows Remote Desktop
Key Handling for Windows Terminal Services
Returning Client Device Information for Windows Terminal Services Sessions
Running Windows Applications on Client Devices
Configuring X Application Objects
Configuring Character Application Objects
Terminal Emulator Keyboard Maps
Terminal Emulator Attribute Maps
Integrating SGD With Oracle VDI
Enabling X11 Forwarding for X Applications
Using SSH and the X Security Extension
Configuring Application Authentication
The Application Server Password Cache
Input Methods and UNIX Platform Applications
Adding Support for System Prompts in Different Languages
Using RSA SecurID for Application Authentication
Tips on Configuring Applications
Starting an Application or Desktop Session Without Displaying a Webtop
Using Multihead Or Dual Head Monitors
Improving the Performance of Windows Applications
Improving the Performance of Java Desktop System Desktop Sessions or Applications
Documents and Web Applications
Configuring Common Desktop Environment Applications
An Application Exits Immediately After Starting
Applications Fail To Start When X Authorization Is Enabled
Applications Disappear After About Two Minutes
An Application Session Does Not End When the User Exits an Application
Users Can Start Applications With Different User Names and Passwords
Using Windows Terminal Services, Users Are Prompted for User Names and Passwords Too Often
Using Shadowing to Troubleshoot a User's Problem
A Kiosk Application Is Not Appearing Full-Screen
An Application's Animation Appears 'Jumpy'
Font Problems with X Applications
Display Problems With High Color X Applications
Clipped Windows With Client Window Management Applications
Display Update Issues When Shadowing Over a Low Bandwidth Connection
7. SGD Servers, Arrays, and Load Balancing
B. Secure Global Desktop Server Settings
This section describes some typical problems that users might have with their applications, and how to fix them.
To troubleshoot problems with starting and ending applications, see the following:
An Application Session Does Not End When the User Exits an Application
Users Can Start Applications With Different User Names and Passwords
Using Windows Terminal Services, Users Are Prompted for User Names and Passwords Too Often
To troubleshoot problems with using applications, see the following:
If an application does not start when a user clicks a link, first
check the configuration of the application object, see Checking the Configuration of the Application Object.
If this does not resolve the problem, check the launch details or the
log files for a launch error message, see Checking the Launch Details and Error Logs.
If users cannot log in to SGD or start applications, do a warm restart of the SGD servers by running the following command:
# tarantella restart sgd --warm
Check the configuration of the application object in the Administration Console.
First, check the Hosting Application Servers tab for the application object. You must specify at least one application server to run the application. Check that the listed application servers are available.
Next, check the Launch tab for the application object. Check the attributes shown in the following table.
|
If the application object is configured correctly, check that the application itself actually runs on all the application servers.
When an application fails to start, SGD displays an error message in the details area of the Connection Progress dialog. The error message is output to the SGD Client log file (tcc.txt) in the user’s home directory.
The error messages are also output to the following log files:
/opt/tarantella/var/log/execpePID_error.log
This file contains log output from the Execution Protocol Engine process.
/opt/tarantella/var/log/launchhelperPID_error.log
This file contains additional log output if the connection method for the application object is SSH.
The error messages have the following form:
ErrorMessage Script process-id exited with code error-code and signal signal
The ErrorMessage and error-code can be used to troubleshoot problems. The following are the most common error messages:
ErrApplicationServerTimeout
ErrApplicationServerLoginFailed
For a complete list of error messages and codes and troubleshooting information, see
Login Script Error Messages.
If the launch details or log files show error messages such as “Failed to find xauth“
or “Attempt to run xauth failed”, see Applications Fail To Start When X Authorization Is Enabled.
If you are still unable to resolve the problem, you can increase the amount of information that is output to the log files. To do this, you amend the log filters for the Execution Protocol Engine, and, for X and character applications only, enable debugging in the login script.
To amend the log filter for the Execution Protocol Engine, use the following command:
$ tarantella config edit \ --tarantella-config-execpeconfig-logfilter \ "execpe/*/*" "pem/*/*" "launchhelper/*/*"
To enable debugging in the login scripts, edit the following files:
The login script configured for the application object.
Remove the comment mark (#) from the start of the startdebug line.
The login script is usually either unix.exp, securid.exp, vms.exp, unixclass.exp, or pupil.exp.
procs.exp
Insert a comment mark (#) at the start of the stopdebug line.
When you have resolved the problem, remember to reset the log filter for the Execution Protocol Engine back to the default, and disable logging in the login scripts. Use the following command to reset the log filter:
$ tarantella config edit \ --tarantella-config-execpeconfig-logfilter \ "execpe/*/*error" "pem/*/*error" "launchhelper/*/*error"
If starting an application results in an ErrApplicationServerTimeout error, this usually means a login script has timed out before it can log the user in.
You can fix this by increasing the login script timeouts. See Login Script Timeouts for
details of the available timeouts.
When changing the timeouts, increase the Expect timeouts first. If the application still fails to start, one of the client timers might be too short. If the application is particularly slow to start, increase all the client timers.
Increasing the login script timeouts slows down application start times. Only change the timeouts if you are experiencing problems, and tune the timeouts to the capabilities of the application server.
Note - None of the timeouts, apart from the Execution Protocol Engine timeout, apply when running a Microsoft Windows application.
If starting an application results in an ErrApplicationServerLoginFailed error, the login script failed to log into the application server.
Check that you can log into the application server manually.
If you can log in, check that the application server’s system prompt is recognized by the login script. Unusual system prompts are a common reason for this failure, and can be caused by the following:
System prompts in a language other than English
Message-of-the-day (/etc/motd) or issue messages (/etc/issue)
The user’s login profile is configured to run a menu
By default, SGD supports English system prompts on application servers. Administrators can add
support for system prompts in other languages. See Adding Support for System Prompts in Different Languages for details.
If you are using the standard SGD login scripts, check the system prompts defined in the vars.exp login script.
If a message-of-the-day or a menu causes a login script to fail, you must configure the login script to handle this situation. Alternatively, contact Technical Support for help.
The login script might also be timing out. If you see “echo SYNC”
in the launch details or log files, and the system prompt ends in
the normal way with $, %, #, or >, try increasing the timeouts(prelogin) value in
the vars.exp login script. See Expect Timeouts for details.
Users might see this problem with X applications. The solution is to keep open the network connection used to start the application.
In the Administration Console, select the Keep Launch Connection Open check box on the Launch tab for the application object.
Alternatively, use the following command:
$ tarantella object edit --name obj --keepopen true
In a default SGD installation, X authorization is enabled. If there are any problems with X authorization, users cannot start applications. If applications fail to start because of X authorization, the message “Failed to find xauth” or “Attempt to run xauth failed” displays in the application launch details and in the log files.
Use the following checklist to establish why X authorization causes application to fail
to start. If this does not resolve the issue, check the log files
as described in Checking the Launch Details and Error Logs.
Is X authorization installed on the application server?
For SGD to be able to use X authorization, xauth must be installed on every application server.
If xauth is not installed, you must either install it or disable the use of X authorization for every application. To disable X authorization, deselect the X Authorization for X Display check box on the Global Settings -> Security tab in the Administration Console.
Can SGD find the xauth binary?
If the message “Failed to find xauth” displays in the application launch dialog or log files, SGD cannot find the xauth binary. By default, SGD searches the following locations for the xauth binary:
/usr/bin/X11/xauth
/usr/X/bin/xauth
/usr/X11R6/bin/xauth
/usr/bin/X/xauth
/usr/openwin/bin/xauth
/usr/bin/xauth
If the xauth binary is in a different location, you must add its location to the /opt/tarantella/var/serverresources/expect/vars.exp login script. Look for the line beginning “set xauthcmds”.
Note - If the xauth binary is only in one location, you can speed up application launches by removing the other locations from the vars.exp login script.
Does the user have a UNIX system account on the application server?
When the user starts an application, the X Protocol Engine process generates a cookie and stores it in the .Xauthority file in the user’s home directory on the application server. The cookie is used to validate whether or not the user has permission to connect to the X display.
If the user does not have a home directory, the cookie cannot be stored in the user’s .Xauthority file and so the user cannot be validated.
You can do any of the following:
Create a home directory for the user on the application server
Disable X authorization
Deselect the X Authorization for X Display check box on the Global Settings -> Security tab in the Administration Console. Alternatively, use the following command:
$ tarantella config edit --security-xsecurity 0
Edit configuration files on the application server, so that the cookie is stored in a temporary directory.
Add the following lines to the /etc/profile file on the application server:
XAUTHORITY=/tmp/.Xauthority.$LOGNAME export XAUTHORITY
Create the following SSH daemon configuration file, /etc/ssh/sshrc, on the application server:
HOME=/tmp
XAUTHORITY=$HOME/.Xauthority.$USER
export XAUTHORITY
if read proto cookie && [ -n "$DISPLAY" ]
then
if [ ‘echo $DISPLAY | cut -c1-10‘ = ’localhost:’ ]
then
# X11UseLocalhost=yes
echo add unix:‘echo $DISPLAY |
cut -c11-‘ $proto $cookie
else
# X11UseLocalhost=no
echo add $DISPLAY $proto $cookie
fi | /usr/openwin/bin/xauth -q -
fiIf users find that their applications disappear unexpectedly after about two minutes, a proxy server might be timing out the connections. Proxy servers drop a connection after a short period of time if there is no activity on the connection.
SGD sends keepalive packets to keep the connection open and by default this is every 100 seconds. If applications are disappearing, you can increase the frequency at which keepalive packets are sent to keep the connection open.
In Administration Console, go to the Global Settings -> Communication tab for the application object and set the AIP Keepalive Frequency to a smaller value than the default, for example, 60.
Alternatively, use the following command:
$ tarantella config edit --sessions-aipkeepalive secs
Note - You must restart every SGD server in the array for changes to this attribute to take effect.
If an application does not end when a user closes down the application,
first check the configuration of the application object, see Checking the Session Termination Setting.
To troubleshoot problems with Windows applications, see Windows Applications Do Not Close Down.
To troubleshoot problems with UNIX desktop sessions, see UNIX Desktop Sessions Do Not Close Down After Logging Out.
In the Administration Console, go to the Launch tab for the application object and check the value of the Session Termination attribute.
If No Visible Windows is selected, the application session ends when there are no visible windows.
When running an application on a Microsoft Windows Terminal Server, closing the application does not always result in the session closing. This is because the SGD Enhancement Module for Windows is still running. The solution is to configure the SGD Enhancement Module to ignore certain system processes so that it closes. To do this, edit the System processes value for the HKEY_LOCAL_MACHINE\Software\Sun Microsystems, Inc.\Enhancement Module for Windows key in the registry on the application server. This value is a string that contains a comma-separated list of .exe binaries that the SGD Enhancement Module can ignore. You must amend this value by listing the processes that were running when the session failed to close. To do this, open Task Manager, while you have a session that has failed to close, and go to the Processes tab. Make a list of all the .exe processes that are running. Do not include the following processes:
clipsrv.exe
conime.exe
csrss.exe
EventLog.exe
lmsvcs.exe
lsass.exe
MsgSvc.exe
nddeagnt.exe
netdde.exe
NETSTRS.EXE
os2srv.exe
proquota.exe
rdpclip.exe
screg.exe
smss.exe
spoolss.exe
ttaswm.exe
userinit.exe
wfshell.exe
win.com
winlogon.exe
If you are running a single application session, you might find that the session still does not exit, even after editing the System processes registry setting. To force the session to exit, amend the Logoff application sessions setting for the HKEY_LOCAL_MACHINE\Software\Sun Microsystems, Inc.\Enhancement Module for Windows key and change the DWORD value to 1.
X applications configured as a full-screen desktop session might not close down when you log out from the application using the desktop Start menu. For example, desktop applets can remain open after logging out from the application. The application then has to be closed down using the pull-down header in the application window.
The workaround is to modify the Application Command (--app) attribute for the X application object, so that the TTA_SESSION_STATE property is removed from the root window when the application is closed down.
The following example shows how to modify the Application Command for a Java Desktop System desktop session.
Create a simple shell script as follows:
#! /bin/sh /usr/dt/config/Xsession.jds /usr/openwin/bin/xprop -root -remove TTA_SESSION_STATE
Save the script to a location on the SGD server, for example /usr/local/bin/launch.sh.
In the Administration Console, go to the Launch tab for the X application object and edit the Application Command field to use the path to the script.
Alternatively, use the following command:
$ tarantella object edit --name objname --app "/usr/local/bin/launch.sh"
By default, users can force SGD to display the Application Authentication dialog by holding down the Shift key when they click an application’s link on the webtop. This enables users to start applications with different user name and passwords.
Note - You cannot use Shift-click with the SGD Client when it is in Integrated mode.
You can disable the Shift-click behavior. In the Administration Console, go to the Global Settings -> Application Authentication tab and deselect the On Shift-Click check box. Alternatively, use the following command:
$ tarantella config edit --launch-showauthdialog system
Disabling the Shift-click behavior means that the Application Authentication dialog only displays when there is a problem with the password or there is no password.
If you are using Windows Terminal Services, users might be prompted for a user name and password by SGD or by the Terminal Server.
If SGD always prompts the user for a user name and password, the problem is usually caused by a missing domain name. If the user has no entries in the password cache that have a domain name, the Application Authentication dialog is displayed.
To fix this problem, the domain name must be provided when saving details in the password cache. You must do this even if the application server is not part of a domain.
The easiest way to configure the domain name is with the Domain Name
attribute on the application server object or the application object. Users can also
provide their own domain names in the Application Authentication dialog. See Windows Domains and the Password Cache.
SGD sends user name and password information to Windows Terminal Services to authenticate the user. If the authentication fails, Windows prompts the user again. No information is returned to SGD indicating whether authentication succeeds or fails, and the details remain in the SGD password cache whether correct or incorrect.
The user might have saved the wrong user name, password or domain name in the password cache.
To fix, the user must press Shift when clicking the link to start, the application. This displays the Application Authentication dialog, and the user can correct their user name, password, and domain name. Alternatively, delete the user’s entry in the password cache so that SGD prompts the user the next time they start the application.
The Terminal Server might also be configured to always prompt for a password
when a user logs in. Microsoft Windows 2000 Server does this by default,
but Microsoft Windows Server 2003 and later does not. See Authentication Settings for details on
how to change this behavior.
If a user is having difficulty with an application, you can use the Administration Console to find the user’s application session and then shadow it. Shadowing enables the user and an SGD Administrator to see and use the application simultaneously.
To find a user’s application session, go to the Application Sessions tab for their user profile object. Alternatively, go to the Application Sessions tab for the application object. This lists the users who are currently running the application.
Select the application session in the Application Sessions List table. Click the Shadow button to commence shadowing.
The user sees a dialog box, asking whether to allow you to shadow the session. If the user agrees, a new window appears on your screen, showing the running application. Both you and the user can control the mouse pointer and use the application.
When you have fixed the user’s problem, close the shadowing window, but do not close the application. The user sees a dialog box, saying that nobody is currently shadowing the session.
The Application Sessions tab shows other application session information, such as the date and time the session started, and whether the session is suspended or currently active.
You can only shadow Windows applications and X applications. The application must not be suspended.
If the user has application sessions for two or more applications that are using shared resources, all applications that are sharing resources are displayed when you shadow the session. The button bar on the shadowing window enables you to toggle between the applications.
You can also shadow a user’s session from the command line, using the tarantella emulatorsession shadow command.
If you are shadowing over a low bandwidth connection and have display update
problems, see Display Update Issues When Shadowing Over a Low Bandwidth Connection for details of how to fix this.
If an application that is configured to display in a kiosk window is resumed on a display that is larger or smaller than the original display, the application no longer fits the screen exactly.
The solution is to ensure that SGD scales the kiosk window to fit the screen.
In the Administration Console, go to the Presentation tab for the application object and set the Window Size to Scale to Fit Window.
Alternatively, use the following command:
$ tarantella object edit --name obj --scalable true
Changing an application object’s performance settings can improve the display of animation effects in the application session.
In the Administration Console, go to the Performance tab for the application object and set the Command Execution attribute to In Order. Deselect the Delayed Updates check box.
Alternatively, use the following command:
$ tarantella object edit --name obj \ --execution inorder --delayed false
If users see font problems with X applications, check the following:
Is the font size wrong?
In the Administration Console, go to the Client Device tab for the X application object and check the value of the Monitor Resolution attribute. Display the Protocol Engines -> X tab for each SGD server in the array and check the value of the Monitor Resolution attribute.
The Monitor Resolution attributes are used to specify the monitor resolution, in dots per inch, that SGD reports to X applications that ask for this information. Some X applications need this value to determine what font size to use.
The default resolution can cause the X application to choose a font size larger than it normally chooses. If this happens, try reducing the resolution by specifying a smaller value, for example, 75.
Are the wrong fonts displayed?
In the Administration Console, go to the Protocol Engines -> X tab for each SGD server in the array and check that the Font Path attribute is correct.
Some X Fonts are supplied with SGD. You can also configure your own X
fonts. See How to Configure SGD to Use Your Own X Fonts.
Several problems can occur when displaying high color X applications:
If an X application fails to run and exits with errors such as “Cannot Allocate Enough Color Planes”, the application probably only displays 8-bit color. Check the display specification of the application and adjust the color depth of the application object.
In the Administration Console, go to the Presentation tab for the application object and set the Color Depth to 8-bit - 256 colors.
Alternatively, use the following command:
$ tarantella object edit --name obj --depth 8
If there are any problems with appearance in 16-bit or 24-bit color applications, change the color quality of the application object.
In the Administration Console, go to the Performance tab for the application object and set the Color Quality to 16-bit, for 16-bit applications, or 24-bit, for 24-bit applications.
Alternatively, use the following command:
$ tarantella object edit --name obj --quality 16 | 24
If bandwidth is critical, try reducing the color quality of the application object.
In the Administration Console, go to the Performance tab for the X application object and set the Color Quality to 9-bit, or 6-bit.
Alternatively, use the following command:
$ tarantella object edit --name obj --quality 9 | 6
Note - There is no absolute guarantee of a bandwidth saving when you make this configuration change. Also, the appearance of the application might be affected adversely.
If you run an 8-bit application within a 16-bit or 24-bit high color X application session, for example from a CDE desktop, you might find the application exits with an error such as "Cannot find a matching 8-bit PseudoColor visual".
To fix this, change the color depth of the X application so that it supports multiple color depths.
In the Administration Console, go to the Presentation tab for the X application object and set the Color Depth to 16/8-bit - Thousands of Colors, or 24/8-bit - Millions of Colors.
If the 8-bit application requires the primary color depth to be 8-bit, set the Color Depth to 8/16-bit - Thousands of Colors, or 8/24-bit - Millions of Colors.
Alternatively, use the following command:
$ tarantella object edit --name obj --depth 16/8 | 24/8
Note - There are memory and performance effects of using these settings.
If the application still exits after changing the color depth, a workaround is to create a separate X application object for the application and set the color depth to 8-bit.
If users see clipped windows when using X applications that are configured to use Client Window Management, this means that users have displays with a greater resolution than expected.
The solution is to increase display resolution for the X Protocol Engine.
In the Administration Console, go to the Protocol Engines -> X tab for each SGD server in the array and change the Client Window Size settings. In the Maximum Height and Maximum Width fields, type the highest display resolution you expect to support.
Note - Increasing the Maximum Width and Maximum Height attributes increases the memory requirements for Client Window Management applications on both client devices and SGD servers.
Alternatively, use the following command:
$ tarantella config edit --array \ --xpe-cwm-maxwidth pixels \ --xpe-cwm-maxwidth pixels
Some applications accept input from the left-hand keypad on a Sun workstation. To emulate these keys using Shift-Function key strokes on the client device, you must use a custom keymap file.
Log in to SGD as root (superuser) and make a copy of the xuniversal.txt keymap file. This file is located in the /opt/tarantella/etc/data/keymaps directory on the SGD server. Rename the file to xsunkey.txt.
Edit the Function key definitions in the xsunkey.txt file, as follows:
112 F1 Cancel NoSymbol NoSymbol 0x3b 113 F2 Redo NoSymbol NoSymbol 0x3c 114 F3 0x1005ff70 NoSymbol NoSymbol 0x3d 115 F4 Undo NoSymbol NoSymbol 0x3e 116 F5 0x1005ff71 NoSymbol NoSymbol 0x3f 117 F6 0x1005ff72 NoSymbol NoSymbol 0x40 118 F7 0x1005ff73 NoSymbol NoSymbol 0x41 119 F8 0x1005ff74 NoSymbol NoSymbol 0x42 120 F9 Find NoSymbol NoSymbol 0x43 121 F10 0x1005ff75 NoSymbol NoSymbol 0x44 122 F11 Help NoSymbol NoSymbol 0x57
This maps the client device Function keys to Sun workstation keys, as shown in the following table.
|
On the application server that runs the application, add the following line to the /usr/dt/lib/bindings/xmbind.alias file:
"Sun Microsystems, Inc." sun
In the Administration Console, go to the Client Device tab for the user profile object. Select the Custom Value option for the Keyboard Map attribute and type xsunkey.txt in the field.
Alternatively, use the following command:
$ tarantella object edit --name obj --keymap xsunkey.txt
Note - The new keyboard map is used for all graphical applications for the specified user.
Display update issues might be seen when shadowing a user who has a low bandwidth connection to SGD.
The solution is to increase the X Protocol Engine queue length and optimize command execution, as follows:
In the Administration Console, go to the Protocol Engines -> X tab for each SGD server in the array and type -mql 8192 in the Command-Line Arguments field.
Alternatively, use the following command:
$ tarantella config edit --xpe-args "-mql 8192"
The changes made take effect for new X Protocol Engines only. Existing X Protocol Engines are not affected.
In the Administration Console, go to the Performance tab for the shadowed application and set the Command Execution attribute to Optimized.
Alternatively, use the following command:
$ tarantella config edit --name obj --execution optimized
The changes made take effect when you next start the shadowed application.
Mouse drag delay issues can result in a poor user experience when using drawing applications.
The solution is to reduce the mouse drag delay setting for the SGD Client. Add a new <mousethrottledelaywithbutton> entry in the <localsettings> section of the user’s client profile. If the <localsettings> section is not present in the client profile, create a new section.
For example, to set the mouse drag delay to 10 milliseconds, type the following:
<localsettings> <mousethrottledelaywithbutton>10</mousethrottledelaywithbutton> ... <localsettings>
The default value for mouse drag delay is 100 milliseconds.
Changes to client profiles only take effect for new user sessions.
When time zone redirection is enabled on a Windows application server, the time zone name shown in Windows applications can sometimes be incorrect. The issue is seen when displaying Windows applications on UNIX platform client devices.
The solution is to manually set the $TZ time zone environment variable on the client device to the correct value for the user’s location. The tzselect command can be used to list the possible time zone values for a geographical location.
See Time Zone Redirection for more details about using time zone redirection with Windows application
servers.
|
|