Design Consideration NetScaler 8.0

Consulting Solutions

NetScaler Global Server Load Balancing for Presentation Server and Access Gateway (All Editions) Deployments

Overview

1

Simply deciding to use Server Load Balancing (SLB) and Global Server Load Balancing (GSLB) for Citrix Presentation Server and Citrix Access Gateway deployments is easy. Designing your solution to fit with your business needs requires an understanding of your current architecture, which will likely impact the final implementation of the solution. This article covers the design considerations you must take into account when pursuing the GSLB integrated solution with Presentation Server environments. Topics for consideration are: Presentation Server farm architecture SSL versus non-SSL monitors Server Load Balancing method Global Server Load Balancing method Active/Passive sites Load Balancing Access Gateway Enterprise Edition

Presentation Server farm architectureBefore deploying a GSLB solution into an environment, the impact to Presentation Server and the overall architecture must be considered. The decision will end up focusing on whether it is best to deploy a single cross-site farm or multiple single-site farms. Each solution comes with its own set of benefits and considerations that must be addressed and assessed before selecting the course of action. To better understand the challenge, take a look at Figure 1, the site selection and application launch process (simplified).

1

Access Gateway Standard Edition and Access Gateway Enterprise Edition terminology and graphics are used interchangeably within this document. Design considerations apply for both editions unless specified otherwise.

2

Site 1: Display Login Page and Authenticate

Display Available Applications

Select Desired Application

Start

Enter in URL address for Access Gateway

NetScaler determines Site

Application Launch

Done

Site 2: Display Login Page and Authenticate

Display Available Applications

Select Desired Application

Figure 1 - Site-Application Launch Process Flow Note: The determination of the appropriate site occurs before the user selects their application. Depending on the Presentation Server architecture selected, users would end up with different application sets within Web Interface or end up having the Presentation Server sessions cross the WAN link and then cross the public link. These challenges are discussed in the following subsections.

Single Cross-Site FarmFigure 2 best explains the impact that a single, cross-site farm architecture can have on inter-site communication and usability.

Site A

IMA: 2512 2513

WAN

94 : 14 ICA

ICA :1 49

4

Site B

Figure 2 - Single Cross-Site Farm Architecture The following list describes the characterization of the architecture: Both sites are part of the same Presentation Server farm Many applications are delivered through Presentation Server from both sites A few applications are only delivered with Presentation Server from one site. Certain applications have back-end systems (databases)

3

Each site has its own point of presence into the environment through a local Access Gateway

The goal with a single, cross-site farm is to have users directed to the best site and have as many applications as possible delivered from the closest site. Users should only be delivered applications from the remote site(s) if the local site is unable to fulfill the user request. For this architecture to function, the farm must be capable of communicating cross-site. This means IMA communication must be supported across the WAN. Also, the GSLB feature of NetScaler is informing the user which Access Gateway is most preferred through the different load balancing criteria utilized. The Access Gateway the user is sent to through load balancing is the users point of presence into the production environment for the duration of the session. To better understand this, take the following as an example: NetScaler tells User A to connect to Site A, where the user establishes a session to Site As Access Gateway. User A selects Application B for delivery. Application B is capable of being delivered from either site, but a server in Site B has the least load. Site As Access Gateway delivers Application B from a Presentation Server in Site B due to Presentation Server load balancing. This means the application delivery protocol, ICA, will cross the WAN link for the duration of the Presentation Server session.

Ideally, Application B would have been delivered from a Presentation Server in Site A as it is local to the users pointof-presence into the environment. By incorporating the Zone Preference and Failover functionality and with a minor Web Interface modification, this preferred delivery process can be achieved. Zone Preference and Failover will deliver applications from the most preferred zone (location) based on policy configurations. This can be achieved by doing the following: Create Presentation Server zones for each site and include the respective Presentation Server in the correct zone. Web Interface can create a dynamic client name beginning with WI_. By slightly modifying the Web Interface configuration, the WI_ can be changed to WA_ for Site As Web Interface Servers and WB_ for site Bs Web Interface servers. o On Site As Web Interface, find the C:\inetpub\wwwroot\citrix\accessplatform\app-data\site\serverscripts\session.aspfx file. Modify the line from deviceInfo.setClientName( clientName ) To: deviceInfo.setClientName( clientName.Replace("WI_","WA_") ); o On Site Bs Web Interface, modify the line from deviceInfo.setClientName( clientName ) To: deviceInfo.setClientName( clientName.Replace("WI_","WB_") ); Create two new Presentation Server Policies: o Zone Preference Policy Site A: Preferred Zone: Zone A Backup Zone 1: Zone B Applied this policy to: Client names with WA_* o Zone Preference Policy Site B: Preferred Zone: Zone B Backup Zone 1: Zone A

