This section describes how to configure Windows application objects.
This section includes the following topics:
You use a Windows application object if you want to give a Microsoft Windows graphical application to users.
In the Administration Console, the configuration settings for Windows application objects are divided into the following tabs:
General tab – These settings control the name and the icon used when creating links for users
Launch tab – These settings control how the application is started and whether application sessions can be suspended and resumed
Presentation tab – These settings control how the application is displayed to users
Performance tab – These settings are used to optimize the performance of the application
Client Device tab – These settings control how the user’s client device interacts with the application
The following table lists the most commonly used settings for configuring Windows application objects, and how to use them.
In addition to this configuration, you can also configure the following:
Printing – See Printing.
Client drives – See Client Drive Mapping.
Audio – See Audio.
Smart cards – See Smart Cards.
Copy and paste – See Copy and Paste.
Serial ports – See Serial Ports.
On the command line, you create an Windows application object with the tarantella object new_windowsapp command. You can also create multiple Windows application objects at the same time with the tarantella object script command. See Populating the SGD Organizational Hierarchy Using a Batch Script.
Windows application objects can only be created in the o=applications organizational hierarchy.
Configuring a Windows application object enables you to use the features of Microsoft Windows Terminal Services.
Note - From Windows Server 2008 R2, Terminal Services is renamed Remote Desktop Services.
The Terminal Services features supported by SGD and the application server platforms on which they are supported are listed in the Oracle Secure Global Desktop 4.6 Platform Support and Release Notes available at http://docs.sun.com/app/docs/doc/821-1928.
There are many possible configuration settings for Microsoft Windows Terminal Services. For detailed information on configuring Terminal Services, see your system documentation. To use Terminal Services with SGD, the settings you might have to configure include the following:
Note - Changes to your Terminal Services configuration only take effect for new Windows Terminal Server sessions.
You must configure Windows Terminal Services so that it does not prompt for a password when a user logs in.
By default, Windows 2000 Server always prompts for a password when users log in, whether or not SGD supplies the password for the application server from its password cache. By default, Windows Server 2003 or later, does not prompt for passwords.
With Windows Terminal Services, users’ sessions can continue to run following a connection loss.
If you are not using Session Directory, it is best to disable this feature on the Windows Terminal Server, and let SGD handle session resumability. This prevents unnecessary use of resources on the application server, and ensures that if users share accounts on the application server, they do not resume each other’s Windows sessions. To disable this feature, you must select End Session for the When Session Limit Is Reached Or Connection Is Broken option in Terminal Services Configuration.
If you are using Session Directory to handle session resumability, you must select Suspend Session for the When Session Limit Is Reached Or Connection Is Broken option in Terminal Services Configuration. To use Session Directory, you must also configure the Window Close Action attribute for Windows application objects to End Application Session.
To support printing to client printers from a Windows Terminal Server session, Windows printer mapping must be enabled. Windows printer mapping is enabled by default.
To support mapping of client drives in a Windows Terminal Server session, drive redirection must be enabled. Drive redirection is enabled by default.
You can only use the Low, Client-compatible, or High encryption levels with SGD. SGD does not support the Federal Information Processing Standards (FIPS) encryption level.
By default, a Microsoft Windows Server only allows users to start one Terminal Services session. If a user starts another desktop session, or another instance of an application with the same arguments, the second Terminal Services session grabs the first session and disconnects it. This means that it is not possible to start two desktop sessions, or two instances of the same application, on the same Windows Server.
On Microsoft Windows Server 2003 or later application servers, you can enable support for multiple Terminal Services sessions.
For Microsoft Windows Server 2003 or later application servers, users can only use Terminal Services if they are members of the Remote Desktop Users group.
Client computers can redirect their time zone settings to the Terminal Server, so that users see the correct time for their time zone in their desktop or application sessions. Terminal Services uses the server base time on the Terminal Server and the client time zone information to calculate the time in the session. This feature is useful if you have client devices in different time zones. By default, this feature is disabled.
In the Administration Console, the Time Zone Map File attribute on the Global Settings -> Client Device tab specifies a file that contains mappings between UNIX platform client device and Windows application server time zone names.
To play audio from a Windows Terminal Server session, audio redirection must be enabled on the application server. By default, audio redirection is disabled.
To use a smart card reader from a Windows Terminal Server session, smart card device redirection must be enabled on the application server. By default, smart card device redirection is enabled.
To access the serial ports on the client device from a Windows Terminal Server session, COM port mapping must be enabled on the application server. By default, COM port mapping is disabled.
SGD supports 8-bit, 16-bit, 24-bit, and 32-bit color depths in a Windows Terminal Server session.
32-bit color is available on Windows Vista, Windows Server 2008, Windows Server 2008R2, and Windows 7 platforms. For a 32-bit color depth, the client device must be capable of displaying 32-bit color.
15-bit color depths are not supported. If this color depth is specified on the Terminal Server, SGD automatically adjusts the color depth to 8-bit.
From Microsoft Windows Server 2003 and later, you can use Transport Layer Security (TLS) for server authentication, and to encrypt Terminal Server communications. SGD does not support the use of TLS.
For Windows Server 2003 and later, Terminal Services settings can be configured using Group Policy, as follows:
Individual Windows Terminal Servers can be configured using a Local Group Policy Object (LGPO). In the Group Policy Object Editor, the Terminal Services settings are at: Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Terminal Services
Multiple Windows Terminal Servers can be configured using a Group Policy Object (GPO), linked to a domain or organizational unit (OU).
To improve performance, you might want to configure some or all of the following policies:
Keep-Alive Connections. This policy specifies a keep alive time interval for the Terminal Services session. See also Keep Alive Configuration for Windows Terminal Servers.
Limit Maximum Color Depth. This policy controls the display color depth on client devices. See Microsoft Knowledge Base article 278502 for details of how to set this policy.
If you find that the connection between the SGD server and the Windows Terminal Server is being dropped unexpectedly, you might need to configure the keep alive mechanism for the Windows Terminal Server.
How to do this is described in Microsoft Knowledge Base article 216783.
SGD does not include licenses for Microsoft Windows Terminal Services. If you access terminal server functionality provided by Microsoft operating system products, you need to purchase additional licenses to use such products. Consult the license agreements for the Microsoft operating system products you are using to determine which licenses you must acquire.
Terminal Services licensing is done using a CAL. A CAL is a license that allows a client to access the Windows Terminal Server. Depending on the licensing mode, a client can be either a user, or a device, or a combination of both.
Client license management for Microsoft Windows Terminal Services varies according to the client platform, as follows:
Windows platforms. CALs for client devices that connect to the Terminal Server are allocated in accordance with Microsoft policy. CALs are stored in the Windows registry on the client device.
UNIX, Linux, or Mac OS X platforms. CALs for client devices that connect to the Terminal Server are stored in a license pool in the datastore on the SGD server. Management of this license pool is done by the SGD Administrator, using the tscal command. See Managing CALs From the Command-Line .
You can use the tarantella tscal command to manage Microsoft Windows Terminal Services CALs for non-Windows client devices, as follows:
To list the Terminal Services CALs currently reserved for non-Windows client devices, type the following:
$ tarantella tscal list
To free a Terminal Services CAL for use by another non-Windows client devices, type the following:
$ tarantella tscal free
To return all free Terminal Services CALs to the Windows License Server, type the following:
$ tarantella tscal return --free
Some editions of Microsoft Windows include a Remote Desktop feature that enables you to access a computer using Microsoft RDP. You can use SGD and Remote Desktop, for example, to give users access to their office PC when they are out of the office.
The supported platforms and features for Remote Desktop are listed in the Oracle Secure Global Desktop 4.6 Platform Support and Release Notes available at http://docs.sun.com/app/docs/doc/821-1928.
Before introducing SGD, ensure that the Remote Desktop connection to the Microsoft Windows computer is working.
You configure SGD for use with Remote Desktop as follows:
Create an application server object for each Microsoft Windows computer.
Create a Windows application object for the Windows desktop application.
To ensure users access their own computer, you have to create separate Windows desktop application objects for each Microsoft Windows computer.
See Using My Desktop for details of how to run a full-screen desktop session, without displaying the SGD webtop.
With seamless windows, the Microsoft Windows application server manages the display of the application. This means an application’s windows behave in the same way as an application displayed on the application server, regardless of the user’s desktop environment. The window can be resized, stacked, maximized, and minimized. The Windows Start Menu and Taskbar are not displayed when using seamless windows.
Seamless windows are not suitable for displaying Windows desktop sessions. Use a kiosk or independent window instead.
The following are the conditions for using seamless windows:
The SGD Enhancement Module for Windows must be installed on the application server.
The Windows application object must be configured with a Window Type of seamless window.
If any of the above conditions are not met, SGD displays the Windows application in an independent window instead.
The following are some notes and tips on displaying applications in seamless windows:
If an application is displayed in a seamless window, you can toggle between a seamless window and an independent window by pressing the Scroll Lock key. This does not work if the SGD Client is in Integrated Mode.
Applications that have non-rectangular windows, for example, a media player with a customized skin, display in a rectangular window.
On Windows client devices, seamless windows are not affected by the Cascade, Tile Windows Horizontally, or Tile Windows Vertically window commands.
If a screen saver or the Windows Security dialog displays, the window automatically switches to an independent window. Unlocking the application automatically restores the window to a seamless window.
If a seamless window application is resumed on a display that is larger or smaller in size than the original session, the application is displayed in an independent window.
Each application displaying in a seamless window has its own RDP connection.
Applications configured to display in seamless windows might not display correctly when accessed from a Gnome 2.0.0 Desktop. This is caused by an unpatched version of the Metacity Window Manager. The solution is to install the Gnome 2.0.0 Window Manager patch. Patch ID: 115780, available from the Sun Support Center at http://www.sun.com/support.
You can configure how SGD handles keyboard presses on the client device in a Windows Terminal Services session, as follows:
SGD supports the following keyboard shortcuts for Windows Terminal Services sessions.
In SGD Windows Terminal Services sessions, the Windows key and keyboard shortcuts for managing windows can be sent either to the remote session or acted on locally. By default, they are acted on locally.
For Windows applications objects that are configured to display in kiosk mode, the Window Management Keys (--remotewindowkeys) attribute controls keyboard shortcut behavior. To send the Windows key and window management keys to the remote session, do either of the following:
In the Administration Console, go to the Client Device tab for the Windows application object and select the Window Management Keys check box.
Use the following command:
$ tarantella object edit --name obj --remotewindowkeys 1
If the Windows key and window management keys are sent to the remote session, use the key sequence Alt-Ctrl-Shift-Space to exit kiosk mode. This minimizes the kiosk session on the local desktop. Alternatively, to exit kiosk mode you can use the Kiosk Mode Escape (--allowkioskescape) attribute to enable a pull-down header for the application window. The pull-down header includes icons for minimizing and closing the kiosk session.
For Windows applications objects that are not configured to display in kiosk mode, you can force the Windows key to be sent to the remote session by using the -windowskey option for the SGD Remote Desktop Client. To send the Windows key to the remote session, do either of the following:
In the Administration Console, go to the Launch tab for the Windows application object and type -windowskey on in the Arguments field.
Use the following command:
$ tarantella object edit --name obj --protoargs "-windowskey on"
The process of configuring Windows keyboard maps in SGD is the same as that used for configuring keyboard maps for X applications. See also Keyboard Maps.
Note - For Windows applications, the keyboard layout must be the same on the client device and the application server.
By default, when you run a Windows application through SGD using the Microsoft RDP protocol, the host name of the client device is returned in the %CLIENTNAME% environment variable for the Windows Terminal Services session. When you use a Sun Ray Desktop Unit (DTU) client device, the DTU ID is returned in the %CLIENTNAME% environment variable. The DTU ID is the hardware address of the Sun Ray.
The DTU ID can be used to specify the name of the client device in the wcpwts.exp login script. SGD uses this login script for all Windows applications that connect using the Microsoft RDP protocol.
The SGD Remote Desktop Client, also known as ttatsc, is a client program that handles the connection between the SGD server and the Windows Terminal Server.
The syntax for running ttatsc from the command line is as follows:
ttatsc [-options..] server.example.com
where server.example.com is the name of a Windows Terminal Server.
You can use the ttatsc to configure Windows Terminal Services sessions in the following ways:
Configure attributes for the Windows application object. Some of the ttatsc command options are available as attributes for a Windows application object. These are indicated in the following table.
Configure the Arguments (--protoargs) attribute of the Windows application object. Using this attribute, you can specify ttatsc command options used for a Windows application object.
Edit the wcpwts.exp login script, and specify ttatsc command options. Any changes you make to this file are used for all Windows applications that connect using the Microsoft RDP protocol.
The following options are supported for the ttatsc command.
A configuration file is a text file containing the ttatsc command-line options to be used for the connection. Each option must be on a separate line without the leading dash (-). The argument and its value are separated by whitespace. Use either single or double quotes to enclose any literal whitespace.
The escape character is \.The following escape sequences are supported:
\n is a new line (0xA)
\r is a carriage return (0xD)
\t is a tab (0x9)
\\ is a literal \
\" is a literal double quote not used for delimiting quoted arguments
\'is a literal single quote not used for delimiting quoted arguments
The following is an example configuration file:
u "Indigo Jones" p "Wh1teh4ll" a "C:\\program files\\notepad.exe" naples.indigo-insurance.com
You can run a Windows application on a client device, instead of displaying it through SGD. If the application is not available on the client device, and the SGD Remote Desktop Client check box is selected, SGD tries to run it on the application server.
Applications that run on client devices are not resumable, even if the Application Resumability is configured.
The application must be installed in the same location on all client devices.