Comprehensive ICA Client Configuration Document

Citrix states in their article: CTX624152

CTX624152 - Comprehensive ICA Client Configuration Document

This document was published at: http://support.citrix.com/kb/entry.jspa?externalID=CTX624152

Document ID: CTX624152, Created on: Jun 12, 2001, Updated: Apr 23, 2003

Products: Citrix MetaFrame XP 1.0 for Microsoft NT 4.0 Server Terminal Server Edition, Citrix MetaFrame XP 1.0 for Microsoft Windows 2000, Citrix MetaFrame 1.8 for Microsoft NT 4.0 Server Terminal Server Edition, Citrix MetaFrame 1.8 for Microsoft Windows 2000, Citrix WinFrame 1.8

This document describes ICA Client communication, including client location of servers by automatic and default location methods. This document also describes the effects of MetaFrame XP and MetaFrame 1.8 interoperability on ICA Client communication.
< p>Server Location by ICA Clients

ICA Clients can be configured to use any of the following protocols for ICA communication:

• TCP/IP

• IPX

• SPX

• NetBIOS

• TCP/IP + HTTP

All of the protocols let ICA Clients locate MetaFrame servers automatically and use specified default servers.

To browse and resolve server and application names, the TCP/IP protocol on the ICA Clients transmits and receives ICA Browser data using the UDP protocol on port 1604 (not configurable). After a name is resolved by the ICA Browser, ICA connections are made using TCP port 1494 (configurable). Firewalls typically block UDP port 1604 packets.

Using Server Auto-Location

When no explicit server locations are configured in the ICA Client, the default setting with TCP/IP protocol is Auto-Locate for automatic location of the nearest MetaFrame server. The communication method used with auto-locate depends on the network protocol setting in the ICA Client:

Network Protocol
Auto-Locate Method

NetBIOS
NetBIOS broadcast

IPX
IPX broadcast

SPX
SPX broadcast

TCP/IP
UDP broadcast to port 1604

TCP/IP+HTTP
Resolves host name "ICA" to find MetaFrame server

TCP/IP, IPX, SPX, and NetBIOS

When using the TCP/IP, IPX, SPX, and NetBIOS settings for network protocol in the ICA Client, auto-locate increases network traffic because the client broadcasts data to locate servers.

If you specify an explicit server location under Default Server Location in the ICA Client, the client attempts to contact the server directly without broadcasts. Therefore, to reduce network traffic, configure ICA Clients by entering a specific server location in the Address List box whenever possible and avoid using auto-locate.

TCP/IP + HTTP

The TCP/IP+HTTP network protocol setting is the only protocol that does not use a broadcast with auto-locate to find the nearest farm server. Instead, the client attempts to resolve the hostname ica to a MetaFrame server. Therefore, if auto locate functionality is desired, the TCP/IP + HTTP protocol is recommended because it does not increase network traffic with ICA Client broadcasts.

NOTE: TCP/IP + HTTP does not currently support SSL technology.

Specifying Servers for Default Server Location

To specify servers for the default server location, you enter one or more server addresses or host names in the Address List box on the Connection tab in the ICA Client. The way that the client uses specified server addresses depends on whether the client is using an application set or a custom connection.

• When refreshing or displaying an application set, the client contacts the specified server to provide the list of published applications in the application set. If the user launches an application in an application set, the client contacts the specified server to discover the data collector and then contacts the data collector to get the address of a server on which to run the application in an ICA session.

• When listing applications to create a custom connection (or in an ICA Client without Program Neighborhood), the client contacts the specified server to discover the data collector and get the list of published applications. When launching an application, the client contacts the specified server to discover the data collector and get the address of the server on which to establish the ICA session.

Using Server Groups

Default server location entries can be divided into three categories that you select from the Server Groups menu: Primary, Backup 1, and Backup 2. You can specify up to five servers in each category.

Use the following methods to specify server locations:

TCP/IP and TCP/IP+HTTP network protocols. Specify the server name, the IP address, or a DNS entry.

IPX and SPX network protocols. Specify the servers MAC address.

NetBIOS network protocol. Specify the server name (also known as the NetBIOS name).

Use Server Group categories to control the order in which the ICA Client attempts to contact MetaFrame servers. The client uses the Server Group setting based on the network protocol setting.

Using Server Groups With TCP/IP, IPX, SPX, and NetBIOS