4

Applied this policy to: Client names with WB_* This solution will keep users application delivery local to their point-of-presence unless the local Presentation Servers are unable to service the request, which will deliver applications from the next preferred zone.

Multiple Single-Site FarmFigure 3 best explains the impact that a multiple, single-site farm architecture can have on the solution. The following list describes the characterization of the architecture: Both sites are their own Presentation Server farm Both sites are hosting the same applications Both sites are hosting the same set of applications Each site as their own point of presence into the environment through a local Access Gateway

ICA: 1494

Site A

Access Gateway Web Interface Data Collector Application Silo Replication Traffic Application 1 Backend Application 2 Backend

NetScaler

Site B

WAN

Access Gateway Web Interface ICA: 1494 Data Collector Application Silo Application 2 Backend

Figure 3 - Multiple Cross-Site Farm Architecture Even though this architecture has multiple farms, the overall goal is to have Presentation Server sessions stay local to the site, thus eliminating ICA from the WAN link. This goal has some technical challenges that must be addressed to provide a usable solution. A user can access any application regardless of the site they have established a session to. If an application has a corresponding back-end database, the application, regardless of site, must be able to contact the back end. The two options to overcome this requirement are The Presentation Server can access the application backend over the WAN link. This will undoubtedly result in poor application performance as the data requests and responses must cross the WAN link. The poor performance can be mitigated by implementing either NetScaler and/or WANScaler, depending on the type of traffic being generated. The application back end could be replicated across the WAN link to the remote site. This would improve application performance from the Presentation Server. However, the replication of data could consume the WAN link. This risk can be potentially overcome by utilizing WANScaler between sites to compress and optimize the communication.

5

SummaryThe previous two sections explained the architecture and challenges with a single, cross-site farm and multiple, singlesite farms. The decision on the most appropriate solution will be based on the technical characteristics and the business needs. Regardless of the option selected, the following table will help guide the decision by focusing on the overall benefits and considerations for both options. Benefits Single, Cross-Site Farm Only one farm to manage and maintain Applications can be hosted in any site No requirement for cross-site replication of application data A WAN link is not needed for intra-farm communication User stays local to the site for the duration of the Presentation Server session Might not require cross-site replication of application data

Considerations Must allow for intra-farm communication going between sites ICA sessions will cross WAN link versus public link All farms must support the same applications Must optimize access to back-end data that is opposite the WAN link from the Presentation Servers Must optimize the replication of application backend data if the organization requires the Presentation Server access back-end data locally

Multiple, Single-Site Farms

If the environment cannot implement a WAN optimization, compression, and caching solution like NetScaler or WANScaler, a single, cross-site farm is the best solution as it overcomes the most challenges.

SSL vs non-SSL monitors2,3Early decisions in the design of a Presentation Server farm can have repercussions on the design of Global Server Load Balancing. Luckily, those decisions are not show-stoppers. These decisions revolve around the communication flows of: Access Gateway to Web Interface: In certain configurations, Access Gateway contacts the Web Interface to authenticate the user. The users credentials are sent either over HTTP 80 or SSL 443 to the Web Interface server. As Access Gateway almost always is located in the Demilitarized Zone (DMZ), the credentials are at risk of being stolen. Because of this, many organizations opt to protect their Web Interface server with a server certificate, thus encrypting Access Gateway to Web Interface communication over SSL 443. Web Interface to XML Brokers: Once Web Interface has the credentials; it sends them onto the XML Broker for authentication. Just like the Access Gateway to Web Interface example, this communication can occur over HTTP 80 (or any other port) or SSL 443. But unlike the Access Gateway to Web Interface example, many organizations chose not to encrypt this communication as the traffic is almost always occurring on the secured, internal network.

In a large percentage of environments, organizations protect the Access Gateway to Web Interface communication with SSL certificates but do not protect the Web Interface to XML Broker communication. This implementation results in a challenge with the configuration of GSLB. In the end, the goal of Global Server Load Balancing is to provide an IP address for the preferred sites Access Gateway. However, it would be unwise to present a user with an IP address for a site if there are no Web Interface servers or XML Broker servers available. This requires the GSLB decision to take into account the availability of these resources as well.

