Bandwidth Management: Part 2 – Leveraging Citrix Policy to Optimize Bandwidth Usage

If you would like to be notified when Andy Jones releases Bandwidth Management: Part 3, please sign up to our Real-time article update newsletter.

If you missed the first part of this article please read Bandwidth Management: Part 1 – The Old Fashioned Way.


In the previous installment of this series, we looked at controlling presentation layer protocols, particularly ICA, with various methods. These methods included ICA Priority Packet Tagging (old school) and adjusting the various THINWIRE properties of a given server. In this article we will look specifically at using Citrix Policy, a component of Presentation Server, to greatly enhance and finely tune the bandwidth used by various VIRTUAL CHANNELS inside of an ICA Packet.


Before we dig into the meat of the topic, we will start with a basic review of Citrix Policy. Citrix Policy began its life with MetaFrame Presentation Server 1.0 (aka MetaFrame XP). Since its inception a few years ago, Citrix has extended its capabilities throughout the Feature Releases of Presentation Server 1.0, making huge enhancements to the rules with Presentation Server 3.0 that have brought us to the current state of affairs with the policy available in Presentation Server 4.0.


First, some ground rules…

Citrix Policy is available in ALL versions of Presentation Server 4.0 (Enterprise, Advanced and Standard). Keep in mind that Advanced and Enterprise editions will have increasing functionality when it comes to policy as not ALL elements that are configurable with policy are features that are ENABLED in the lesser editions of the platform.

Citrix Policy works in conjunction with Active Directory Group Policy Objects, not necessarily in competition with GPOs. There are some settings that “overlap” between AD GPOs and Citrix Policy, but by-and-large, Citrix Policy stands on its own as a mechanism for controlling sessions.

Citrix Policy functions in many ways similar to AD GPOs, for instance it is possible to have MULTIPLE Citrix Policies assigned that could potentially conflict. Just as AD GPOs have a mechanism to handle this, Resultant Set of Policies, so does Citrix. In Citrix Policy, we can assign a PRIORITY number that allows the Presentation Server to EASILY determine the “importance” of the policy. In short, the LOWER the PRIORITY number (closer to one) the MORE important the policy is and will override conflicting settings. For instance, if our farm has two policies, that both apply to a group my user account is a member of and that have conflicting values for whether to enable or disable DRIVE REDIRECTION, the policy with the LOWER NUMBER will win the “rule conflict” and take precedence. In Figure 1 below, ICA Turner has a Citrix Policy defined SPECIFICALLY for his account and is also a member of DOMAIN USERS (that has a policy with conflicting values assigned). In this case, all DOMAIN USERS will have ONLY their default printer mapped, but due to the PRIORITY, ICA Turner will have all his printers mapped. Citrix Policy Priority is going to be a VERY useful feature that we will leverage later to “optimize” bandwidth based on the user’s location (for instance).

Figure 1: Importance of Priority for Conflicting Policy Rules


Now that the ground rules have been established and the importance of PRIORITY explained, let us turn our attention to the various RULES of Citrix Policy that can be leveraged specifically to optimize bandwidth usage. For the purposes of this article, we are reviewing the settings that are available in Presentation Server 4.0. The rules, their functions and the targets for the rules to be applied against will vary based on the version (XP, 3.0, etc) and the feature set (Advanced, Enterprise or Standard) of your environment.

Each Citrix Policy has five basic “sections” that contain various rules in Presentation Server 4.0:

  1. Bandwidth
  2. Client Devices
  3. Printing
  4. User Workspace
  5. Security

Again, for the purposes of this article we are going to focus on just the Bandwidth rules for Citrix Policy (although other policy rules found under Client Devices and Printing are also helpful in optimizing and controlling bandwidth). Additionally, a Citrix Policy can be applied or “filtered” to apply to a limiting set of objects on your network. A given policy can have MULTIPLE rules and MULTIPLE Filters applied to allow for simplified and streamlined policy application. Policies can be applied or “filtered” to the following:

  1. Access Control – Connecting through MSAM or Advanced Access Controls based “portal”
  2. IP Address – A single IP Address or range of IP Address, one my favorites
  3. Client Name – as reported by the Citrix client at the time of connection
  4. Users (or groups) – also a favorite
  5. Server(s) – allowing you to assign “different” rules for silo-ed or servers that are members of Load-Managed Groups

