Product Documentation

Planning Controllers

May 16, 2015

Regardless of your farm size, Citrix recommends having at least one server dedicated to controller functions, which are deployment functions other than those related to running published applications. Publishing applications on a controller slows down application enumeration. If you decide to install controller functions on a server hosting published applications, choose a server that hosts an infrequently used and not resource-intensive application (or lower the load threshold for that server so that it accepts fewer connections).

While farm size (small, medium, large) as determined by the number of servers, can indicate the general category of your farm, another factor to consider is the number of user connections. Because applications can scale differently from server to server (some servers might support 100 user connections, others might support only ten), looking solely at the number of servers might be misleading. Determine how you want to group controller functions by designing an initial configuration, then fine tune the design after testing the pilot farm.

As you add user connections in your test configuration, watch the Windows Performance Monitor counters:
  • When the peak number of users is connecting simultaneously to the farm; this usually occurs in the morning.
  • When the peak number of users is connected to the farm; this usually occurs during the day.

If the counters exceed the values listed in the table, move the controller functions on to separate servers until the counter metric no longer exceeds the value.

Performance Monitor Counter Name Criteria
CPU > 85% - 90%
Memory > 80%
ResolutionWorkItemQueueReadyCount > 0 for extended periods of time
WorkItemQueueReadyCount > 0 for extended periods of time
LastRecordedLicenseCheck-OutResponseTime > 5000 ms

Typically, you need to evaluate the LastRecordedLicenseCheck-OutResponseTime counter only in large farms.

Planning for Data Collectors

When planning for data collectors, consider:
  • If you need a dedicated data collector
  • If you do not need a dedicated data collector, which infrastructure services can share the same server
  • If you need a zone in each geographic region, which means that you need data collectors for those regions as well

To maintain consistent information between zones, data collectors relay information to all other data collectors in a farm, creating network traffic.

In general, data collector memory consumption increases as farm size increases. However, it is not significant. For example, the Independent Management Architecture service running on the data collector typically uses 300 MB on a 1000 server farm.

Likewise, CPU usage is not significant. A data collector hosted on a dual-processor server can support over 1000 servers in its zone. In general, CPU usage increases as the number of servers in a zone increases, the number of zones increases, and the number of users launching applications increases.

On most networks, Citrix recommends reducing the number of data collectors and zones. For example, if you have a farm with 100 servers in one location, Citrix recommends having one zone with a dedicated data collector (although you can have backup data collectors).

Citrix recommends installing XenApp on the server you want to host the data collector functionality and, after installing other member servers, configuring a server as the backup data collector.

Planning the XenApp Data Store

Updated: 2015-04-21

When you deploy your server farm, it must have an associated data store. When servers in a farm come online, they query the data store for configuration information. The data store provides a repository of persistent information, including:
  • Farm configuration information
  • Published application configurations
  • Server configurations
  • Citrix administrator accounts
  • Printer configurations

The System Requirements lists the databases you can use for the farm data store. For information about supported database versions, see http://support.citrix.com/article/CTX114501.

Choosing a Database

Consider these factors before deciding which database product to use:
  • The number of servers you currently plan to have in the farm, and whether or not you plan to expand that number
  • Whether or not you have a database administrator with the expertise to configure and manage a data store running on SQL Server or Oracle
  • Whether or not you foresee the enterprise expanding, which would result in expanding the size and maintenance of the database
  • Any database maintenance requirements, such as backup, redundancy, and replication

General recommendations are listed below, based on the following size table.

  Small Medium Large Enterprise
Servers 1-50 25-100 50-100 100 or more
Named Users < 150 < 3000 < 5000 > 3000
Applications < 100 < 100 < 500 < 2000
  • Microsoft SQL Server and Oracle are suitable for any size environment and are recommended for all large and enterprise environments. When deploying large farms across a WAN, you can obtain a performance advantage by replicating the data store and distributing the load over multiple database servers. SQL Server and Oracle are suitable for large farms and support replication.

    Do not install XenApp on the SQL Server or Oracle database server.

  • SQL Server Express is suitable for all small and many medium environments located in one physical location, which do not have branch offices across a WAN.

See the database product documentation for hardware requirements for the database server.

Important: Ensure that the data store is backed up regularly. If the data store database is lost, you must recreate the farm. You cannot recreate the data store from an existing farm.

Database Server Hardware Performance Considerations

Increasing the CPU power and speed of the database server can improve the response time of queries made to the data store when:
  • Starting the Citrix IMA Service on multiple servers simultaneously
  • Adding a server to the farm
  • Removing a server from the farm

The response time of other events (such as starting the IMA Service on a single server, recreating the local host cache, or replicating printer drivers to all servers in the farm) is affected more by the farm size than by the data store response time.