2

Certain versions of NetScaler experience this design requirement whereas other versions do not. This section will help overcome potential challenges. 3 This section is only focusing on Access Gateway Standard Edition. The concepts can be used with Access Gateway Enterprise Edition if needed.

6

A GSLB service will represent a site. This service will take into account the availability of Access Gateway devices, Web Interface servers and XML Broker servers through the use of monitors. Because the service is load balancing Access Gateway devices, the service will operate on SSL_Bridge port 443 as the Access Gateway device must be the SSL endpoint. Certain versions of NetScaler require that any monitor bound to a SSL GSLB service must also be SSL. This is not a problem if Web Interface and the XML Broker servers are secured with server certificates, but in most cases they are not. This type of implementation will not allow for a multi-layer site monitoring for GSLB unless changes are made to the environment. There are essentially two options: Secure the Web Interface and the XML Broker servers with server certificates. This would allow NetScaler to monitor these servers with secured monitors over SSL. Create a NetScaler SSL secured virtual server (vserver) for the corresponding unsecured services (Web Interface and XML Broker). The SSL secured vserver will perform SSL offloading, allowing the unsecured services to continue using HTTP 80.

Option 1: Secure Web Interface and XML BrokerAs the GSLB service will operate on SSL port 443, the Web Interface and XML brokers must also be secured and communicating on port 443. The first step is to secure both sets of servers with server certificates and reconfigure the Web Interface and XML Broker settings to communicate with SSL port 443. Once both sets of servers are protected with server certificates, communication between Access Gateway and Web Interface and between Web Interface and the XML Brokers will occur over HTTPS 443.Service_wi_a_01 172.17.2.26 SSL_Bridge Port 443 Monitor gslb_mon_web_a SSL 172.17.1.26 Site A Vserver_web 172.17.1.26 SSL_BRIDGE Port 443 Service_wi_a_02 172.17.2.27 SSL_Bridge Port 443 Monitor ctxweb TCP Port 443 Monitor ctxweb TCP Port 443

Web Interface

Web Interface

Service_xml_a_01 172.17.2.28 SSL_Bridge Port 443 GSLB Virtual Server vgslb cag.citrixlab.com GSLB Service gslb_cag_a SSL_BRIDGE 443 172.17.1.12 Monitor gslb_mon_xml_a SSL 172.17.1.28 Site A Vserver_xml 172.17.1.28 SSL_BRIDGE Port 443 Service_xml_a_02 172.17.2.29 SSL_Bridge Port 443

Monitor ctxxml TCP Port 443

XML Service

Monitor ctxxml TCP Port 443

XML ServiceService_cag_02 172.17.2.30 SSL_Bridge Port 443 Monitor gslb_mon_cag_a SSL 172.17.1.30 vserver Vserver_CAG 172.17.1.30 SSL_BRIDGE Port 443 Service_cag_01 172.17.2.31 SSL_Bridge Port 443

Access Gateway

Access Gateway

Figure 4 - Secure Web Interface and XML Broker The GSLB Service, operating on SSL_Bridge port 443, will monitor the three sets of components vservers for resource availability (vserver_web, vserver_xml and vserver_cag). Because each vserver is operating on port 443, the corresponding monitors will also operate on port 443. These three monitors can be bound to the GSLB service for the site as there is congruency between the monitor configurations. This solution will require modifications to the Web Interface and XML Broker servers. Also, new server certificates must be generated and installed on the Web Interface and XML Broker servers. Finally, if an enterprise Certificate

7

Authority (CA) was used to generate the server certificates, the enterprise CA root certificates must be set up and installed on the appropriate devices (Access Gateway, Web Interface, client devices) to complete the SSL communication.

Option 2: Create SSL Offload VServersIn the end, the GSLB Service will have three monitors bound to it, all operating on port 443. However, if the Web Interface and XML Brokers are not secured with server certificates, an intermediate solution is required. A monitor will probe a vserver on SSL port 443, and the vserver will load balance the components on HTTP port 80. NetScaler is capable of performing SSL offload, where the traffic entering occurs on SSL port 443 and the traffic exiting operates on an unsecured protocol (HTTP port 80).Service_wi_a_01 172.17.2.26 HTTP Port 80 Monitor ctxweb TCP Port 80

Site A Vserver_web 172.17.1.26 HTTP Port 80 Monitor gslb_mon_web_a SSL 172.17.1.26 vserver Dummy_SSL_Web_A 172.17.1.26 SSL Port 443

