If you would like to read the other parts in this article series please go to:
- Installing and Configuring Citrix XenApp 6. 5 (Part 1)
- Installing and Configuring Citrix XenApp 6. 5 (Part 2)
- Installing and Configuring Citrix XenApp 6. 5 (Part 3)
In the third part of this article series I described the configuration steps for Citrix XenApp 6.5 on the Administrators and Published Application options. Now we will continue with the other options.
Load Balancing Policies
This option is only available in the Enterprise or higher editions. This makes it possible to divide sessions over Worker Groups based on four filters; Access Control, Client IP Address, Client Name and Users. Based on one or a combination of these filters you can specify to which Worker Group(s) based on priority the user will be assigned to. Also this component can be used to specify the way the Citrix Application Virtualization will be delivered/started. I wrote a detail article about Load Balancing policies earlier, which can be found on my website VanBragt.Net Virtualization.
Figure 1: Load Balancing Policies
Load Evaluator
Although the names are pretty similar and Load Evaluators are often called Load Balancing by Citrix administrators/consultants, the Load Evaluator has another goal than the just described Load Balancing policy. The Load Evaluator determines the load per Citrix XenApp servers based on load evaluator rules. By default two Load Evaluators are available; Default (based on User load and Load Throttling) and Advanced (based on CPU utilization, memory utilization, Load Throttling and Page Swap). Both have some downsides, so often a new custom load evaluator is created.
My best practice is to use a combination of the rules User Load (where the value should be determined by performance tests), Memory Usage, CPU Utilization and Load Throttling. Because CPU Utilization and Memory Usage have a dynamic character I only want that those rules to come into play when the usage is pretty high. So for the no load setting, I use a pretty high value like 70 or 80 percent, causing that User Load as the rule that is used in normal situations. I will explain this a bit more, because there is alot of confusion amongst admins about the way the load is calculated. Out of the rules, the most high value will be used combined with the averages of the other rules (which are multiplied by 0,1). So in my best practices the User Load will have the highest value by default or CPU or Memory should have a high value.
Figure 2: Custom Load Evaluator
Policies
From XenApp 6.5 the policies have changed a lot. The first big change is the way that you configure the policies. In previous versions this could only be done within the Citrix Management Consoles, but nowadays you also configure the policies within Active Directory. Logically you should make a decision to use one of the possibilities, because it cannot me combined. Advantages for Active Directory are that settings can be shared over multiple Citrix farms and the AD method is always used to deploy the policies (also if you configure them in the Citrix console). Advantages for using the Citrix console is independency of AD (if you do not administrator AD for example) and it’s clear that the policies are for which XenApp farm (if multiples are configured).
Policies can be applied on two levels, on machine or user level (same as Active Directory GPO’s works). Multiple policies can be configured, which can be assigned via Filters and Priorities. Using the priorities part settings can be overruled by a higher priority. Filtering on machine level can be based on AD Organizational Unit and/or Worker Groups. It’s good to know that several configure options are nowadays embedded in the policies part were in earlier versions those were available as separate options in the console. Some examples are the Load Evaluator assignment on server level, reboot configuration, licensing, Health Monitoring and Recovery, CPU/Memory optimization and so on.
The second level is on user level. Logically on the User Level the same concept is used for prioritization and filtering. However more filters are available:
- Access Control
With this option the policy can be applied or denied based on defined Access Control conditions, which can be defined in the Access Controller of the Access Gateway.
- Branch Repeater
Using this filter setting will be applied based on the way the client connects, via a branch repeater or without a branch repeater.
- Client IP address
Based on (part of) the client IP addresses the policy will be applied or denied. Wildcards can be used for defining sets of clients to apply or deny the policy. Some use cases are settings defined for WAN connections, External Access (if Access Control is not in place), specific department/location settings and so on.
- Client Name
Using (part of) the client name to apply or deny the policy. Again wildcards can be used to define a group of client. Can be used for different settings per client type (laptops, desktop and thin clients), specific department configuration or similar use cases.
- Organizational Unit
Just as the default user policies for Active Directory are functioning, the policy is applied or denied based on the location of the user within the AD Organization Unit schema.
- User or Group
Filtering of the policy is based on users or groups. This can be both local or Active Directory users or groups, where it makes sense to use Active Directory Groups for this kind of filtering.
- Worker Group
In this way the user policy will be applied based on the server the session is started. So if the server is member of the configured Worker Group the policy will be applied or denied.
Figure 3: Citrix User policies Filters
I’m not going to discuss all policy settings one by one this time. If there is interest we can make a separate article series for it.
Worker Groups
Also introduced in XenApp 6.0 are the Worker Groups. A Worker Group is actual just a group of servers. A server can be a member of one, none or multiple Worker Groups. Worker Groups are often used for combining similar servers used to assign the same configuration. For example you can assign a Published Application to a Worker Group. If a server is added the Published Application is automatically available on that server (or the other way around). Also applying Citrix Policies using Worker Groups is a nice opportunity, especially because a server can be assigned to more Worker Groups. I use this concept to add the server out of production using a Load Evaluator (now only configurable using the Machine Policy part) and Worker Groups (see this article for more info). Also using the Load Balancing Policies defined Worker Groups are required.
Zones
Nowadays Zones are only used for organizing the communication traffic between Citrix XenApp servers (and specifying the Data Collector preference per zone). By default all Citrix XenApp servers are communicating with each other in a zone. When a Citrix Farm is divided over multiple locations (with limited bandwidth) it can be important to limit the traffic between those locations. By creating a zone for each location, traffic between the zones is limited where only one server of each zone communicates. The other servers only communicate directly with the servers within the same zone.
The Election Preference can be configured per zone. This determines which server will hold the Data Collector role. Each zone will have one server that will hold that role. If that server is unavailable an election will be performed and based on the election preference of the server a new server will be selected to host the role.
Figure 4: Set Election Preference
ICA Listener Configuration
As stated earlier there are still a few settings outside the management console for specific configuration. The ICA Listener is the most important, because this is the only place where you can configure the session limits for end disconnected session and active session limit. In Citrix policies are the same settings available but those only apply to XenDesktop. I don´t recommend to change other settings within this ICA Listener Config.
Figure 5: ICA Listener Configuration
SpeedScreen Latency Reduction Manager
Not used a lot anymore, but with this utility you can change specific settings like enable local text echo and mouse click feedback and the latency threshold settings. Only change this for specific needs.
Citrix SSL Relay Configuration
Communicating between the XenApp Farm and the access technologies like Web Interface, Secure Gateway, Access Gateway or Cloud Gateway, by default, plain XML/HTTP traffic is used. This can be secured using SSL traffic. With the Citrix SSL Relay Configuration you can configure the SSL settings for the XenApp servers for securing the communication between the configured servers and the access technologies.
Conclusion
In this last part I continued describing and discussing the configuration possibilities of XenApp. With this article series I showed and described the basic installation and configuration of a XenApp environment based on XenApp 6.5.
If you would like to read the other parts in this article series please go to:
