3. Publishing Applications to Users
Configuring Microsoft Windows Application Servers for Printing
Configuring UNIX and Linux Platform Application Servers for Printing
Configuring an SGD Server for Printing
Configuring Printing to Microsoft Windows Client Devices
Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices
Users Cannot Print From Applications Displayed Through SGD
Troubleshooting Other Printing Problems
Setting Up Client Drive Mapping
Configuring UNIX and Linux Platform Application Servers for CDM
Configuring an NFS Share for CDM
Starting CDM Processes on the Application Server
Configuring Microsoft Windows Application Servers for CDM
Running UNIX Platform CDM With Another SMB Service
Configuring the Client Drives Available to Users
Configuring Microsoft Windows Application Servers for Audio
Configuring UNIX and Linux Platform Application Servers for Audio
Configuring X Applications for Audio
Configuring Client Devices for Audio
Troubleshooting Audio in Applications
Controlling Copy and Paste in Applications
An Example of Using Clipboard Security Levels
Tips on Configuring Copy and Paste
Copy and Paste Troubleshooting
Using Smart Cards With Windows Applications
Setting Up Access to Smart Cards
Configuring the Microsoft Windows Application Server for Smart Cards
Configuring Smart Card Readers on Client Devices
How to Log In to a Microsoft Windows Application Server With a Smart Card
Setting Up Access to Serial Ports
Configuring the Microsoft Windows Application Server
Enabling Serial Port Access in SGD
7. SGD Servers, Arrays, and Load Balancing
B. Secure Global Desktop Server Settings
Client drive mapping (CDM) enables SGD users to access the drives on their client device from applications running on UNIX, Linux, or Microsoft Windows platform application servers.
This section describes how to configure CDM for SGD users. Common problems when using CDM in SGD are also covered, along with tips on how to fix them.
This section includes the following topics:
Setting up CDM involves the following configuration steps:
Configure the application servers for CDM.
See Configuring UNIX and Linux Platform Application Servers for CDM.
The SGD Enhancement Module must be installed on the application server.
See Configuring Microsoft Windows Application Servers for CDM.
Enable CDM services in SGD.
Configure the drives you want users to access from SGD.
Configuring UNIX and Linux platform application servers for CDM involves the following steps:
Install the SGD Enhancement Module for UNIX and Linux Platforms.
The Oracle Secure Global Desktop 4.6 Installation Guide has details of how to install the Enhancement Module.
The Oracle Secure Global Desktop 4.6 Platform Support and Release Notes has details of the supported platforms for the SGD Enhancement Module.
Configure the Network File System (NFS) share to be used for CDM.
Start the CDM processes on the application server.
Configuring an NFS share for CDM involves the following:
Configuring a shared directory on the application server
Configuring how client drives are displayed on UNIX platforms
You must have an NFS server installed and running on the application server. The NFS server must share, or export, a directory to be used for CDM. By default, the directory is /smb. You have to manually create and export this directory.
You can specify an alternative NFS share in the CDM configuration file, /opt/tta_tem/etc/client.prf. Edit the [nfsserver/mount/mountpoint={(/smb)}] setting to reflect the name of the share.
The NFS share must be accessible to localhost, and users must have read and write access to it. Consult your system documentation for details of how to configure an NFS server and export a directory.
When CDM is enabled, the user’s client drives or file systems are available by default in the My SGD Drives directory in the user’s home directory. The My SGD Drives directory is a symbolic link to the NFS share that is used for CDM.
You can configure the name and location of the symbolic link by adding settings to the CDM configuration file, /opt/tta_tem/etc/client.prf, as follows:
The name of the symbolic link. This is configured with the following setting:
[nfsserver/user/symlinkname={(symlink)}]
The default setting is: My SGD Drives
For example, to change the name of the symbolic link to Client Shares, add the following line to the configuration file:
[nfsserver/user/symlinkname={(Client Shares)}]
The directory where the symbolic link is created. This is configured with the following setting:
[nfsserver/user/symlinkdir={(dir)}]
The default setting is: $HOME
For example, to create the symbolic link in the /tmp directory, add the following line to the configuration file:
[nfsserver/user/symlinkdir={(/tmp)}]
The directory can also be specified using environment variables. The variables you can use are controlled by the nfsserver/user/envvars setting.
For example, to create the symbolic link in the /tmp/username directory, add the following line to the configuration file:
[nfsserver/user/symlinkdir={(/tmp/$USER)}]
Environment variables for specifying the directory where the symbolic link is created. These are configured with the following setting:
[nfsserver/user/envvars={(var)...}]
The default setting is: (USER)(HOME)(LOGNAME)
Enclose each variable in parentheses. Do not include the dollar sign ($) before the variable name.
The variables in the list replace the default variables.
For example, to be able to use the HOME, USER, DISPLAY and TMPDIR variables, add the following line to the configuration file:
[nfsserver/user/envvars={(HOME)(USER)(DISPLAY)(TMPDIR)}]
After making any changes to the CDM configuration file, you must restart the
CDM processes on the application server. See Starting CDM Processes on the Application Server for details of how
to do this.
To start the CDM processes on the application server, log in as superuser (root) and use the following commands:
# /opt/tta_tem/bin/tem stopcdm # /opt/tta_tem/bin/tem startcdm
To use a Microsoft Windows application server for CDM, drive redirection must be enabled on the application server. Drive redirection is enabled by default.
This section describes how to enable CDM services for an array of SGD servers.
CDM can be enabled separately for applications that run on Microsoft Windows application servers (Windows CDM), and for applications that run on UNIX or Linux platform application servers (UNIX platform CDM).
By default, Windows CDM and UNIX platform CDM are disabled.
By default, you cannot use UNIX platform CDM and run a Server Message
Block (SMB) service, such as Samba, on the SGD host. See Running UNIX Platform CDM With Another SMB Service
for details of the required configuration if you want to use UNIX platform
CDM and run an SMB service on the SGD host.
When you enable CDM services, you can also enable or disable dynamic drive mapping. This feature provides support for “hot plugging” of removable drives, such as USB memory sticks, during a user session. Dynamic drive mapping is enabled by default for an SGD array.
Changes to CDM only take effect for new user sessions. Users might have to log out of SGD and log in again to access the drives on their client device.
In the Administration Console, display the Global Settings -> Client Device tab.
(Optional) Enable Windows CDM.
Select the Windows Client Drive Mapping check box.
(Optional) Enable UNIX platform CDM.
Select the Unix Client Drive Mapping check box.
Start UNIX platform CDM services on each server in the array.
Either restart all the SGD servers in the array, or use the tarantella start cdm command on each SGD server in the array.
If you restart the SGD servers, ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.
(Optional) Enable Dynamic Drive Mapping.
Dynamic drive mapping is enabled by default for an SGD array.
Select the Dynamic Drive Mapping check box.
In a default installation, you cannot use UNIX platform CDM and run another SMB service, such as Samba, on the SGD host. This is because they both use Transmission Control Protocol (TCP) port 139. To use CDM for UNIX and Linux platform applications, you must either disable the other SMB server or configure the host to enable more than one service to use TCP port 139.
To enable more than one service to use TCP port 139, you
have to configure the SGD host to have more than one Internet Protocol (IP)
address. To do this, either install another network interface card (NIC), or use
IP aliasing to assign multiple IP addresses to a single NIC. This is
described in How to Run UNIX Platform CDM and Another SMB Service on the Same Host.
Repeat this procedure for each SGD server that also has an SMB service enabled.
Ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.
Stop the SGD server and configure the IP addresses you want it to bind to for CDM.
Use the following command:
# tarantella config edit \ --tarantella-config-cdm-externalnbtaddress ip-address ...
The default setting for ip-address is *, which means bind to all interfaces. Separate each IP address with a space.
When you have configured the IP addresses, start the SGD server.
Configure the other SMB service, or services, to bind to a different IP address.
You configure the client drives you want users to access with the Client Drive Mapping attribute on the Client Device tab for user profiles, organizational unit, and organization objects. CDM uses inheritance. You define access to client drives at an organization level, which you can override at an organizational unit level or user profile level. By default, users have read and write access to all drives.
For Windows applications, you can configure application-specific client drive access with the Client Drive Mapping attribute on the Client Device tab for the Windows application object. This overrides any CDM settings configured for organization, organizational unit, or user profile objects. The order of precedence when configuring CDM for Windows application objects is: Windows application -> user profile -> organizational unit -> organization.
When a user logs in to an SGD server from a Windows client device, information is gathered about the drives on the client device. For each available drive, the Client Drive Mapping attribute on the user profile is checked. If there is no matching client drive configured, the parent organizational unit’s Client Drive Mapping attribute is checked, and so on up the organizational hierarchy to the organization object.
If a match is found, then the associated access rights are granted for that drive. The access rights for a mapped client drive are shown in brackets after the drive name: (rw)means read-write access, (ro) means read only access.
At each level in the organizational level, you configure a number of drive mapping specifications. Each of these states a client drive letter and the access rights to that drive. For example, you might specify that a user has read-write access to client drive A. The first matching entry in the list is used. Make sure the most specific settings, for example, A or B, appear before more general settings, for example, All Drives.
When a user logs in to an SGD server from a UNIX, Linux, or Mac OS X platform client device,
the SGD Client uses a local configuration file to configure access to the
client file system. See Configuring the Drives Available to UNIX, Linux, and Mac OS X Platform Client Devices for more details.
Note - Changes to client drive specifications only take effect for new user sessions.
By default, users with UNIX, Linux, and Mac OS X platform client devices have access to their home directory and this is mapped to a drive called My Home.
Users can configure which part of their client file system they can access from applications by editing the $HOME/.tarantella/native-cdm-config configuration file. This file is automatically created when the SGD Client is installed. The file contains detailed instructions for users on how to create mapped drives.
The [CDM] section of this configuration file contains entries of the form <path> <type> <label> where:
<path> is the absolute path name of the client file system.
<type> is either fixed, floppy, cdrom, remote or removable.
<label> is the name that is used in the application session.
Use a separate line for each drive and separate each of the fields with a space or a tab. If either the <path> or the <label> fields contains spaces or tabs, enclose the field in quotes.
You can use environment variables in the <path> or <label> fields. You delimit these with a dollar sign ($). To use a literal $, escape it with another $.
The following is an example configuration file:
[CDM] $HOME$ fixed "My Home" /tmp/$USER$ fixed Temp "/mnt/win/My Documents" fixed "My Local Documents" ... [/CDM]
Note - Changes to the native-cdm-config configuration file only take effect for new user sessions.
The access rights for a mapped client drive are shown in brackets after the drive name: (rw)means read-write access, (ro) means read only access.
The following example shows how to disable access to all client drives for all users in the Indigo Insurance organization. Only a single user in the organization, Ruby Port, is allowed to access the floppy drive on her Windows computer.
In the Administration Console, go to the Client Device tab and display the Client Drive Mapping table for the o=Indigo Insurance organization object. In the Client Drive Mapping table, select the check box next to All Drives. Click the Edit button and set the Access Rights to None. This disables access to all client drives.
In the Administration Console, go to the Client Device tab and display the Client Drive Mapping table for the Ruby Port user profile object. In the Client Drive Mapping table, click the New button and configure the following settings:
Client Device Drive. Select A:, the drive letter of Ruby’s floppy drive, or R/W Removable. R/W Removable matches all read-write removable drives, such as floppy drives.
Access Rights. Select Read/Write. This gives Ruby full access to the drive, as long as the floppy disk is not write-protected.
This gives Ruby Port full access to the floppy drive on her Windows computer.
If users attach a removable drive such as a Universal Serial Bus (USB) memory stick during a user session, SGD detects and mounts the device automatically. This feature is called dynamic drive mapping.
Dynamic drive mapping is enabled by default for an SGD array.
To use dynamic drive mapping, either Windows CDM or UNIX platform CDM must be enabled.
On UNIX and Linux platform client devices that do not use hardware abstraction layer (HAL) to detect client drives, SGD looks for removable drives by monitoring the locations listed in the [DYNAMICSTORAGE] section of the $HOME/.tarantella/native-cdm-config configuration file. Depending on the client platform, the following default system locations are listed in the [DYNAMICSTORAGE] section of this file.
|
You can specify additional directories to be monitored, by adding one or more entries to the [DYNAMICSTORAGE] section. For example, the following entry causes SGD to monitor the /opt directory for removable drives, in addition to the default location for the client platform.
[DYNAMICSTORAGE] ... /opt removable [/DYNAMICSTORAGE]
On Mac OS X client devices, virtual drives (.dmg files) are not detected as dynamic drives.
The following are common problems when using CDM in SGD:
Removable Drives Attached During a User Session are Not Detected Automatically
Invalid Password Errors on Microsoft Windows Application Servers
Use the following checklist to resolve this problem.
Is the SGD Enhancement Module installed on the application server?
To access client drives from UNIX or Linux platform applications displayed through SGD, the SGD Enhancement Module must be installed on the application server.
The Oracle Secure Global Desktop 4.6 Platform Support and Release Notes has details of the supported platforms for the SGD Enhancement Module.
Is UNIX platform CDM enabled?
In the Administration Console, go to the Global Settings -> Client Device tab and ensure that the Unix Client Drive Mapping check box is selected.
Remember, UNIX platform CDM services only become available when you restart all SGD servers in the array. To manually start CDM services without restarting the array, run the tarantella start cdm command on all members of the array.
Have the user’s client drives been configured correctly?
The Client Drive Mapping attribute on the Client Device tab for organization, organizational unit, and user profile objects determines which client drives each user can access. The user might be configured to have no access to any client drives. Remember to check the ancestor OUs in the organizational hierarchy. CDM settings are inherited, so you can give access to many users with one configuration change.
For Windows applications, application-specific client drive access can be configured using the Client Drive Mapping attribute on the Client Device tab for the Windows application object. Remember that this overrides any CDM settings configured for organization, organizational unit, or user profile objects.
For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If this file is not present, a default version is created automatically when the user next logs in to SGD.
Are UNIX platform CDM processes running?
On the host where SGD is installed, use the following command:
# ps -ef | grep ttacdmd
If UNIX platform CDM processes are running, there are at least two processes with the name ttacdmd.
If there are no any drive mapping processes, use the following command:
# grep cdm /opt/tarantella/var/log/*
Check the output for any messages.
On UNIX and Linux platform application servers, use the following command to check that CDM processes are running:
# /opt/tta_tem/bin/tem status
If CDM processes are not running, use the following command:
# /opt/tta_tem/bin/tem startcdm
If starting CDM processes produces errors such as "Failed to mount /smb", check that the NFS server is running and that the directory being used for CDM is exported correctly.
Check whether another service is using port 4242. If so, edit the /opt/tta_tem/etc/client.prf file and change the port number in the line [nfsserver/mount/port={(4242)}] and restart the CDM processes.
Are you using a proxy server?
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 between the client device and the SGD server and by default this is every 100 seconds. This connection is used for CDM. Try increasing the frequency of the keepalive packets.
See also Proxy Server Timeouts.
Do the version numbers for the SGD Enhancement Module and the SGD server match?
Run the following command on the host where SGD is installed:
$ tarantella version
Make a note of the version number.
On UNIX and Linux platform application servers, run the following command:
$ /opt/tta_tem/bin/tem version
Are other services using TCP port 139?
UNIX platform CDM services must bind to TCP port 139, which is used for SMB services. This port might already be in use, for example by a product such as Samba.
To find out whether any other process is using port 139, stop the SGD server and then run the following commands on the host where SGD is installed:
$ netstat -an | grep 139 $ grep 139 /etc/xinetd.conf
To ensure that UNIX platform CDM services are available, stop any other products that bind to TCP port 139 and restart the SGD server.
Follow the instructions in How to Run UNIX Platform CDM and Another SMB Service on the Same Host.
Have all the client drives been found?
For Windows client devices, the SGD Client displays information about the drives it has found. Click the right mouse button on the System Tray icon and select Connection Info.
For UNIX and Linux platform client devices, this information is written to the SGD Client log file.
For users with UNIX or Linux platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If a client drive is not being detected automatically, add an entry to the [CDM] section of this file to specify the location where the drive is mounted.
Does logging reveal any errors?
On UNIX or Linux platform application servers, check for any drive mapping errors in the clerr.log and the clPID.log files in the /opt/tta_tem/var/log directory.
See also Logging for CDM.
Is the drive mapping connection between the UNIX or Linux platform application server and the SGD server working?
On UNIX or Linux platform application servers, drive mapping errors are reported to
the clerr.log and the clPID.log files in the /opt/tta_tem/var/log directory. See also CDM Diagnostics for UNIX or Linux Platform Application Servers.
Use the following checklist to resolve this problem.
Is drive redirection enabled on the Microsoft Windows application server?
Drive redirection is enabled by default on Microsoft Windows application servers.
To access client drives from Windows applications displayed through SGD, the SGD Enhancement Module does not have to be installed on the application server.
Is Windows CDM enabled?
In the Administration Console, go to the Global Settings -> Client Device tab and ensure that the Windows Client Drive Mapping check box is selected.
Have the user’s client drives been configured correctly?
The Client Drive Mapping attribute on the Client Device tab for organization, organizational unit, and user profile objects determines which client drives each user can access. The user might be configured to have no access to any client drives. Remember to check the ancestor OUs in the organizational hierarchy. CDM settings are inherited, so you can give access to many users with one configuration change.
For Windows applications, application-specific client drive access can be configured using the Client Drive Mapping attribute on the Client Device tab for the Windows application object. Remember that this overrides any CDM settings configured for organization, organizational unit, or user profile objects.
For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If this file is not present, a default version is created automatically when the user next logs in to SGD.
Are Windows CDM processes running?
On Microsoft Windows application servers, use the Terminal Services Manager to check that there is an RDP session for the user.
Are you using a proxy server?
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 between the client device and the SGD server and by default this is every 100 seconds. This connection is used for CDM. Try increasing the frequency of the keepalive packets.
See also Proxy Server Timeouts.
Have all the client drives been found?
For Windows client devices, the SGD Client displays information about the drives it has found. Click the right mouse button on the System Tray icon and select Connection Info.
For UNIX and Linux platform client devices, this information is written to the SGD Client log file.
For users with UNIX or Linux platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If a client drive is not being detected automatically, add an entry to the [CDM] section of this file to specify the location where the drive is mounted.
Does logging reveal any errors?
On Microsoft Windows application servers, check the Windows Event Viewer for any drive mapping errors.
See also Logging for CDM.
Is the drive mapping connection between the Microsoft Windows application server and the SGD server working?
To check whether the drive mapping connection between the application server and the
SGD server is working, use the Terminal Services Manager on the Microsoft Windows
application server to check that there is an RDP session for the user.
See also CDM Diagnostics for Microsoft Windows Application Servers.
Check that dynamic drive mapping is enabled for the SGD array.
$ tarantella config list --array-dyndevice
By default, dynamic drive mapping is enabled.
To use dynamic drive mapping, CDM must be enabled for the array. Go to the Global Settings -> Client Device tab in the Administration Console and check that Windows Client Drive Mapping or Unix Client Drive Mapping is enabled.
The Client Drive Mapping attribute on the Client Device tab for organization, organizational unit, and user profile objects determines which client drives each user can access. The user might be configured to have no access to any client drives. Remember to check the ancestor OUs in the organizational hierarchy. CDM settings are inherited, so you can give access to many users with one configuration change.
For Windows applications, application-specific client drive access can be configured using the Client Drive Mapping attribute on the Client Device tab for the Windows application object. Remember that this overrides any CDM settings configured for organization, organizational unit, or user profile objects.
For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If a removable drive is not being detected automatically, add an entry to the [DYNAMICSTORAGE] section of this file to specify the location where the drive is mounted.
Check the SGD Client log file for information about whether attached drives have been detected correctly. Set the SGD Client logging level to All to log verbose messages about dynamic drive mapping.
If no client drives are mapped in the Microsoft Windows application session and you see errors such as Add device failed with ERROR_INVALID_PASSWORD in the CDM log output, this can be caused by the LAN Manager authentication level setting. The LAN Manager authentication level controls the authentication protocols used for communications between a client and Microsoft Windows server. If the authentication level is set too high, CDM fails.
The solution is to edit the Security options\Network security\LAN Manager authentication level policy and select Send LM & NTLM - Use NTLMv2 session security if negotiated.
See Microsoft KB article 823659 for more details.
See also Logging for CDM.
Client drives are inherited within the organizational hierarchy, so you can give access to many users with one configuration change. Check the Client Drive Mapping attribute on the organizational unit object that the user profile object belongs to. If necessary, check all ancestors of the user profile, including the top-level organization object. You can override a setting that is specified in a parent organizational unit (OU) or organization object, by configuring the user profile’s Client Drive Mapping attribute. The first matching drive specification is used.
For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries.
On Microsoft Windows client devices, client drives accessed through SGD are treated by the application server as network drives. This means that Recycle Bin features are not available for client drives.
Deleting a file does not send the file to the Recycle Bin. The Recycled directory, if present, is not shown as the Recycle Bin, and its contents are not displayed.
On Microsoft Windows client devices, the names of mapped drives are of the form clientdrive (access) on clientname. For example:
C (rw) on MYCOMPUTER
On UNIX, Linux, and Mac OS X platform client devices, the names of mapped drives are configured in the user’s $HOME/.tarantella/native-cdm-config file. Check that this file has valid entries.
On Unix or Linux platform application servers, access to client file systems is given to users based on their UNIX system user ID and standard NFS file system privileges. If a shared account is used to access applications, CDM is not available. This is because SGD has no way to distinguish between these users, as they all have the same user ID.
For security purposes, you may want to disable CDM for a client device.
To disable CDM for the client device, edit the <enablecdm> entry in the <localsettings> section of the client profile. A setting of 0 disables CDM.
Logging can be used to diagnose problems with CDM. You configure and use logging for the SGD array and for application servers, as follows:
Enable CDM logging for the SGD array
Use CDM diagnostics for Microsoft Windows application servers
Use CDM diagnostics for UNIX or Linux platform application servers
Use SGD Client logging for the client device
Add the following filters in the Log Filters field on the Monitoring tab of the Administration Console.
cdm/*/*:cdm%%PID%%.jsl cdm/*/*:cdm%%PID%%.log server/deviceservice/*:cdm%%PID%%.log server/deviceservice/*:cdm%%PID%%.jsl
On Microsoft Windows application servers, drive mapping errors are written to the Windows Event Viewer.
On UNIX or Linux platform application servers, drive mapping errors are reported to the clerr.log and the clPID.log files in the /opt/tta_tem/var/log directory.
By default, the SGD Client logs any warning messages about client drives. Log messages are stored to a file, tcc.txt on the client device.
To record detailed information about CDM, set the SGD Client logging level to
All. See SGD Client Logging for more information about configuring and using SGD Client logging.
For Windows client devices, the SGD Client displays information about the drives it has found. Click the right mouse button on the System Tray icon and select Connection Info. CDM information is written to the SGD Client log file.
For UNIX and Linux platform client devices, CDM information is written to the SGD Client log file.