Web Interface

Service_wi_a_02 172.17.2.27 HTTP Port 80

Monitor ctxweb TCP Port 80

Web Interface

Monitor gslb_mon_xml_a SSL 172.17.1.28

vserver Dummy_SSL_XML_A 172.17.1.28 SSL Port 443 Site A Vserver_xml 172.17.1.28 HTTP Port 80

Service_xml_a_01 172.17.2.28 HTTP Port 80

Monitor ctxxml TCP Port 80

XML Service

GSLB Virtual Server vgslb cag.citrixlab.com

GSLB Service gslb_cag_a SSL_BRIDGE 443 172.17.1.12

Service_xml_a_02 172.17.2.29 HTTP Port 80

Monitor ctxxml TCP Port 80

XML ServiceService_cag_02 172.17.2.30 SSL_Bridge Port 443 Monitor gslb_mon_cag_a SSL 172.17.1.30 vserver Vserver_CAG 172.17.1.30 SSL_BRIDGE Port 443 Service_cag_01 172.17.2.31 SSL_Bridge Port 443

Access Gateway

Access Gateway

Figure 5 - SSL Offload VServers A new server load balancing vserver (dummy_ssl_web_a and dummy_ssl_xml_a) can be created that operates on SSL port 443, while a second vserver (vserver_web and vserver_xml) using the same virtual IP address and load balancing the same services will operating on HTTP port 80. Monitors for GSLB will be created that operate securely and monitor the vservers that are secured with SSL port 443. In order to complete this configuration, NetScaler uses a self-signed certificate for the dummy SSL vservers. Those vservers will be able to monitor the unsecured server load balancing services operating on HTTP port 80 (service_wi_a_01, service_wi_a_02, service_xml_a_01 and service_xml_a_02). This solution required no modifications to the Web Interface or XML Broker servers. The only certificates required were requested and generated from the NetScaler and only installed on the NetScaler.

Server Load Balancing methodAn important aspect when designing the server load balancing solution is determining how sessions should be routed to the load balanced pool. NetScaler includes fourteen different load balancing methods. Which one should be selected is

8

based upon what is being load balanced and the types of sessions the server maintains. The following recommendations are for a standard Presentation Server environment:

Load Balancing Method Access GatewayLeast Connections

Alternative MethodRound Robin, Least Response

JustificationBeing used purely for ICA encapsulation with SSL, a single end-point will create a single TCP connection to Access Gateway. Access Gateway will then connect to the amount of Presentation Servers on the backend required to fulfill the endpoint's request. As each endpoint creates a single connection, the least connection load balancing method will help to ensure that all Access Gateways are balanced equally. However, if Access Gateway is being used in full SSL-VPN mode, another load balancing method is recommended as additional protocols and ports connecting to Access Gateway could result in uneven performance across devices.

Web Interface

Least Response Time

Round Robin, Least Connections

Web Interface is a light Web application, meaning that users do not interact with the site and the site has minimal resource impact. The most important thing from a users perspective when being load balanced to a Web Interface server is that they are being directed to the fastest responding system. By using the Least Response Time load balancing method, users should receive the fastest possible service at that particular time. Requests to the XML Broker directly impact the speed of application enumeration and application launch. Having NetScaler determine the server with the fastest responding XML Broker will help to improve performance.

XML Broker

Least Response Time

Round Robin, Least Connections

Global Server Load Balancing methodThe core reason for utilizing global server load balancing is to direct the user to the best available site. The question comes down to how is Best determined? NetScaler has eight different global server load balancing methods that can be used to determine which site is the best for the user. In order for many of these global server load balancing methods to function, each NetScaler must communicate with every other sites NetScaler using the Metric Exchange Protocol. The following offers general recommendations for the most common global server load balancing methods for Presentation Server deployments: Justification Round RobinDistributes users in an even manner, and has the additional intelligence of health checks to avoid sending users to failed sites. Weighted round-robin allows network administrators to shift load to sites with higher capacity or lower operating costs. Although this method will only send users to sites with availability, it does not take into account site usage and response times. Directs the traffic to the service with the least number of active client connections / the least response time/ the least bandwidth consumption/least number of processed packets. The metric exchange protocol needs to be enabled for these methods to work as defined. Depending on the usage of each site, this method could result in users being sent to a site that is farther away. Geographic information can be configured for each site so that users are sent to a nearby datacenter based on pre-configured IP maps or through response times used to send users to the highest-performing site. In addition, a site can be designated as a backup for other sites, and will only be used if all of the other sites are offline. This solution should prevent users from being sent to the furthest site, but the services at the sent could be overloaded. It is important to note that these types of solutions use the users DNS server to determine proximity. If the users DNS server is located in Fort Lauderdale, Florida, but the user is in London, proximity-based global server load balancing would place the user in Florida. If the DNS server entries are automatically modified based on the users location, this concern is not warranted.

