Chapter 4: Using Citrix Technologies

---

MetaFrame XP improves upon several existing features and introduces a few new ones. Citrix has improved the ICA protocol to allow for a more robust user experience and support of new features. One of the improvements is the Independent Management Architecture (IMA), which is the new management structure and server-to-server protocol used to administer the majority of XP server components by consolidating several MetaFrame 1.8 management applets into one Citrix Management Console (CMC). Citrix has also updated the SpeedScreen 3 technology to include predictive text entry and instant mouse click feedback.

Certification Objective 4.01: Identifying the Components of the ICA Packet

ICA is a general purpose presentation protocol developed by Citrix to provide the Windows community with functionality similar to that of X Windows on Unix. The ICA protocol, however, is much more efficient and robust, allowing more features and better performance over lower bandwidth connections. ICA is the physical line protocol used for communication between the client and the Citrix MetaFrame application server. The name of the data protocol that exports the application's graphical screen image is called thinwire. Thinwire is a logical data stream that flows encapsulated in an ICA packet. ICA must guarantee the delivery of the thinwire data stream with no errors and no missing or out-of-sequence data. The output of the thinwire protocol driver is a logical data stream that is sent through a virtual channel API, which takes the data stream and encapsulates it into an ICA packet. Once the ICA packet is formed, it optionally passes through a series of protocol drivers to add functionality like encryption, compression, and framing. It is then put on the transport layer and sent to the client. Once at the ICA client, the data packet passes through the same layers in opposite order, resulting in the graphical display of the remote application user interface on the client.

ICA packets consist of a required one-byte command, followed by optional data. This packet can be prefixed by optional components, negotiated at connection time, to manage the transmission of the packet. The nature of the transmission medium and user-defined options (e.g., encryption) influence the total packet definition. ICA packets consist of the format depicted in Figure 4-1.

Figure 4-1: ICA packet format

Only the command component will always be present in an ICA packet. All other components are optional.

• Frame Head Optional framing protocol header. Prefix for framing stream-oriented transport data.

• Reliable Optional reliable transmission protocol header. Prefix for error detection and recovery.

• Encryption Optional encryption protocol header. Prefix for managing encrypted data.

• Compression Optional compression protocol header.

• Command Beginning of base ICA protocol packet.

• Command Data Optional data bytes associated with the specified command.

• Frame Trail Optional framing protocol trailer. Suffix for framing asynchronous transport data.

The ICA protocol stack is dynamically configured to meet the needs of each transport protocol. For example, IPX is not reliable, so a reliable protocol driver is added above the IPX transport driver. However, since IPX is a frame-based protocol, a frame driver is not included. TCP is a stream protocol so a frame driver is included, and TCP is reliable, so a reliable driver is not added to the stack.

There are several different categories of ICA commands. These categories are discussed in the listing that follows:

1. Control Commands Control commands are a category of ICA command packets that manage the connection to the application server and the relationship to the local client user interface. Control commands include the following:

   • Server browsing

   • Connection initialization and negotiation

   • Screen control between the application server and the local client user interface

   • Keyboard and mouse input to the application server

   • Control of the keyboard indicator lights

2. Full-Screen Text A set of ICA command packets that permit the Citrix server to control the local client display in a full-screen text mode. These commands are normally not needed for Windows applications, however, they are important for supporting older, DOS-based clients. These commands involve less data transfer; therefore they typically have high display performance. Command packets are used to perform the following functions:

   • Set the text modes

   • Write characters

   • Adjust character attributes

   • Scroll

   • Control the cursor

3. Keyboard An ICA command packet containing one or more PC scan codes transmits keyboard data from the client to the server.

4. Mouse ICA command set used to track mouse coordinates and button states.

5. Virtual Channel Commands The ICA protocol supplies simultaneous control of multiple virtual channels. A virtual channel is used by application layer objects on a session-based connection to provide additional functions to the client in parallel to the ICA protocol. Some of the virtual channels are shown in Table 4-1.

Table 4-1: Virtual Channels

Thinwire Virtual Channel	An ICA virtual channel protocol used to transmit presentation commands from applications running on the server to the ICA client. The thinwire protocol has been optimized for transmission of Windows display objects across low-bandwidth links.
	Command and object-specific intelligent compression with state persistence (e.g. run-length encoding for bitmaps)
	Outboard complex clipping and complex curve drawing
	Intelligent caching of Windows objects, such as bitmaps, brushes, glyphs, and pointers
	Remote SaveScreenBitmaps
	Cross-session persistent caching
Printer Spooling Virtual Channel	A dedicated virtual channel used to transmit printer spooler data from the server to the client
Drive Mapping Virtual Channel	A virtual channel used to provide client drive mapping and file system functions
Parallel Port Mapping Virtual Channel	Provides access to the client's parallel port
Serial Port Mapping Virtual Channel	Provides two-way full-duplex access to client serial ports
Clipboard Virtual Channel	Provides a virtual mapping that allows users to copy and paste from the local clipboard to the server clipboard, and vice versa

