In addition to providing the core functionality of ICA sessions, the ICA client software has several features that can enhance the quality and performance of ICA sessions making them easier for users and administrators to use.
These ICA client features and options can be broken down into the following four categories.
- ICA session features.
- Performance-enhancing options.
- Administrative features.
- Connection establishment features.
Let's take a look at each of these features now.
ICA Session Features
There are several options that ICA clients have that affect users' ICA sessions and how their client devices work with the MetaFrame XP server within their ICA sessions.
Client Device Mapping
Client device mapping allows certain hardware elements of the ICA client device to be accessed through ICA sessions running on remote MetaFrame XP servers. This process is called "mapping" because it is very similar to mapping a network drive or printer port on a server, except that ICA client device mapping occurs in the opposite direction. For example, consider the following diagram.
Figure 10.3: ICA client drive mapping from a MetaFrame XP server session
- When the ICA session is established with the MetaFrame XP server, the ICA client software on the client device sends the server a list of local components that are available to be mapped.
- If the appropriate mappings have been enabled on the MetaFrame XP server, the mapping process continues and a dynamic mapping is made to the client device.
- Part of the ICA protocol, called a "virtual channel" is used for the mapping. One channel is used for each of the different types of device mapping. This channel allows the mapping data to flow back and forth between the ICA client and the MetaFrame XP server.
These mappings are dynamic. They only exist for the current user and the current session. As soon as the user logs off, the mappings are deleted.
There are several types of devices that can be mapped to client devices in ICA sessions.
MetaFrame XP servers have the ability to connect to and map client drives from the local client device to the sessions running on the MetaFrame XP server.
When client drives are mapped, users have the ability to access data stored on their local hard drives or floppy drives from within their MetaFrame XP server sessions. By default, client drives are mapped using the same drive letter that is configured for the drives on the local client. This allows users to access their local drives via drive letters that are familiar to them.
Obviously, the server can't map a drive to the client device if the drive letter is already in use. In this case (whether because the server has a local drive with the same letter or a network drive is mapped with the same letter), the client drive is mapped with a new drive letter, starting with "V" and moving backwards through the alphabet.
This drive letter conflict is why you have the option of remapping the server drives when MetaFrame XP is installed (as discussed in Chapter 2). The idea is that most client devices will have drive letters that are "C", "D", and "E." If your MetaFrame XP server also uses these drive letters, then the client drives will be available via drive letters "V", "U" and "T" during their server sessions.
In some situations, you might want to configure your MetaFrame XP server so that it does not automatically assign a drive letter to mapped client drives. If you do this, you can still configure it so that users can browse to their client drives through network neighborhood. To do this, you need to make a change to the properties of the connection, which means that you need to use the Citrix Connection Configuration utility to configure it. Use this utility to edit the properties of the connection, and ensure that the "Connect client drives at logon" box is not checked (CCC | Edit Connection | Client Settings). If you're using Feature Release 2, you can also configure this via a Citrix user policy (Client Devices | Client Drives | Connect Client Drives).
Whenever any client devices are mapped from within ICA sessions, your users will see a "Client Network" item in their Network Neighborhood (Network Neighborhood | Entire Network | Client Network). Underneath the Client Network item will be a computer called "client." Browsing this computer will reveal a drive share for each local drive on the client device. These drive share names are made up of the drive letter plus a dollar sign, which means that you will see the shares as \\Client\C$ or \\Client\D$.
If you would like to disable all access to ICA client devices' local drives, then you can check the "Disable Client Drive Mapping" box in the connection's properties (CCC | Edit Connection | Client Settings) or enable the "Connect Client Drives" Citrix user policy with a value of "Do Not Connect Client Drives at Logon". If you do this, the client drive shares will not appear in the client network.
Similar to the drive mappings, printers can be mapped with the ICA client software. There are many different parameters that will affect your printing solution in your MetaFrame XP environment. For that reason, you can find everything that you need to know about printing in back in Chapter 7.
You can map LPT and COM ports from the local ICA client devices so that they are available to users via their server sessions. This is also configured as a property of the connection (Citrix Connection Configuration | Edit Connection | Client Settings | Ensure that "Disable Client LPT Port Mapping" or "Disable Client COM Port Mapping" is not checked) or as part of a Citrix user profile. When you enable port mapping, the ports are not mapped in MetaFrame XP server sessions automatically. Instead, they are available via the client device in Network Neighborhood (From a MetaFrame XP server session | Network Neighborhood | Entire Network | Client Network | Client). You will see that one port is shared for each local port on the client device, such as \\Client\COM2, or \\Client\LPT1.
LPT ports are mapped automatically when your session begins, but COM ports are not. In order to use a mapped COM port, you need to manually map it from within your MetaFrame XP server session. This is most easily done with the "change client" command. The "change client" utility is included with MetaFrame XP and it is meant to be run by users (or logon scripts) from within their ICA sessions. This utility allows you to change the current mapping settings for a particular client device.
When you first use this command, try typing "change client" at the command prompt of a MetaFrame XP server session. This will show you a list of the current devices that are mapped to the local client device.
The "change client" command has the following syntax:
change client hostport clientport
For example, in order to map COM1 so that the ICA client's COM1 port is available via COM1 from a server session, you would type "change client com1 \\client\com1:" Notice that the trailing colon (:) is part of the device's share name. When you use this command, you do not have to map it to the same port on the server as it is on your client device.
In order to view the list of devices that are available on your client device, type "change client /view".
Once your ports are mapped, you can do just about anything with them that you can with a local port on a regular Windows computer, including synchronizing Palm Pilots and Windows CE devices.
If your users' client devices have speakers, they will be able to hear audio from their sessions on the MetaFrame XP server. This is known as "client audio mapping," and it works in a similar way to the other client mapping features.
If you decide to enable client audio mapping, you should know that only certain kinds of sounds are redirected to the ICA client devices. Only audio from applications in which the programmers "properly" used the Microsoft sound APIs fall into this category. Because of this, certain types of sound that are played from server sessions do not make it to the ICA client.
In the real world, you will have to test any applications that require sound. Citrix designed the audio mapping capabilities of the ICA client so that the general "beeps" and "bings" that users receive throughout the day can be sent to the client. It's not really meant for users to use to watch multimedia presentations from the server.
On your MetaFrame XP servers, you enable client audio mapping as a property of a connection (Citrix Connection Configuration | Edit Connection | Client Settings | Disable Client Audio Mapping box unchecked) or as part of a Citrix user policy (Client Devices | Client Audio Mapping) in Feature Release 2 environments.
In addition to enabling or disabling audio mapping, you can also configure the quality of the sound that is sent to ICA client devices. This quality can also be configured as a property of a connection (Citrix Connection Configuration | Edit Connection | ICA Settings | Client Audio Quality). There are three quality options: high, medium, and low:
- High. You should only use the "High" quality when you have more bandwidth than you know what to do with and when you need really accurate sound. The high quality setting plays audio at the native data rate, which equates to about 1.3Mbps. If you choose to use the high setting, remember that your MetaFrame XP server will need to spend more time processing audio, because it will need to send 1.3 MB across the network every second.
- Medium. With the "Medium" setting, the sound quality is lower, but it only uses 64Kbps.
- Low. Most people who use client audio mapping use it with the "Low" setting. This quality setting allows users to hear system sound while only consuming about 16Kbps.
The bandwidth requirements for each of the three quality levels only apply when sound is actually being played. However, when sound is enabled, a small amount of bandwidth is always used even when no sound is playing. This happens because the "Audio" virtual channel of the ICA protocol is enabled anytime audio mapping is enabled. Even though this additional bandwidth usage is small (less than 1Kbps), a lot of people choose to disable audio mapping altogether.
However, it is better to think twice before choosing to disable sound altogether. Disabling sound usually upsets users. When they get upset, your job becomes more difficult. If you use the "low" quality setting, your users will get to hear their audio without overtaxing the network. Besides, your users won't be able to tell the difference between the low, medium, and high settings anyway.
Within MetaFrame XP environments, there are several keystroke combinations that users might need from within their ICA sessions that are not possible. For example, imagine that an application running on a MetaFrame XP server requires the user to press CTRL + ALT + DEL. How would the user do that from their MetaFrame XP session? If they press CTRL + ALT + DEL on their local client device, the local CTRL + ALT + DEL screen will pop up, not the one on the server.
In order to send CTRL + ALT + DEL to the server, a user can press a special key combination on the ICA client device. There are several hotkey combinations, including the task list, closing remote applications, CTRL + ESC, ALT + TAB, and CTRL + ALT + DEL. The exact configuration of these hotkey combinations is done on the ICA client, and the exact method changes depending on the client platform.
When users run a combination of locally and remote ICA applications, they will often need to cut and paste data from their local applications to their remote applications. Since both sets of applications are running on two different computers, this clipboard integration is not inherently possible. Fortunately, the Citrix ICA client software allows local and remote applications to share clipboard data.
When this feature is enabled, any data that is written to the clipboard of either the client or the server is instantly replicated to the clipboard of the other.
As with other configurations, clipboard integration is enabled or disabled as a property of a connection (Citrix Connection Configuration | Edit Connection | Client Settings | Disable Client Clipboard Mapping check box) or a Citrix user policy (Client Devices | Client Audio Mapping).
MetaFrame XP servers support 4-, 8-, 16-, and 24-bit color depths. This works out to 16, 256, 64K, or 16M colors. Ordinarily you would think that the fewer colors you use, the lower the bandwidth requirements would be. As with almost everything in MetaFrame XP, this is not necessarily the case. The 16 and 256 color modes use just about the same amount of bandwidth, so there is really no reason to limit yourself to 16 colors unless you have older client devices or you are mad at your users.
When you step up to the 16 or 24 bit color depths, things get even more interesting. Ordinarily, you would expect that these color depths would require more bandwidth, because more colors are used. In fact, the opposite tends to be true. This is because Citrix has continuously upgraded the compression algorithms that the ICA client uses, but for legacy compatibility reasons, these new algorithms cannot be applied to the older clients that only support 16 or 256 colors. This "feature" has been corrected with Feature Release 2.
In the real world, it's probably best to keep your servers set to 24-bit color. If bandwidth is a problem, then you can use the monitoring tools of MetaFrame XPe to determine the exact ICA virtual channels in use and the amounts of bandwidth that different options require. Just remember that a lower color depth does not automatically equate to lower bandwidth requirements.
ICA clients can theoretically support ICA session resolutions up to 32,000 by 32,000 pixels (although limitations in Windows reduce this to more like 2,700 x 2,700 pixels). Either way, since there are no display devices that can actually show this resolution, you can set the screen resolution of your remote MetaFrame XP session so that it's higher than the physical resolution of your ICA client device. If you do this, you will be able to pan the remote session window with scroll bars.
In the real world, not too many people use this on a daily basis, mainly because the scroll bars are annoying to use. Panning the screen is most often used when you are connecting to an ICA session from a device with a tiny screen, such as a HP iPAQ handheld running Windows CE.NET.
If the ICA client device is running a local operating system with a windows interface (for example, Microsoft Windows or Linux x-Windows), the user can run applications in "Seamless Windows" mode. This means that remote applications appear in resizable windows that look and feel just like local applications. Seamless Windows are one of the "killer app" features of MetaFrame.
Seamless windows applications do not run in their own desktop windows. For Microsoft Windows users, the remote application will not have its own Start Menu, and users can maximize, minimize, resize, and "ALT + TAB" to their application, just as if it were local. In fact, most users that access MetaFrame XP applications in Seamless Windows mode do not even realize that their applications are running on the remote server.
Refer back to Chapter 4 for more details about seamless windows,
Multiple Monitor Support
ICA client devices running Windows across multiple monitors can run single ICA sessions that can span multiple monitors. This support happens automatically for systems that have multiple monitors when users connect to applications with fixed resolutions (not seamless window mode).
Local Time Zone Support
Citrix ICA clients support per-user time zones when connecting to MetaFrame XP servers. This allows each user's session to run in the time zone (and local time) of the local ICA client software.
When local time zone support is enabled (CMC | Farm Properties | MetaFrame Settings Tab | Client Time Zones | Use local time of ICA clients) the ICA client sends the name of its local time zone to the MetaFrame XP server. The MetaFrame XP server compares the client's time zone to its own time zone and adjusts the clock for that user's session appropriately. It is possible for a single MetaFrame XP server to simultaneously support users from any number of time zones throughout the world.
Multi Button Mouse Support
The ICA client can support mice with multiple buttons, even if the local client operating system does not. (Attention Macintosh users!)
Wheel Mouse Support
As part of the mouse movements and clicks that are passed to the MetaFrame XP server via an ICA session, the scroll wheel on newer mice is also supported. This means that users who are accustomed to using the wheel on their mouse can use it for both local and remote applications.
The newest ICA clients support three types of ICA session encryption: SSL, TLS and SecureICA. The details of these encryption features are covered in the security chapter of this book, Chapter 15.
Client Performance Enhancing Options
The ICA client software also several features that you can use to enhance the performance of your users' sessions.
ICA clients with local storage capabilities can use that space to cache bitmap images from the MetaFrame XP servers. This increases the performance of a session because popular objects can be retrieved from the local cache instead of needing be retrieved from the MetaFrame server.
Bitmap caching is generally a good thing, especially with applications that have a few main screens that most users flip through. It also works very well in WAN environments.
When you configure bitmap caching, you need to specify the amount of disk space that is used for the cache, the location of the cache, and the minimum bitmap size that will be cached. In general, you can't have too much cache, so if your clients have big hard drives, go ahead and use them. Typically, the performance increases of the bitmap cache will level off after your cache exceeds about 10MB.
You can also choose the location of the cache files on the client device. When you do this, be sure to choose a local drive. If you choose a network mapped location, then your ICA client performance will probably be worse than having no cache.
Lastly, you can configure the minimum size of the bitmap to be cached. This defaults to 8K and works well for most environments. If you change the minimum size, be sure to test your changes to determine if they actually make a difference and to ensure that they do not negatively affect performance.
The bitmap cache settings, like all client settings, can be configured on a client-by-client basis, meaning that you can have different options configured on each of your ICA client devices.
Most ICA client platforms support data compression. This option can only be configured at the ICA client itself (as opposed to enabling on the server- or farm-basis). Citrix's ICA protocol data compression works pretty well and there's no real reason not to use it.
SpeedScreen Latency Reduction
Remember from the last chapter that "latency" in MetaFrame environments is the time it takes from when a user performs an action until he receives feedback of that action. For many users, the inherent latency of MetaFrame environments causes problems with typing and clicking, as when the user enters several keystrokes before seeing output of them on the screen.
MetaFrame XP can make the user think that there is less latency through the use of SpeedScreen Latency Reduction (SLR). SLR decreases the users' perception of latency in two ways:
- SLR can provide instant feedback whenever a mouse button is clicked.
- SLR can be used to echo text to the screen locally.
Mouse Click Feedback
When mouse click feedback is enabled, the Citrix ICA client will change the cursor from the "normal select" pointer (usually an arrow) to the "working in background" pointer (usually an arrow next to an hourglass). Since mouse click feedback is a property of the ICA client, it can provide instant "click feedback" to the user, even in environments with high latency where the server does not respond quickly.
Enabling mouse click feedback will prevent users from clicking on items too many times and getting multiple copies launched. This usually happens when impatient users click on something, and then they think that nothing has happened, so they click on it again. Ultimately, they get multiple instances of their item being opened.
Local Text Echo
Local text echo allows the ICA client software to render fonts locally on the client device rather than waiting for them to be sent down by the MetaFrame XP server. Ordinarily, MetaFrame XP works in a "screen-scrape" mode, in that the MetaFrame server sends information about the pixels that change color to the ICA client. For example, if a user is using Microsoft Word, the keystroke is sent to the MetaFrame XP server each time they type a letter. The server processes the keystroke and the application responds by displaying the letter that was typed on the screen. The MetaFrame XP software sends the screen update information to the ICA client, which would probably be a list of pixels that were white that should now be changed to black, representing the new letter.
This method can be inefficient, especially over slow network links. In order to address it, SLR can be used to generate the characters locally on the ICA client device. When local text echo is enabled, the ICA client sends the server a list of fonts that it has installed as soon as the session begins. Then, as a user types from within their application, the ICA client device displays the text on the local device the instant the key is pressed, before receiving confirmation from the server to change the color of the appropriate pixels. Local text echo works well with applications in which users type very quickly, and it's annoying to have even the slightest delay from the time that a key is pressed until the time the character appears on the screen.
Configuring SpeedScreen Latency Reduction
In order to use either or both of the components of SLR, you must configure them on your MetaFrame XP server. This is done with the SpeedScreen Latency Reduction Manager (Start | Programs | Citrix | MetaFrame XP | SpeedScreen Latency Reduction Manager).
When you launch the SLR manager on a MetaFrame XP server, you are presented with a list of servers in your farm. If you double-click on a server, you can view the default SLR configuration options for that server.
The mouse click feedback configuration is simple-either it is "on" or "off." There are no additional options to configure.
The local text echo is a bit more complex. This stems from the fact that not all applications are ideal candidates for using SLR's local text echo. In fact, some applications have some screens that would work well and others that would not. For example, if you wanted to enable local text echo with Microsoft Word, it would work well while you're using the main document screen. However, it might not work so well with some of the property pages.
For this reason, you need to configure the local text echo components of SLR so that it knows which applications (and which windows of those applications) it should be enabled for, and which ones it should avoid.
To configure local text echo properties for applications, open the SLR Manager. By clicking the "new" button, you can define a new policy for an application. When you do this, a wizard will be launched that will walk you through the SLR configuration of the application. Basically, you are given the opportunity to use the application while the SLR manager is running in the background. You can select different windows or fields and give them each different SLR properties, including whether you want to enable local text echo, the font size, and how text is displayed.
You can use local text echo with any application so long as it was written using the standard Microsoft APIs. (You cannot use local text echo with the Citrix Management Console, since it was not written with Microsoft APIs.)
Once you get your SLR settings configured the way you want them, they are saved into the %systemroot%\system32\ss3config\ folder. This folder will not exist until you save some SLR settings. Within this folder, subfolders will be created for each application for which you created an SLR policy. You can copy application SLR policies from one server to the next simply by copying the application's folder in the \ss3config folder.
Queue Mouse Movements and Key Strokes
On an ICA client, you can configure the rate that mouse movements and keystrokes are sent to the server. This is not the same as SpeedScreen. Adjusting these settings helps to reduce network traffic by reducing the frequency of mouse and key data sent, while SpeedScreen's purpose is to improve the user's perception of performance.
To make your life easier as an administrator, there are a few features that are common to many ICA clients.
Auto Client Update
Auto client update allows you to automatically deploy new versions of the ICA client software to your users. To do this, you maintain a database that contains the new versions of the clients for the platforms that you support on your MetaFrame XP servers.
For details about the auto client update, refer to the "Auto Client Update" section of this chapter.
Many of the ICA client platforms support logging that you can enable to record the following types of information:
- Connections and Disconnections. When enabled, a record is written to the log file anytime an ICA connection is enabled or disabled. That record indicates the time, date, and the name of the server farm or application. This option is enabled by default.
- Errors. Error logging causes an error event to be written to the log file anytime an ICA error occurs. This option is also enabled by default.
- Data Transmitted. If you choose to enable logging of the data that is transmitted, the contents of every single ICA packet sent from the client to the MetaFrame XP server are written to the log file. This causes the log file to grow very, very quickly (about 1MB per minute). This logging is meant only for advanced troubleshooting purposes. If you are a geek, then you might also want to enable this logging for a minute or two, because studying the outputs of this log will teach you how the ICA client really works.
- Data Received. This is similar to the data transmitted, except that it logs the contents of the ICA stream sent from the MetaFrame XP server to the ICA client.
- Keyboard and Mouse Data. If you enable this, the log file will contain a record of the mouse movements and keystrokes. Be aware that this represents a huge security hole if you're not careful. When enabled, someone viewing the log file can see everything that a user typed, including passwords. (See Chapter 15 for more security information.) As with data logging, having the keyboard and mouse data logging enabled will cause your log file to grow quickly.
If you enable logging, all five types of logging information are written to the same log file. You have the option of specifying whether you want to append the data to the current log file or start a new log file every time a new connection is made. In the real world, most people disable logging for the day-to-day operations of their environment. Logging is usually only used for troubleshooting purposes.
Connection Launching Features
There are quite a few features of ICA clients that help users find and connect to their applications on your MetaFrame XP servers.
Program Neighborhood allows your users to log into a MetaFrame XP server farms once, after which they are presented with icons for each application that they can access. This prevents users from having to log in separately to each application. It also simplifies your administration, since icons for newly-configured applications are automatically made available to users as soon as they log into Program Neighborhood.
Your users can use Program Neighborhood to configure multiple Application Sets. An Application Set is a listing of applications from a single server farm. By accessing multiple application sets, your users can access multiple server farms from a single ICA client.
For example, a user may log into Program Neighborhood and be presented with multiple icons, each icon representing a different server farm. Clicking on a specific server farm will expose the icons for published applications in that server farm configured for that user.
Program Neighborhood Agent
The Program Neighborhood Agent client is similar to the Program Neighborhood client, except that MetaFrame XP application and content icons are placed in the system tray, Start menu, or desktop folder. When the Program Neighborhood Agent is used, no configuration information is stored locally on the client device.
Details about configuring the servers needed to support the Program Neighborhood Agent ICA client can be found in Chapter 11. Details about the use and installation of the Program Neighborhood client can be found later in this chapter.
Web Browser Launching
Most Citrix ICA clients support web browser launching, which means that the ICA client software can be automatically launched by a user clicking a hyperlink on a web page. Full details about the integration of Citrix ICA clients and the web can be found in Chapter 11.
Users connecting from Windows 32-bit clients can choose to have the credentials they used to log onto their workstation transparently passed through to MetaFrame XP servers when they establish an ICA session. This pass-through authentication works with both NDS and Windows authentication methods. For details about configuring pass-through authentication on your servers, refer to Chapter 15.
Many ICA clients have redundancy built into them in the form of "business recovery." Essentially, this redundancy allows you to create multiple lists of servers that the client software will contact when looking for an application list or trying to connect to a published application.
This feature is implemented in the form of a "Server Group List." ICA clients divide the MetaFrame XP servers that are to be contacted into three groups: primary, backup 1, and backup 2. Each group can contain up to five servers, listed by their DNS name, NetBIOS name, IP address, or MAC address. When the user clicks an icon to launch a session, the ICA client simultaneously sends out the request to all servers in the primary group. If no server responds, it tries again. After the third try, the ICA client software automatically moves on to the servers in the backup 1 group. After the third try to the backup 1 list, the client tries the backup 2 list.
If you have chosen an HTTP protocol as your method for locating servers, then the ICA client software treats all three lists as one, methodically stepping through each server.
As an administrator, you can put the servers in specific lists to control the order that they should respond. However, you need to keep the server list within reason. Even though you could have fifteen servers spread out across your three lists, you wouldn't really want a situation in which a user had to wait for fourteen servers to timeout before finding one that works.
Some ICA client platforms can support multiple simultaneous ICA sessions. This allows users to be connected to two different MetaFrame XP servers at the same time.
All of the ICA clients version 6.20 and newer can authenticate users to an NDS tree instead of a Windows domain (if Feature Release 1 or 2 is enabled on your MetaFrame XP servers). For details, refer to Chapter 8.
Auto Session Reconnect
ICA clients version 6.20 and newer can be configured for auto client reconnect. This option will prompt the client software to automatically attempt to reestablish a connection with the MetaFrame XP server if an ICA session is unexpectedly disconnected. This usually occurs over slower network connections when the sessions occasionally timeout, or when your cat walks across your desk and pulls out your modem cable.
The ICA clients that support dial-in modems can support dialing prefixes, allowing users to save settings for the phone dialer that can be applied across multiple ICA connections.
Local File Type Support
The ICA clients version 6.20 and newer support launching published application by opening a local document on a client device that is associated with the remotely published application. Detailed information about configuring this on the MetaFrame XP server was outlined back in Chapter 4. Information about configuring this for different ICA client platforms is contained in the appropriate section of this chapter.
Windows-based ICA clients allow you to automatically place icons for MetaFrame XP applications and content directly on your users' desktops or start menus, without the need to visit their client devices. This can make it easy to make new applications available to your users.
Save User Credentials
Many ICA clients allow users to save their credentials associated with ICA connections so that they do not have to manually type them in whenever they launch an ICA session. See Chapter 15 for more information.
Which options work on which platforms?
The previous section outlined the generic options that are available with ICA clients. It's important to note that not all of these options are available on all client platforms. The chart in Figure 10.4 shows several popular ICA client platforms and the specific options that are supported on them.
Figure 10.4: (facing page) Available options for popular ICA client platforms
As you look at this chart, keep in mind that it only shows the options that could be used on different client platforms. As an administrator, you have the ability to restrict certain options from users, and many of these restrictions can be configured in many places. The appendix of this book contains a chart detailing every configuration option (all of those shown below and then some), and the location at which each option can be configured.
Now that you've seen all of the options that are available to various client platforms, let's take a detailed look at some of the more popular ICA clients. To do this, we'll first study the family of numerous and popular 32-bit Windows clients. After that, we'll look at the Java clients, since they can be used on any platform.