Least Connections Least Response Least Bandwidth Least Packets Proximity Based

9

Active-passive sitesMany organizations employ an Active-Passive model when it comes to disaster recovery. In an Active-passive model, one site is always used for user sessions, while a secondary site is used only in the event of a failure at the active site. In essence, the request would resemble the following flow identified in Figure 6.

Figure 6 - Active-passive 1. User makes a request, which goes to the users configured DNS server. 2. The DNS server forwards the request onto NetScaler in Site A, which acts like an authoritative DNS server. The DNS server is also configured with the NetScaler at Site B as a secondary forwarding entry in the event that the NetScaler in Site A is down. 3. NetScaler identifies the site is not able to service the request with the active site and the user is forwarded onto the passive site. However, with a default implementation of Global Server Load Balancing, the site will result in an Active-Active configuration. With minor changes to the Global Server Load Balancing configuration, NetScaler can be used to provide Active-Passive failover between sites. There are a few ways of achieving this functionality and the remainder of this section will discuss two options. Backup Domain Backup Virtual Server

Backup DomainThe easiest method for providing an Active-Passive configuration with Global Server Load Balancing is to utilize the Backup IP option within the GSLB domains configuration. In this configuration, there is only a single GSLB virtual server. Each GSLB service corresponds to a single site. There can be any number of active sites, but only one passive site. As shown in Figure 7, there is one active site (service_vgslb_a) and one passive site (service_vgslb_b). Only the active sites service should be bound to the GSLB virtual server, while the passive sites service is left unbound.

10

Figure 7 - GSLB Services The next step in the configuration is to update the Backup IP for the domain name used by the GSLB virtual server. The Backup IP address should be the IP address used for the passive site. This configuration must be completed at all sites.

Figure 8 - Backup Domain

When all bound services for the virtual server are offline, NetScaler will respond to the domain request with the IP address configured as the Backup IP. This configuration is a last-ditch option; it assumes the passive site will be available in the event of a disaster at the active site. As soon as any active site comes back online, all new requests will be sent to the active site, bypassing the passive site.

11

Backup Virtual ServerThere are instances when the Backup Domain option will not meet all requirements as it does not provide the ability to keep the original passive site as the active site when the original active site is online again. This functionality can be provided with the use of backup virtual servers. The configuration of a backup virtual server requires unique GSLB services for each site, just like the Backup Domain option explained in the previous section. The configuration differs in that the backup virtual server option requires a second GSLB virtual server for the passive site as seen in Figure 9.

Figure 9 Virtual Servers The passive sites virtual server is only bound to the GSLB service corresponding to the passive site, while the active site virtual server is bound to the GSLB service for each active site. This can be seen in Figure 10 Active Site Passive Site

Figure 10 - Bound Services

12

Also, only the active sites virtual server contains the domain name, while the passive site is blank. This can be seen in Figure 11. Active Site Passive Site

Figure 11 - Domain Name The next step required to set up an Active-passive configuration takes place within the Advanced tab for the active sites virtual server configuration. An option is available to select another virtual server to act as a backup in the event that the primary virtual server has no services available. By specifying the passive sites virtual server, an Activepassive configuration is complete. Active Site Passive Site

Figure 12 - Backup VServer Selecting the Disable Primary When Down option keeps the backup virtual server (passive site) active when the primary site comes back online. This level of control was not possible with the Backup Domain option detailed earlier.

13

Load balancing Access Gateway Enterprise 4 EditionProviding load balancing to Access Gateway Enterprise Edition devices can take on numerous architectures because, with proper licensing, Access Gateway Enterprise Edition functionality can be co-hosted from the NetScaler device responsible for Server/Global Server Load Balancing. This type of architecture allows for different types of load balancing for the SSL VPN functionality. Each option is valid based on the needs of the organization. The following options will be addressed: High Availability Front-end Load Balancer Integrated Load Balancing