Adding processors to the server hosting the data store can improve response time when executing multiple simultaneous queries. In environments with large numbers of servers coming online simultaneously and at frequent intervals, additional processors can service requests faster.

The capabilities of the processor on the database server affect management console performance, how long it takes to add (configure) and remove a server from the farm, and how long it takes to start multiple servers simultaneously.

In the following chart, five sample farm configurations (A through E) are listed, with measurements of various metrics in the farm.

Configuration A B C D E
Number of servers in farm 50 100 250 500 1000
Number of applications published to all servers 50 50 50 50 50
Number of user policies 25 25 25 25 25
Printers per server 5 5 5 5 5
Printer drivers installed per server 25 25 25 25 25
Network print servers with printers 5 5 5 5 5
Number of Load Manager load evaluators 10 10 10 10 10
Number of application folders in management console 10 10 10 10 10
Number of server folders in management c onsole 8 16 25 50 50
Number of Application Isolation Environments 10 10 10 10 10
Number of Citrix administrators 10 10 10 10 10
Size of data store database in megabytes 32 51 76 125 211

The following table lists suggested hardware for the server hosting the data store, for each configuration in the previous table.

Configuration A B C D E
Dual Pentium 4/1.6GHz with 2GB RAM X X X    
Dual Pentium 4/3.0GHz with 4GB RAM X X X X  
Quad Pentium 4/3.0GHz with 4GB RAM X X X X X

The actual performance of a farm’s data store varies depending on the database engine and the level of performance tuning achieved.

Replication Considerations

A significant amount of network traffic for XenApp farms consists of reads from the data store; writes are infrequent. The amount of bandwidth required increases as farm size increases. Actions such as data store reads and restarting multiple servers simultaneously use disproportionately more bandwidth on larger farms.

Citrix recommends using a single data store for most deployments, but in some situations, placing a replicated data store at remote sites can improve farm performance. Citrix recommends replicating the data store across all high-latency or low-bandwidth WAN links. A replicated data store ensures all data store reads occur on the network local to the XenApp server.

In a WAN environment, place replicas of the data store at sites with a large number of servers; this minimizes reads across the WAN link. Database replication consumes bandwidth. Limit the use of replicated databases to configurations where the remote site has enough servers to justify the bandwidth cost of placing a replicated copy of the database at the site. For SQL Server, you must use immediate updating transactional replication.

Crossing high latency links without using replicated databases can create situations where the data store is locked for extended periods of time when performing farm maintenance from remote sites. Data store reads do not adversely affect local connections but remote sites can experience slower performance. This means that the Citrix IMA Service may start after extended periods of time and some normal operations may fail when initiated from the remote site.

Note: You might experience poor performance if you use a local XenApp management console to perform farm maintenance on a remote site that has high latency. You can resolve this issue by publishing the management consoles as applications on a server at the remote site and use a Citrix plug-in to access the published management tools.

Planning for Configuration Logging and IMA Encryption

The IMA encryption feature provides a robust AES encryption algorithm to protect sensitive data in the IMA data store. Enabling IMA encryption provides an additional layer of security for the data preserved by the Configuration Logging feature.

If you do not enable IMA encryption, XenApp uses the standard encryption used in previous versions of XenApp. The Securing Server Farms documentation contains more information about IMA encryption, Configuration Logging, and when to enable these features.

To enable IMA encryption, you specify a key which is used for all the servers in your farm. To generate the key, use CTXKEYTOOL, which is available on the installation media.

For custom installations or provisioning servers in large environments, consider:
  • Deploying XenApp by using images, and including the key file as part of the server image
  • Generating a key, putting the key in a folder on your network, using a UNC path to specify the location, and performing an unattended installation

If you have multiple farms in your environment, Citrix recommends you generate separate keys for each farm.

Designing Zones for a XenApp Deployment

A zone is a configurable grouping of XenApp servers. All farms have at least one zone. All servers must belong to a zone. Unless otherwise specified during XenApp Setup, all servers in the farm belong to the same zone, which is named Default Zone.

Zones have two purposes:
  • Collect data from member servers in a hierarchical structure
  • Efficiently distribute changes to all servers in the farm

Each zone contains a server designated as its data collector. Data collectors store information about the zone’s servers and published applications. In farms with more than one zone, data collectors also act as communication gateways between zones.

This illustration depicts a server farm with multiple zones. Each zone’s data collector communicates with the other data collectors across the WAN link.


Because session and load information within a XenApp farm can become large in enterprise deployments—up to several megabytes—to ensure a scalable and resilient XenApp farm, it is imperative that you design zones based on your network topology.