Exam Watch 

The only component of the ICA packet that will always be present is the command section.

ICA data packets use optional protocol drivers to provide functionality across various network architectures. These drivers are not necessary for the operation of ICA itself and their use is negotiated during the ICA handshake that occurs at the beginning of a session. Protocol drivers for the most ubiquitous transport protocols such as TCP/IP (Transmission Control Protocol/Internet Protocol), NetBIOS (Network Basic Input/Output System), IPX/SPX (Internet Packet Exchange/Sequenced Packet Exchange), and PPP/SLIP (Point-to-Point Protocol/Serial Line Internet Protocol) are available but can be removed and/or replaced due to their position under the ICA protocol. This architecture provides ICA with a protocol independence that allows it to continue regardless of new networking technologies that may be developed.

Using ICA Over the Internet

A great way to provide access to applications to remote and home users is to allow connections to your MetaFrame servers over the Internet. This can come in many forms such as directly connecting to a server or published application, using NFuse to deliver a Web-based solution, or a VPN to provide access to Citrix servers residing on a private network.

On The Job 

Using ICA over the Internet is a great way to provide connectivity to users, but it is susceptible to latency and other network conditions. For mission- critical access, provide a backup access method such as a modem bank for dial-in.

ICA uses TCP port 1494 to establish sessions over TCP/IP and requires that this port be open on any firewalls between the client and server. Previous versions of WinFrame and MetaFrame used UDP port 1604 for ICA browsing traffic. Many companies had security concerns about allowing UDP traffic across their firewalls due to its connectionless nature. Citrix has addressed this concern in XP by using an XML (Extensible Markup Language) service on HTTP (Hypertext Transport Protocol) port 80 (or any other unused port you designate) for obtaining server and farm information.

On The Job 

Migrating your clients to use HTTP instead of UDP traffic is much easier to get approved by security. It is also more reliable since it is no longer connectionless.

Exercise 4-1: ConfiguriChapter 4ng the ICA Client to Use TCP/IP+HTT:

To start migrating your clients to an XP environment, begin by changing your client settings to use TCP/IP+HTTP if you have FR-1 running on your existing MetaFrame 1.8 servers. To do this:

1. Make sure that FR-1 and the XML service is installed on your ICA master browser.

2. Start Program Neighborhood and select the properties of your farm or connection, as shown in Figure 4-2.

   
   Figure 4-2: Farm properties

3. Change the network protocol to TCP/IP+HTTP.

4. Click the Add button to add an entry for your MetaFrame server and XML port.

5. Enter the new server location address and port as shown in Figure 4-3.

   
   Figure 4-3: Server and XML port definition

6. Click OK on the property page.

7. Your connection will now use XML over port 80 (or whichever port you entered as your XML port) to obtain server and application lists.

MetaFrame XP farms running in native mode will not respond to UDP broadcasts by default. There are two methods that allow an XP server to respond to UDP broadcasts.

1. Run the farm in mixed mode to provide compatibility to older clients while you complete your migration.

2. Set the individual server or farm to respond to client broadcasts.

Since UDP broadcasts do not cross subnets, you will need to enter one or more IP addresses or DNS (Domain Name System) names of the master ICA browser (data collector in XP) to allow the client to find the server and published applications. This also is true after you migrate to TCP/IP+HTTP as the client will still need to find the data collector server to obtain information on servers and published applications.

Using ICA Over Wireless LANs

Wireless LANs are becoming more prevalent now with the 802.11b standard equipment being available to home users as well as corporations. Many companies are installing wireless access points throughout their offices to provide easy access to corporate data as employees move about the building conferring with other staff on various projects. Conference rooms are a common place to find wireless connectivity because it provides LAN access to everyone in the room without the hassle of wires.

ICA is ideal for access to applications across wireless links as the bandwidth degrades with distance. 802.11b provides 1MB connectivity at the outer range, but this isn't always enough to run corporate applications. By using ICA to establish a session with a MetaFrame server, the lower bandwidth is more than enough to provide wireless users with LAN-like speeds.

As wireless technology proliferates further into the mainstream, places like airports and coffee shops are providing wireless access to the Internet while you wait for a connection or have a latte. Soon there will be 802.11b access points hanging from light posts where you can check your stocks, make restaurant reservations, or log in to the corporate VPN and MetaFrame to check your e-mail while waiting for the bus.

Now that you have a better idea of the structure of the ICA packet, here are some possible scenario questions and their answers.

Scenario & Solutions

What section of the packet is always present?	The command section
What are two common protocol headers?	Compression and encryption
What is used to provide additional functionality to the ICA protocol?	Virtual channels

---