High AvailabilityIn many situations, the goal of load balancing is to provide fault-tolerance in the event of a system failure and not to increase scalability. Scalability concerns when using Access Gateway Enterprise Edition can be overcome by purchasing a larger, more powerful device. By purchasing a bigger device, every user in an organization can potentially be supported from a single device. To provide fault-tolerance, a second device should be purchased and configured for High Availability. With a High Availability configuration, one Access Gateway device (passive) will monitor the second Access Gateway device (active). Session tables and configurations are kept synchronized between the two devices. If the passive device sees a failure of the active device, the passive immediately takes over the responsibility of the active device and re-establishes the sessions on the users behalf. Most users are unaware of the failure as their sessions stay active even though they were transferred between two Access Gateway devices. High Availability is the simplest solution to provide Access Gateway fault-tolerance.

Front-End Load BalancerIn a front-end load balancer scenario, the Access Gateway SSL VPN functionality is separated from the device providing Server and Global Server Load Balancing decisions. The architecture and configuration of this model is identical to how Server and Global Server Load Balancing is designed when using Access Gateway Standard Edition.

Site A

Figure 13 - Front-End Load Balancer This type of configuration is easy to understand from a configuration and architecture standpoint as the components are separate. However, this solution can be costly as it does require the purchase of at least one additional NetScaler device per site (two if High Availability is used, which is highly recommended).4

This section is only for Access Gateway Enterprise Edition. Access Gateway Standard Edition does not have this particular design decision.

14

Integrated Load BalancingThe final option is to use the integrated features to provide Server/Global Server Load Balancing. This scenario requires the appropriate licensing to allow all options to function on the same device. This configuration is slightly more confusing than the front-end Load Balancer as the NetScaler Server Load Balancing functionality cannot be used to load balance the integrated Access Gateway component. Instead, Global Server Load Balancing must be used. With the previous two options (High Availability and Front-End Load Balancer), a GSLB Service corresponded to a single site. In this scenario, a GSLB Service corresponds to a single Access Gateway device. A single site could contain multiple GSLB Services, based on the number of Access Gateway devices present at the site. The same requirement is still valid that users should be sent to a site (GSLB Service(s)) only if all required resources are available (Access Gateway, Web Interface and XML Brokers). In addition to the monitors created to probe the Web Interface and XML Broker virtual servers, additional monitors are needed to watch individual Access Gateway devices as shown in Figure 14.

Figure 14 - GSLB Architecture The following explains the architecture: SiteA has two Access Gateway devices, which means there should be two GSLB Services (gslb_cag_a and gslb_cag_b). GSLB_CAG_A o o o Verifies Access Gateway #1 is available with the gslb_mon_a_1 monitor Verifies at least one Web Interface is available at the site by using the gslb_mon_web_a monitor. This monitor is probing the Web Interfaces load balancing virtual server. Verifies at least one XML Broker is available at the site by using the gslb_mon_xml_a monitor. This monitor is probing the XML Brokers load balancing virtual server.

GSLB_CAG_B o o Verifies Access Gateway #2 is available with the gslb_mon_a_2 monitor Verifies at least one Web Interface is available at the site by using the gslb_mon_web_a monitor. This monitor is probing the Web Interfaces load balancing virtual server. This is the same monitor used for Access Gateway #1.

15

o

Verifies at least one XML Broker is available at the site by using the gslb_mon_xml_a monitor. This monitor is probing the XML Brokers load balancing virtual server. This is the same monitor used for Access Gateway #1.

Although this solution utilizes additional GSLB Services, it is effective at load balancing SSL VPN connections to multiple Access Gateway devices while still using any number of load balancing methods like round robin, least response time, and so on.

16

Notice The information in this publication is subject to change without notice. THIS PUBLICATION IS PROVIDED AS IS WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. CITRIX SYSTEMS, INC. (CITRIX), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE. This publication contains information protected by copyright. Except for internal distribution, no part of this publication may be photocopied or reproduced in any form without prior written consent from Citrix. The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products. Citrix does not warrant products other than its own. Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies. Copyright 2007 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009 U.S.A. All rights reserved.

Version HistoryAuthor Daniel Feller Version 1.0 Change Log Document completed Date December 3, 2007

851 West Cypress Creek Road

Fort Lauderdale, FL 33309

954-267-3000

http://www.citrix.com

Copyright 2007 Citrix Systems, Inc. All rights reserved. Citrix, the Citrix logo, Citrix ICA, Citrix MetaFrame, and other Citrix product names are trademarks of Citrix Systems, Inc. All other product names, company names, marks, logos, and symbols are trademarks of their respective owners.