When using the TCP/IP, IPX, SPX, and NetBIOS protocols, the client contacts servers in the Primary group first, followed by servers in the Backup 1 group and then the Backup 2 group. To illustrate this ICA Client request process, refer to the example Server Groups in the following table:

Server Group
Servers

Primary
Dedicated data collector1, Dedicated data collector2, Server1, Server2, Server3

Backup 1
Server4, Server5, Server6, Server7, Server8

Backup 2
Server9, Server10, Server11, Server12, Server13

1. The ICA Client first sends out a packet to all servers listed in the Primary Server Group. If five servers are listed, it sends five packets, one to each server, requesting the zone data collector or master ICA Browser.

2. The ICA Client attempts to contact each server in the Primary Server Group three times.

3. When one of the servers responds, the ICA Client ignores subsequent responses and continues with the authentication, browsing, or connection process.

If no servers in the Primary Server Group respond, the client repeats the process using the Backup 1 group and then the Backup 2 group (the client attempts to contact the servers in the Backup 2 Server Group only once).

In smaller farms or farms with low activity, Citrix recommends that only zone data collectors or dedicated master ICA Browsers be listed in the Primary Server Group to reduce network traffic and improve ICA Client connection time. The above example is then reconfigured as follows:

Server Group
Servers

Primary
Dedicated data collector1,
Dedicated data collector2

Backup 1
Server1, Server2, Server3, Server4, Server5

Backup 2
Server6, Server7, Server8, Server9, Server10

If multiple sites exist, Citrix recommends that the Primary and Backup 1 Server Groups contain dedicated data collectors and servers respectively that reside at the same physical location as the ICA Clients. The Backup 2 Server Group can include other servers from the same physical site and servers from other sites. This practice reduces ICA browsing across a WAN link.

In larger farms with high activity, the data collector can become overloaded with many ICA Client requests. If managed applications are being used through Program Neighborhood, specifying only member servers for server location can reduce activity on the data collector and provide faster user response.

During application set refreshes, enumeration, and authentication, the specified member server fulfills the request without contacting the data collector. The member server forwards the request to the data collector only when applications are launched.

Using Server Groups With TCP/IP+HTTP

The TCP/IP+HTTP protocol treats all three categories of Server Groups as a single ordered list beginning with the Primary group, followed by the Backup 1 group and then the Backup 2 group.

When establishing a connection, the ICA Client attempts to contact the first server in the list. If the request times out without a response, the client attempts to contact the next server in the list. The client continues to contact servers in order until it establishes a connection or reaches the end of the list.

The ICA Client connection timeout interval is based on the TCP timeout setting on the client device. The ICA Client does not return a timeout error message to the user until it fails to connect to all servers in the three groups. Therefore, if each server group contains five servers, the ICA Client can take about six minutes to return a timeout message.

Follow these Default Server Location guidelines when using TCP/IP+HTTP for ICA Client communication:

• List servers with the highest probability of responding first

• Limit the number of servers specified in the list to prevent unnecessarily long ICA Client connection times that might result in a timeout

Communication in Mixed Server Farms

ICA Client communication differs from the previous descriptions when MetaFrame 1.8 servers reside on the same network as MetaFrame XP servers. The following sections describe these differences.

Server Location in Mixed Server Farms

Deploying MetaFrame XP in mixed mode for interoperability with MetaFrame 1.8 automatically configures all MetaFrame XP servers in the farm to respond to ICA Client broadcast messages. In mixed mode, the following is true:

• On subnets with MetaFrame 1.8 servers, ICA Clients can view both MetaFrame 1.8 and MetaFrame XP resources using Default Server Location settings.

• On subnets with only MetaFrame XP servers, ICA Clients can view both MetaFrame 1.8 and MetaFrame XP resources using Default Server Location settings.

• When MetaFrame 1.8 and MetaFrame XP servers are both specified as Default Server Locations, the same list of MetaFrame 1.8 and MetaFrame XP resources is returned every time because MetaFrame 1.8 and MetaFrame XP servers are aware of each other.

Server Location in Native Mode With MetaFrame 1.8 Servers

If MetaFrame XP is installed in native mode and detects MetaFrame 1.8 servers on the network, the MetaFrame XP farm ignores ICA Client broadcasts. The MetaFrame XP servers still respond to direct requests from ICA Clients that have MetaFrame XP servers specified for server location. In native mode, the following is true:

