| 
XenApp Configurations - Assessing the following factors will help in determining the types of configurations to make in a XenApp environment:
- Base image considerations
- Capacity planning
- Load balancing
- Policy configuration
- XenApp optimizations
- Virtualized XenApp components
Load Balancing
Load evaluators maximize system efficiency by balancing online application sessions across the farm. The rules associated with a load evaluator determine the load level of a server at any given time. Servers that report a full load do not allow new connections until the calculated load falls under the high threshold. You should use and configure custom load evaluators whenever possible using applicable criteria to determine load on the XenApp servers. Avoid certain load evaluator rules, or use them carefully to prevent situations in which a user is unnecessarily prohibited from connecting to XenApp resources. Rules that result in fluctuating values can cause a server to report a full load. It is crucial for you to understand how the applications function in your environment to ensure that you configure a custom load evaluator with the correct rules. For example, if a load evaluator is created and configured to report a full load based on high memory utilization, applications that are CPU intensive can easily cause a server to report a full load.
Note: You can create a new load evaluator using Citrix AppCenter. The new load evaluator can then be applied directly to an application, or the servers running the application using Load Balancing policies and worker groups. If a load evaluator is applied to both, the load is calculated by measuring the load at the server level and then the application level; the greatest value is taken
Policy Configuration - You can manage a virtualized environment by applying Active Directory Group Policy Objects and Citrix policies. By design, most Citrix policies do not conflict with Active Directory policies. If there is a policy overlap, Citrix policies always take precedence over Windows policies and settings, except in the case of security as it relates to encryption and shadowing. Configuring policies as Active Directory Group Policies is recommended to provide consistency for the environment and end users. You can manage a newly built server by placing it in an Active Directory Organizational Unit (OU) and applying Group Policies to that OU. When troubleshooting, you can temporarily move a server out of an OU to remove the applied policies. You can then determine if any of the policies or settings applied to the OU caused any of the issues to the server.If the policies are not applied to the OU and instead are applied to the server, you can troubleshoot an issue by setting the policies to the Deny state. If a set of policies is applied to a server, you can attempt to locate the issue by denying each policy individually and properly testing the server. Applying Citrix policies with the user filter or to a server using the worker group filter is recommended for a XenApp farm environment. Citrix policies can also be applied to client IP addresses, client names, and users of the Citrix Access Gateway, but these filters can lead to static management of a dynamic environment.
Examples of policies that streamline the end user experience include:
- Client drive mappings
- HDX technologies
- Printers configurations
- Time zone settings
XenApp Optimizations
- Automatic Updates: You should disable automatic updates for applications and the operating system because all changes to XenApp servers should be tested and validated before implementing into production. In an environment with provisioned XenApp servers configured as standard image mode vDisks, any installed updates will be lost upon restart. If automatic updates are enabled, the update services will identify new updates and make requests to update every time a XenApp server restarts. A best practice is to review each operating system and application update as they release. If the update is approved, update the base vDisk image for the XenApp servers. After the provisioned XenApp servers restart, they will use a vDisk image containing the latest updates
- Event Logs: An event log is commonly used to identity and troubleshoot issues within an environment and can also act as a security audit log. Provisioned XenApp servers, which operate best when configured as a standard image mode vDisk, lose any changes made to the system upon restart; this includes changes in the event log. You can change the location of the event log files, but that location must be a local drive. If the event log files are stored on a network share, the event log fails to save messages.
Events can be collected in the following places:
• Local Storage
• Citrix EdgeSight
• Microsoft Event Collection Services (only available in Windows Server 2008)
Printing Optimizations: While configuring an online application in the AppCenter, you should enable the Start this application without waiting for client printers to be created option in the published application properties. Launching an application before the creation of printers can help reduce the load on the application, which results in a reduction of load on the XenApp server.
Note: This option should not be selected for applications that need to use the print function immediately after being started
- Base image considerations
- Capacity planning
- Load balancing
- Policy configuration
- XenApp optimizations
- Virtualized XenApp components
Base Image Considerations - The base image of a XenApp server always includes the installation of an operating system and XenApp software, but you must decide which other common elements to include in order to keep the number of managed images to a minimum. The following list is a general recommendation of items to include in the base image:
Clients and Plug-ins - Include the appropriate clients and plug-ins, which can include the Online, Offline, and the Single Sign-on plug-ins
Root certificates - Include the appropriate root certificates in the base image of all XenApp servers
Common applications - Include the common applications, such as Adobe Flash, Microsoft Silverlight, or Adobe Reader
Common configuration settings - Include the common criteria for XenApp server settings to keep the number of managed images to a minimum
Hotfixes and service packs - Include the latest OS and XenApp hotfixes and service packs in the XenApp server base image after proper testing
XenServer / VMware tools (if applicable) - Include XenServer tools to provide custom Windows drivers and a management agent for all XenServer virtual machines
Application Inclusion - You must decide if there is a need to include any installed applications as part of the base XenApp image. The decision to include applications is determined by factors unique to each organization.
Example: Application Inclusion Factors - Some organizations prefer to separate applications from the base image to align with the following organizational structure of the business:
Application Administrators - This group is responsible for profiling, packaging, and updating applications used by the XenApp server
Citrix Administrators - This group is responsible for creating and maintaining the base image with the latest hotfixes, service packs, and clients
Capacity Planning
You should incorporate redundancy in a XenApp environment to ensure that end users can access applications and content without interruption. Ensure that critical XenApp infrastructure components, such as the Web Interface and Remote Desktop Service (RDS) licensing, are deployed with adequate redundancy in place. One XenApp server should be dedicated as a zone data collector. Since the zone data collector manages all dynamic data, such as load on the servers and end user information, applications should not be published to this server and end users should not be able to log on to it. Publish applications to at least two servers to ensure continuous availability. When planning for capacity, determine the minimum number of XenApp servers that can fully support users and then add servers to that figure to provide redundancy in the event of server failure. Common capacity estimation formulas include N+1 and N+20 percent, where N is the minimum number of servers required to support users. Further capacity might be needed in environments to facilitate downtime for maintenance or to accommodate large spikes in concurrent usage.
Example: Capacity Planning - If one XenApp server is able to support 100 end users and there are 500 end users, you should have six XenApp servers in place to support all of the end users, which follows the N+1 capacity estimation formula.
In an organization that has 20 XenApp servers but does not have available maintenance windows for the servers, an N+5 estimation formula might be necessary. In this scenario, five XenApp servers can be taken offline simultaneously, serviced, and brought back online while still providing application access to the end users
Clients and Plug-ins - Include the appropriate clients and plug-ins, which can include the Online, Offline, and the Single Sign-on plug-ins
Root certificates - Include the appropriate root certificates in the base image of all XenApp servers
Common applications - Include the common applications, such as Adobe Flash, Microsoft Silverlight, or Adobe Reader
Common configuration settings - Include the common criteria for XenApp server settings to keep the number of managed images to a minimum
Hotfixes and service packs - Include the latest OS and XenApp hotfixes and service packs in the XenApp server base image after proper testing
XenServer / VMware tools (if applicable) - Include XenServer tools to provide custom Windows drivers and a management agent for all XenServer virtual machines
Application Inclusion - You must decide if there is a need to include any installed applications as part of the base XenApp image. The decision to include applications is determined by factors unique to each organization.
Example: Application Inclusion Factors - Some organizations prefer to separate applications from the base image to align with the following organizational structure of the business:
Application Administrators - This group is responsible for profiling, packaging, and updating applications used by the XenApp server
Citrix Administrators - This group is responsible for creating and maintaining the base image with the latest hotfixes, service packs, and clients
| Benefits | Considerations | |
| Application Inclusion | - Installing applications on the base image allows for the fastest application delivery times - Applications are not streamed to the XenApp server, which reduces the impact to network bandwidth |
- Upgrades to installed applications could impact other dependent applications - In a provisioned environment, modifications made to applications within an image could impact all servers that rely on that image - In a non-provisioned environment, applications must be manually updated |
| Application Exclusion | - Fewer items installed on the base image allow for easier maintenance - Separation of the base image and applications allows for easier delegation of administration tasks - Farms can expand easily by adding servers that can deliver any packaged application |
- Application streaming increases network utilization - The maintenance need increased with the increase in number of application profiles and packages - Users experience latency when the streamed application launches for the first time Note: You can avoid this latency by configuring the pre-caching of streamed applications |
Capacity Planning
You should incorporate redundancy in a XenApp environment to ensure that end users can access applications and content without interruption. Ensure that critical XenApp infrastructure components, such as the Web Interface and Remote Desktop Service (RDS) licensing, are deployed with adequate redundancy in place. One XenApp server should be dedicated as a zone data collector. Since the zone data collector manages all dynamic data, such as load on the servers and end user information, applications should not be published to this server and end users should not be able to log on to it. Publish applications to at least two servers to ensure continuous availability. When planning for capacity, determine the minimum number of XenApp servers that can fully support users and then add servers to that figure to provide redundancy in the event of server failure. Common capacity estimation formulas include N+1 and N+20 percent, where N is the minimum number of servers required to support users. Further capacity might be needed in environments to facilitate downtime for maintenance or to accommodate large spikes in concurrent usage.
Example: Capacity Planning - If one XenApp server is able to support 100 end users and there are 500 end users, you should have six XenApp servers in place to support all of the end users, which follows the N+1 capacity estimation formula.
In an organization that has 20 XenApp servers but does not have available maintenance windows for the servers, an N+5 estimation formula might be necessary. In this scenario, five XenApp servers can be taken offline simultaneously, serviced, and brought back online while still providing application access to the end users
Load Balancing
Load evaluators maximize system efficiency by balancing online application sessions across the farm. The rules associated with a load evaluator determine the load level of a server at any given time. Servers that report a full load do not allow new connections until the calculated load falls under the high threshold. You should use and configure custom load evaluators whenever possible using applicable criteria to determine load on the XenApp servers. Avoid certain load evaluator rules, or use them carefully to prevent situations in which a user is unnecessarily prohibited from connecting to XenApp resources. Rules that result in fluctuating values can cause a server to report a full load. It is crucial for you to understand how the applications function in your environment to ensure that you configure a custom load evaluator with the correct rules. For example, if a load evaluator is created and configured to report a full load based on high memory utilization, applications that are CPU intensive can easily cause a server to report a full load.
Note: You can create a new load evaluator using Citrix AppCenter. The new load evaluator can then be applied directly to an application, or the servers running the application using Load Balancing policies and worker groups. If a load evaluator is applied to both, the load is calculated by measuring the load at the server level and then the application level; the greatest value is taken
Policy Configuration - You can manage a virtualized environment by applying Active Directory Group Policy Objects and Citrix policies. By design, most Citrix policies do not conflict with Active Directory policies. If there is a policy overlap, Citrix policies always take precedence over Windows policies and settings, except in the case of security as it relates to encryption and shadowing. Configuring policies as Active Directory Group Policies is recommended to provide consistency for the environment and end users. You can manage a newly built server by placing it in an Active Directory Organizational Unit (OU) and applying Group Policies to that OU. When troubleshooting, you can temporarily move a server out of an OU to remove the applied policies. You can then determine if any of the policies or settings applied to the OU caused any of the issues to the server.If the policies are not applied to the OU and instead are applied to the server, you can troubleshoot an issue by setting the policies to the Deny state. If a set of policies is applied to a server, you can attempt to locate the issue by denying each policy individually and properly testing the server. Applying Citrix policies with the user filter or to a server using the worker group filter is recommended for a XenApp farm environment. Citrix policies can also be applied to client IP addresses, client names, and users of the Citrix Access Gateway, but these filters can lead to static management of a dynamic environment.
Examples of policies that streamline the end user experience include:
- Client drive mappings
- HDX technologies
- Printers configurations
- Time zone settings
XenApp Optimizations
- Automatic Updates: You should disable automatic updates for applications and the operating system because all changes to XenApp servers should be tested and validated before implementing into production. In an environment with provisioned XenApp servers configured as standard image mode vDisks, any installed updates will be lost upon restart. If automatic updates are enabled, the update services will identify new updates and make requests to update every time a XenApp server restarts. A best practice is to review each operating system and application update as they release. If the update is approved, update the base vDisk image for the XenApp servers. After the provisioned XenApp servers restart, they will use a vDisk image containing the latest updates
- Event Logs: An event log is commonly used to identity and troubleshoot issues within an environment and can also act as a security audit log. Provisioned XenApp servers, which operate best when configured as a standard image mode vDisk, lose any changes made to the system upon restart; this includes changes in the event log. You can change the location of the event log files, but that location must be a local drive. If the event log files are stored on a network share, the event log fails to save messages.
Events can be collected in the following places:
• Local Storage
• Citrix EdgeSight
• Microsoft Event Collection Services (only available in Windows Server 2008)
Printing Optimizations: While configuring an online application in the AppCenter, you should enable the Start this application without waiting for client printers to be created option in the published application properties. Launching an application before the creation of printers can help reduce the load on the application, which results in a reduction of load on the XenApp server.
Note: This option should not be selected for applications that need to use the print function immediately after being started