XenApp member servers replicate their dynamic data to the ZDC designated for their zone. XenApp uses a star topology for replication among zones—each ZDC replicates all of its zone dynamic data to all other ZDCs in the farm. Thus, it is important to design zones so that there is adequate bandwidth among ZDCs.

When designing zones, the most important variables to consider are latency and bandwidth. The amount of bandwidth and the impacts of latency are highly dependent on your XenApp deployment. The lower the bandwidth and the higher the latency, the longer a farm takes to resynchronize the dynamic data among zones after an election.

In farms distributed across WANs, zones enhance performance by grouping geographically related servers together. Citrix does not recommend having more than one zone in a farm unless it has servers in geographically distributed sites. Zones are not necessary to divide large numbers of servers. There are 1000-server farms that have only one zone.

Data collectors generate a lot of network traffic because they communicate with each other constantly:

  • Each zone data collector has an open connection to all data collectors in the farm.
  • During a zone update, member servers update the data collector with any requests and changed data.
  • Data collectors relay changes to the other data collectors. Consequently, data collectors have the session information for all zones.

In general, Citrix recommends using the fewest number of zones possible, with one being optimal. If all farm servers are in one location, configuring only one zone for the farm does not reduce performance or make the farm harder to manage. However, in large networks, such as organizations with data centers on different continents, grouping geographically-related servers in zones can improve farm performance.

Keep in mind that data collectors must replicate changes to all other data collectors in the farm. Also, bandwidth consumption and network traffic increase with the number of zones.

Separate zones are not required for remote sites, even ones on separate continents; latency is the biggest factor in determining if servers should be put in their own zone. For large farms with servers in different geographic regions, create zones based on the location of significant numbers of servers.

Also decide if you want to configure failover zones or preferred zones. If a zone fails, you can configure for user connections to be redirected to another zone (failover) or control to which zones specific users connect (preference). Failover requirements might determine the number of zones required.

For example, an organization with 20 farm servers in London, 50 servers in New York, and three servers in Sydney could create two or three zones. If the Sydney location has good connectivity to either New York or London, Citrix recommends grouping Sydney with the larger location. Conversely, if the WAN connection between Sydney and the other locations is poor, and zone preference and failover is required, Citrix recommends configuring three zones.

Consider these zone design guidelines:
  • Minimize the number of zones in your farm.
  • Create zones for major datacenters in different geographic regions.
  • If a site has a small number of servers, group that site in a larger site’s zone.
  • If your organization has branch offices with low bandwidth or unreliable connectivity, do not place those branch offices in their own zone. Instead, group them with other sites with which they have the best connectivity. When combined with other zones, this might form a hub-and-spoke zone configuration.
  • If you have more than five sites, group the smaller sites with the larger zones. Citrix does not recommend exceeding five zones.

Planning for the Web Interface and XML Broker

The Web Interface and the XML Broker are complementary services. The Web Interface provides users with access to applications. The XML Broker determines which applications appear in the Web Interface, based on the user’s permissions.

When determining whether or not to dedicate servers to the Web Interface and the XML Broker, consider scalability and security.

In small to medium farms, you can:
  • Run XenApp and the Web Interface on the same server, depending on your security considerations.
  • Group the XML Broker with other infrastructure services, such as the data collector or the data store, in very small farms (one to five servers). Citrix recommends grouping the XML Broker with the data collector.
In larger farms, Citrix recommends:
  • Configuring the XML Broker on data collectors or dedicated servers. In deployments with dedicated servers for infrastructure functions, dedicate a server to the XML Broker to accommodate authentication traffic.
  • Running the Web Interface on dedicated Web servers.

Do not publish applications on the server functioning as the XML Broker

Important: If you change the port used by the Citrix XML Service on the XML Broker, set the correct port in the plug-in.

Security Considerations

When users access the Web Interface from the Internet, Citrix recommends locating the Web Interface server on the internal network and the Citrix XML Broker with the XenApp farm. Shielding the XML Broker from the external Internet protects the XML Broker and the farm from Internet security threats.

If you must place the Web Interface in the DMZ and want to secure the connection between the XML Broker and the Web Interface, put the Web Interface server in the DMZ with Secure Gateway or Access Gateway. This configuration requires putting the Web Interface on a separate Web server. Install a certificate on the Web Interface server and configure SSL Relay on the servers hosting the Citrix XML Broker.

In very small farms, configuring the Web Interface and the XML Broker on the same server eliminates having to secure the link from the Web Interface to the farm. This deployment is used primarily in environments that do not have users connecting remotely. However, this might not be possible if your organization does not want Web servers such as Internet Information Services (IIS) in the farm.