Running XenApp in interoperability or multi-version farm mode for an extended period of time is not recommended.
Performing any Management Console (XenApp 4.0, XenApp 4.5, XenApp 5.0) function that crosses Citrix platforms is not recommended. (This includes running Installation Manager, Resource Manager, Custom Administrator or Publishing Applications). These functions should be run from the newest version management console whenever possible (or run as MFCOM or using scripts through the command line). Or, under certain conditions, run the corresponding administrative console against the same version servers (4.0 to complete tasks with 4.0 servers, 4.5 to 4.5, and so on).
When two or more versions run within a single farm, a number of potential issues might arise, including the following:
When an administrator needs to make changes, the console version should match the server version being modified. For example, if a server farm is based on both Presentation Server 4.0 and 4.5, changes to Citrix Policies should be made within the respective console version.
When running two or more versions, not all farm-wide capabilities can be invoked. For example, IMA Encryption and Configuration Logging can be enabled only when all servers are running Presentation Server 4.5 or later. Also, certain features such as custom administrator rights do not function correctly in these situations.
The user experience varies based on the XenApp Server being accessed. For example, if the user accesses a graphical application on a Presentation Server version 4.5 where SpeedScreen Progressive Display is enabled on Monday and then accesses that same graphical application on a Presentation Server version 4.0 on Tuesday, the user experience will be different.
Mixed server farms inherently have more issues and generate a higher number of support calls. In some environments running two or more versions of XenApp is necessary to meet business requirements during an upgrade. In this case, Citrix recommends that you limit the number of versions to two and that you minimize the period of time the two versions are operational in the server farm. Observing the server upgrade order is vital - first Farm Metric Servers, followed by Zone Data Collectors, and then Member Servers.
In large farms and those running mission-critical applications, it may be impossible to upgrade all servers during a single maintenance window. In these cases, follow the recommended installation order, and address considerations for functionality and logistics.
As x64 servers become more common, many Citrix customers find that the increased user density of these servers address their business and technical requirements. Because both 32-bit and 64-bit applications can be hosted on 64-bit servers, customers are finding that selecting x64 servers when installing new hardware provides a robust platform. In many cases, new 64-bit servers are added to existing 32-bit Presentation Server farms, producing a server farm based on both types of processors - which is supported by Citrix.
It is recommended that all servers run the same version of XenApp consistently. Main considerations for administrators are as follows:
Citrix recommends that when a Hotfix Rollup Pack (HRP) becomes available, administrators apply it consistently to all servers in the farm. When Citrix releases HRPs, two versions are released: 32-bit and 64-bit. If the server farm contains both types of servers, careful attention is needed when applying the correct HRP to the different servers. (The HRP for the 64-bit edition contains "64" in the file name, to help differentiate it.)
Citrix recommends that interim hotfixes should be applied only if necessary to address a specific issue or requirement. At this point, more Citrix customers are using the 32-bit versions of XenApp. This means that more issues are reported on this version, and so more hotfixes are created for it that may not have a 64-bit equivalent. If an administrator determines that a specific hotfix should be applied to 64-bit servers as well, an incident should be opened with Citrix Technical Support to have that same hotfix generated for the 64-bit servers. By doing so, consistency can be maintained within the server farm.
Because 64-bit servers inherently support a higher number of users because of their memory addressing architecture, administrators should consider revisiting the Load Manager design of the XenApp farm to confirm that effective load balancing has been implemented. This is especially true where either the Default or Advanced Load Evaluator is used. If server user load is used, it is likely that the 32-bit servers will demand more resources to service the same number of users, compared to 64-bit servers. This impacts the user experience. See Mixing Load Evaluators.
Server Resource Alerts
The configuration of alerts should be based on rules that are suitable for the server configuration, whether EdgeSight, Resource Manager or other monitoring tools are used. For example, 64-bit servers typically have more memory than 32-bit servers, and so less paging is generally required on more powerful servers. Monitoring alerts should be set to account for the server resource differences.
Peripheral Components
Because 64-bit servers are more costly than 32-bit servers, administrators can positively impact the total cost of ownership by using more powerful servers to host applications and to service the greatest number of users. For servers required to host peripheral components such as the Citrix License Server, Web Interface, and similar functionality, 32-bit servers are sufficient.
Multiple License Types
Sometimes a customer has various types of licenses and dates installed on a single Citrix license server. This is supported; however, the licenses are consumed based on the license type set for that server and the date, and in all cases, valid license dates are a requirement. Licenses are consumed based on the oldest valid date related to the version of the XenApp product launched. For example, if a customer has both Enterprise and Platinum licenses based on multiple dates, and User1 connects to a XenApp Server that is set to Enterprise edition, that license is allocated from the oldest Enterprise license group that is not exhausted. No Platinum functionality is available. If User2 connects to a XenApp Server that is set to Platinum, that license is allocated from the oldest Platinum license group. All Platinum functionality is available. If a user logs on to a XenApp Server set to an edition for which the licenses are exhausted, a license logon limit error appears.
For more information refer to Citrix Licensing.
Other known issues when mixing versions in one server farm:
Mixing Load Evaluators from different versions of XenApp might result in merging of Load Factors. For instance, when using the Memory/ CPU (Advanced Load Evaluator) - larger servers are not stopped from accepting new connections, continue to take on new users, and eventually run out of memory. This is also true in mixing 32-bit and 64-bit servers in a farm. The 64-bit server might continue to take on load. Workaround: Use the Default Load Evaluator (User Load) in mixed server farms. Configure each server type for optimum user load based on observed behavior.
The Web Interface should override the ICA client name option is enabled as the default setting. If it is unchecked, there is a problem in a non-default Web Interface configuration of a XenApp 4.5 or later server acting as the XML broker. Web Interface requests a ticket from a XenApp 4.0 member server using a call that is not implemented on the XenApp 4.0 server. In a version 4.0 and 4.5 mixed farm, when overriding the Web Interface default client name option, the version 4.5 Zone Data Collector fails and does not launch applications. Workaround - use the Web Interface default as shipped.
To take full advantage of the Configuration Tracking feature in XenApp 4.5 or later, administration must be done using that version of the console. Currently, in a mixed environment there is no way to prohibit the use of a XenApp 4.0 Console. Thus, changes from that console could not be tracked from the version 4.5 console.
Running the Citrix Management Console (4.0) and Access Management Console installed on the Zone Data Collector server is not recommended and can cause corruption in the Data Store.
From CTX116492 - Key Infrastructure XenApp Server Tuning.
To reduce non-essential load on the Key Infrastructure Servers, do not run or point the Access Management (or Presentation Server) Console (running on another computer) to a Zone Data Collector or XML Broker Server. There have been cases reported of Data Store corruption caused by rebooting a Key Infrastructure Server during a live console update.
DSCheck Considerations:
Data Store manipulation using DSCheck is not recommended unless Citrix Technical Support is engaged. Depending on the version of DSCheck and the function chosen, erroneous reported errors based on incorrectly located Data Store data may result.
There are specific versions of DSCheck available for specific XenApp versions. For instance, the version 6.x version is written for XenApp 4.5, not for XenApp 4.0.
Always check with Citrix Technical Support before running DScheck. Always back up your Data Store before running DSCheck with options.