This section describes the features that are new in the SGD version 4.60 release.
This release supports automatic recovery of an array after failover.
In version 4.50, the original primary server did not rejoin the array after failover and you had to manually recreate the original array formation. In this release, the original array formation is recreated automatically by default.
The process of failover, followed by recovery of the original array formation is called array resilience. The new Global Settings, Resilience tab in the SGD Administration Console is used to configure array resilience.
See the Oracle Secure Global Desktop 4.6 Administration Guide for more details about array resilience.
Dynamic launch is the term used to describe runtime changes that are applied when users start applications. Typically, the runtime changes enable users to select the application server that runs the application, or to choose the application that is started, or both.
The following new object types have been introduced for dynamic launch:
Dynamic application servers
Dynamic applications
The tarantella object new_host command has been extended to include support for creating dynamic application server objects.
The following commands have been introduced to create and configure dynamic application objects:
tarantella object new_dynamicapp
tarantella object add_mapping
tarantella object remove_mapping
Client overrides have been extended to support dynamic launch features, such as password caching.
See the Oracle Secure Global Desktop 4.6 Administration Guide for more details about how to configure dynamic launch.
Version 4.6 contains significant enhancements and performance improvements for integrating SGD with Active Directory and Lightweight Directory Access Protocol (LDAP) directories.
For Active Directory and LDAP directories, there are enhancements to how SGD handles password expiry. SGD can now be configured to do the following:
Display a warning message on the webtop, telling the user that their password is about to expire
Deny authentication and force the user to reset their password at the next log in
For Active Directory, the following enhancements can be used to tune how SGD discovers LDAP information:
Site awareness – If SGD detects, or is configured with, site information, it queries only the Active Directory servers appropriate for the site.
Whitelist – A whitelist is a list of global catalog servers that are always used for LDAP queries. Only those servers that are included in the whitelist can used for LDAP queries.
Blacklist – A blacklist is a list of Active Directory servers that are never used for LDAP queries. Blacklists override any other configuration such as sites or whitelists.
Search only global catalog – SGD searches for user information only from the global catalog instead of contacting a domain controller.
Other configuration settings are also provided for tuning connections to Active Directory and LDAP directories.
In previous releases, Active Directory or LDAP configuration settings applied globally. In this release, service objects have been introduced to provide more flexibility. A service object is a group of directory services configuration settings that can be applied to one or more LDAP directories or Active Directory forests. You can create and manage service objects on the Global Settings, Service Objects tab in the SGD Administration Console, or with the new tarantella service command. The Administration Console only enables you to configure the commonly-used settings.
Most of the command-line options for filtering user logins and tuning LDAP group searches have changed. It is also now possible to filter (deny or allow) user logins based on the membership of LDAP groups.
Options have been added to the tarantella
cache command to improve the caching of LDAP group
data. The --populate
option
adds LDAP group and LDAP group membership information to the
cache. The --refresh
option
updates the cache with the current membership of LDAP groups.
See the Oracle Secure Global Desktop 4.6 Administration Guide for details of how to use service objects to tune directory services configuration.
This release includes support for “hot plugging” of removable storage devices during a user session. This feature is called dynamic drive mapping.
Dynamic drive mapping is enabled by default for an SGD server.
To disable or enable dynamic drive mapping, use the Dynamic
Drive Mapping
(--array-dyndevice
)
attribute.
The native-cdm-config
file used to
configure the available drives on
UNIX® and Linux
platform client devices now includes a list of default system
locations which are monitored for removable drives. Users
upgrading from earlier versions of SGD must rename their
existing native-cdm-config
file before
connecting to the upgraded SGD server. A new
native-cdm-config
file containing the
default system locations is created automatically when the SGD
Client first connects to the upgraded server. Any custom
configuration present in the backed up file can be merged with
the new file.
See the Oracle Secure Global Desktop 4.6 Administration Guide for more details about array resilience.
In this release, client drive mapping (CDM) for Windows applications is implemented using Remote Desktop Protocol (RDP) instead of the Server Message Block (SMB) protocol. As a result, you do not need to install the SGD Enhancement Module on the Windows application server to provide CDM services. Application server drive letters are no longer displayed when using CDM for Windows applications.
Windows CDM is now enabled separately from CDM for UNIX platform
applications. Two new attributes, Windows Client Drive Mapping
(--array-windowscdm
) and Unix Client Drive
Mapping (--array-unixcdm
) have been introduced
for this. The attributes apply to all SGD servers in the array.
A restart of CDM is not required when configuring CDM for Windows applications. Consequently, the tarantella start cdm and tarantella stop cdm commands are now only applicable to CDM for UNIX platform applications.
Ports used for connections between SGD servers and application servers have changed as follows:
TCP Port 139 was previously used for all CDM services. This port is now only used for CDM for UNIX platform applications.
TCP Port 137 is no longer used by SGD.
The following CDM attributes have been deprecated for this release:
Client Drive Mapping (--array-cdm
)
Windows Internet Name Service (WINS)
(--array-cdm-wins
)
Fallback Drive Search
(--array-cdm-fallbackdrive
)
New attributes have been introduced to configure Windows applications. The attributes correspond to command options for the SGD Remote Desktop Client, also known as the ttatsc command.
Previously, ttatsc command options were
configured using the Arguments for Protocol
(--protoargs
) attribute of
the Windows application object. This method is still supported
for those ttatsc options that do not have a
corresponding Windows application attribute.
See the Oracle Secure Global Desktop 4.6 Administration Guide for more details about the new attributes and their equivalent ttatsc command options.
New application server object attributes for filtering application servers have been introduced.
The Maximum Count
(--maxcount
) attribute
specifies the maximum number of SGD application sessions that
can be run concurrently on the application server.
The User Assignment
(--userassign
) attribute
specifies the users that can run applications on the application
server.
These attributes can be used individually or together to control the application servers that can run an application for a user.
SGD now supports 32-bit color depths in a Windows Terminal Server session.
32-bit color is available on Windows Vista, Windows Server 2008, Windows Server 2008 R2, and Windows 7 platforms. The client device must be capable of displaying 32-bit color.
In previous releases, to display X applications through SGD using an SSH connection, you had to enable X11 forwarding.
The Allow SSH Downgrade
(--allowsshdowngrade
)
attribute for X application objects has been introduced, to
enable the display of X applications when X11 forwarding is not
available.
If this attribute is enabled and X11 forwarding is not working or not configured, SGD attempts to display the application using a regular unsecured X11 connection. Depending on your configuration, users might be prompted to accept the downgrade.
A new client profile setting has been added, to provide support for displaying X applications in kiosk mode on a multihead or dual head monitor.
Enabling the Span Multiple Monitors (Kiosk Mode) setting causes the display to be spanned across all monitors.