Enumerating every Citrix Policy rule is not the end-goal of this article. Please refer Citrix Documentation for the use and function of each individual rule.

Now, let us setup a scenario and work through how to leverage Citrix Policy to accomplish the goals. We will assume a fairly standard environment, one in which I have “internal” users on a SMALL LAN segment all connected via 100Mbps connections (so they have fast access to the Citrix Presentation Servers). Additionally, we will have a portion of users that work from remote locations and home, plus we can assume that some of the LAN users will work from remote locations occasionally. Our desired end-state would be to optimize bandwidth for both types of connections. A basic plan of implementation would look like the following:

Step 1 – Establish TWO empty policies, one for LAN Connections and one for WAN/Remote connections.
Step 2 – Configure the RULES of the two policies to optimize the bandwidth (keeping in mind the “target” of each policy).
Step 3 – Filter the individual policies and assign PRIORITY.

STEP 1 – Creating TWO empty policies. As illustrated below in Figure 2, simple right-click the POLICY node in the Presentation Server Console and CREATE two “empty” policies with names and descriptions to your liking. I am a big fan of using the description field to tell me EXACTLY what the policy’s intentions are and “who” it applies to (the filter).

Figure 2: Creation of TWO Policies to Allow for “Conflicting” Policy Rules

STEP 2 – Configuring the RULES. At this point, we can simply edit the policies to configure the various rules to our satisfaction. For simplicity’s sake, we will focus on a SINGLE RULE, IMAGE ACCELERATION and have the LAN settings “conflict” with the WAN settings. As you can see below in Figures 3 and 4, I have configured the LAN Policy for the rule IMAGE ACCELERATION to provide the BEST quality image at the expense of some bandwidth (which should be okay on the LAN). For the WAN Policy, I have configured the rule to be the reverse, to CONSERVE bandwidth at the expense of a degraded image quality.

Figure 3: LAN Policy IMAGE ACCELERATION – Best Image, More Bandwidth

Figure 4: WAN Policy IMAGE ACCELERATION – Lesser Quality Image, Lowered Bandwidth

STEP 3 – Filtering the Policy and assigning PRIORITY. The last steps are to determine WHEN the policy in question will go into effect. This is down by assigning one or more “filters”. For the LAN Policy, I have decided to “FILTER” it to apply ONLY to connections coming from the network (the internal LAN IP scheme in our fictitious office).

Figure 5: LAN Policy Filtering to a SINGLE SUBNET

Now we can filter the WAN Connection Policy. The configuration is “slightly” more challenging due to the fact that the end result is we don’t “know” where a WAN/Remote connection will be coming from but we do know where it will NOT, our network. In this case, as shown in Figure 6, we are going to use the DENY feature to exclude our internal network as a possible target of the WAN Connection Policy.

Figure 6: WAN Policy Filtering to EXCLUDE a Single Subnet

At this point, we have two policies that will accomplish the end goals of our design. The last thing to do is to simply assign the correct PRIORITY to allow for faster processing and to “guarantee” the results in the event of policy conflicts. Assigning PRIORITY is a simple task of selecting the policy that’s PRIORITY you wish to change and right-clicking and choosing PRIORITY and simply moving it up or down as you see fit. Remember, the LOWER the PRIORITY number the higher the precedent.

Try to limit the number and complexity of your Citrix Policies to lighten the load on the servers and shorten the login process for users. Extensive use of Citrix Policy, like AD GPOs, can have detrimental impact on user experience and session performance!


We have taken our second look at bandwidth management and explored how Citrix Policy can be leveraged to extend and control, nay optimize the bandwidth consumed for connections. This article, combined with practices from the first in the series lays a very solid foundation for controlling bandwidth as pertaining specifically to ICA sessions. In the final installment of the series, we will investigate methods for “protecting” the fragile presentation layer protocols with third party tools. All of our optimizations to this point are for naught, if the bigger and hungrier protocols (such as SMTP, FTP, HTTP, etc) are competing on our network links against ICA/RDP for bandwidth. We will look at how to guarantee some Quality of Service and provide consistent bandwidth for ICA and RDP.

For more information of Citrix Policy, please refer to the MetaFrame Presentation Server 4.0 Administrator’s Guide at

If you would like to be notified when Andy Jones releases Bandwidth Management: Part 3, please sign up to our Real-time article update newsletter.

If you missed the first part of this article please read Bandwidth Management: Part 1 – The Old Fashioned Way.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top