Comprehensive ICA Client Configuration Document
Comprehensive ICA Client Configuration Document 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.
User login
Who's new
- japhabept
- Rullydery
- eagenorce
- rittaarier
- swasseZex