• On subnets with MetaFrame 1.8 servers, ICA Clients using auto-locate get only a list of MetaFrame 1.8 servers. To view MetaFrame XP resources, a MetaFrame XP server must be specified under Default Server Location. However, if a MetaFrame XP server is specified, only MetaFrame XP resources can be seen.

• On subnets with only MetaFrame XP servers, ICA Clients using auto-locate cannot view any resources. Default Server Location values must be specified because no MetaFrame 1.8 servers exist on the subnet to respond to the broadcast, and MetaFrame XP servers do not respond to broadcasts when MetaFrame 1.8 servers exist elsewhere on the network.

• When MetaFrame 1.8 and MetaFrame XP servers are both specified for server location, the first server to respond determines the list of resources. A MetaFrame 1.8 server sends a list of MetaFrame 1.8 resources to the client. A MetaFrame XP server sends a list of MetaFrame XP resources to the client.

Configuring Server Location After Migration

After all MetaFrame 1.8 servers are upgraded to MetaFrame XP, the MetaFrame XP farm does not automatically begin to respond to ICA Client broadcasts even though there are no longer any MetaFrame 1.8 servers on the network.

To configure broadcast response by MetaFrame XP servers

If you want all MetaFrame XP servers in the migrated server farm to respond to ICA Client broadcasts, do the following:

1. Launch the Citrix Management Console and log in to the MetaFrame XP farm.

2. Right-click the farm (top) node in the console tree and choose Properties.

3. Select the MetaFrame Settings tab. Select the option Farm responds to ICA Client broadcast (UDP) messages.

4. Click OK to save changes and exit.



Primary links

Custom Search

Who's new

  • japhabept
  • Rullydery
  • eagenorce
  • rittaarier
  • swasseZex

Who's online

There are currently 0 users and 5 guests online.

KrissysCorner.com RuthSwensonLaw.com CreativeLizardProductions.com

DISCLAIMER:

None of this has anything to do with us, someone else is responsible for the entire thing, and we have no idea who or why. We do not know anything about it. It may be alien life forms for all we know: we haven't a clue. You cannot blame us for anything that may result from your visit. That was entirely your own personal choice, made by you of your own volition, and without our knowledge. We do not, after all, have any control over you and cannot by any stretch of the imagination be expected to accept or acknowledge, be it legally or morally, any accountability for decisions made by you on an independent basis, utilizing your own free will, and without our intervention. We are therefore in no way, shape, or form answerable to anyone for any consequences arising from the aforementioned or indeed any other actions, similar or otherwise, because it was not us that did, or did not do anything. It is not even remotely our fault, and we are in no way prepared or willing to accept any liability, not even slightly, ever. We are, in fact completely and utterly blameless, in that it is definitely not our concern, and no blame can possibly be laid at our doorstep, even if we had one, the possession of which we hereby reserve as being entirely our own free choice. The onus is not on us at all, and furthermore, never has been. The entire matter is wholly beyond our control, and completely out of our hands, each of which are washed scrupulously clean of the whole business. We are not accountable for anything at all, and we hereby categorically deny all responsibility for all that has ever, or will ever happen. Our innocence is therefore wholly beyond doubt and absolutely unimpeachable, and so cannot, under even the remotest or unlikeliest circumstances, be brought into question. By clicking either on a link on this site, clicking on a link that leads to this site, or by arriving at this site by natural or supernatural means, you are in effect accepting responsibility for the fact that it is all entirely your own fault, down to the most miniscule detail, and that you are wholly accountable for whatever outcome may arise as a consequence of the aforementioned action or actions insofar as they were undertaken personally by you on an entirely voluntary basis and without any persuasion, coercion or influence from any party or parties other than yourself. Don't come sniveling to us, we are only figments of your imagination. I also agree that if I am ever with a contributor to this website during mealtimes I agree to pay for any super-sizing of their meal, or at least a nice dessert or one of those foo-foo drinks with an umbrella or a monkey. By admitting to have seen the worthless spineless drivel on this website (also known as content)

I Agree Wholeheartedly and Without Reservation to the above. (Except maybe for that part about the monkey.)

All Your Base Are Belong To Us.

Soylent Green Is People!

Never make a bet with a Sicilian when Death is on the Line!

No. Really, I do agree.