Citrix introduced their policies back in Feature Release 2 for MetaFrame XP. In a nutshell, Citrix policies allow you to control various Citrix options on a connection-by-connection basis.
Each new version of Citrix MetaFrame has provided more powerful policies—both in terms of what settings you could control with the policies and the flexibility of how you could decide which policies should be applied to which connections.
MetaFrame XP’s policies were somewhat limited because you could only control a few settings and they could only be applied to based on username or a user’s group membership. Contrast this to the policies in Presentation Server 4. In PS4, you can control just about every conceivable Citrix option via policies, and you can apply them to incoming connections based on username, group, client IP address, client name, server name or silo, or Smart Access zone.
Policies are one of the most powerful management features of Citrix, and knowing how to create and apply them is critical if you want to be a Citrix badass.
Policy Basics (Skip this section if you’ve worked with policies before)
Each policy you create exists as a separate object in the IMA data store. Once a policy is created you edit its properties which control what Citrix settings it applies. (Virtual channels that are enabled or disabled, screen settings, bandwidth limits, printer assignments, etc.) There is no limit to the number of policy objects you can create in your farm. However, simply creating policy objects doesn’t actually do anything. You have to apply (or “filter” them in Citrix’s lingo) to various connections based on the things mentioned above like server name or ICA client IP subnet.
The only real challenge with Citrix policies is that they only exist at one level: The farm. There is no way to break them up into subfolders or anything. So if you want to create 40 policies for different things, you’ll end up with one single huge list of 40 policies. (Ugh!) This means that if you’re not very intentional about the policies you create, where they’re applied, and how they’re named, you can run into a lot of trouble.
The other problem this creates is that a lot of people are afraid to create too many policies. This is a problem because Citrix policies are so powerful that you should create as many as you need to do the job right. This means that you may have 20, 30, 50, or even 100(!) Citrix policies in your farm.
Yeah, that’s right. You may have 100 or more Citrix policies in your farm.
Before we look at how you should create policies, I want to shoot down a myth about the number of policies you can create in a farm. I’m not sure if this is from some deeply-buried KB article or some news group myth or what, but there’s some kind of industry-wide fear of creating too many policy objects. Most people balk at the idea of 100 policies in a Citrix farm. “That’s too many!” they say, or, “That will make logons too slow.”
“Nonsense!” is my response. I think you need to make as many policies as you need to get the job done, and if that means that you end up with 100 policy objects in one farm, then so be it.
For those who don’t believe me, it’s really easy to prove exactly how much “slower” (if at all) having a huge number of policies will make the logons. To prove this, let’s think about what happens when users logon and policies are applied.
Since the policy objects live in the data store, each Presentation Server maintains a copy of all the policies and their settings in its own local host cache. When a user logs on, the policy processing engine in Presentation Server needs to go through three steps:
- It must sort through all the policies and figure out which ones apply to this particular logon. This means looking at policies that apply to the user name, user’s group memberships, client name, server name, client IP address, and (if using PS4) the Smart Access zone.
- Once it has a list of all the policies that apply to this logon, the server must scan through all the settings of each policy to come up with the master list of settings that will apply to that session. This process must take into consideration priority settings and figure out which settings are ignored and set by which policies.
- Once all the policy settings have been sorted out for that session, the server must actually apply those settings to that session.
At first glance, it seems that Steps 1 and 2 could take a really long time if there were dozens or even hundreds of policies in the data store. While it’s true that it seems like this would be a slow process, remember that computers are really fast these days, and this process is probably a lot faster than you think.
To test this in your own environment, open up the “Search” box in the Presentation Server Console (that crazy Java-based MMC-wannabe excuse for a management tool you use to configure your Citrix servers). You can do this by right-clicking on the Policy folder in the left-hand pane and choosing “Search” from the context menu. This opens up a box that lets you search through your policies to see which ones are applied in different session scenarios. (Sound familiar? It should, because that’s basically the exact same thing as Step 1 from above.)
So if you want to see how fast your Presentation Server can sort through your dozens of policies to see which ones apply in a given logon scenario, simply fill in the five (or four if you’re using PS3) “Search Criteria” options for a sample logon and click the “Search” button.
Chances are the Search Results box will be populated faster than you can read this sentence. And if the Java-based management console can filter the full policy list that fast, I promise you that the Citrix logon process can filter the list just as fast.
So that brings us to Step 2. Now that you have a list of all the policies that apply to a given logon scenario, how quickly can the server figure out which settings from which policies should apply? Fortunately you can test this with the same search tool as in the previous step. Just click the “View Resultant Policy” button at the bottom of the screen after you’ve searched for some policies, and a new box will pop up with the filtered policy settings that would apply to the logon you based your search on.
Guess what? That box pops up pretty fast, even if several policies are being filtered. Again, this means that if this box can show you your resultant set so quickly, you know darn right that the Citrix logon process can figure these out just as fast.
The final step in the policy application process is to apply the policy settings themselves. Fortunately it doesn’t matter how those settings were derived—from a single policy object or filtered from dozens—the actual application process takes a fixed amount of time.
So, what was the point of all that? We just spent 500 words justifying the fact that you can make as many policy objects as you want. The real trick is knowing how to make and apply these policies. So…
How to Make and Apply Citrix Policies
From a management perspective, it’s easiest to make one policy object for each different thing that you’ll apply policies to. For example, if you have three different domain groups of users that will have three different settings, you should create three different policies—one for each. Then when you apply filtering for each of those policies, apply each policy to one group.
Furthermore, if you want to have two policies for client IP subnets, (maybe one for internal and one for external users), then create two policies—one for each subnet.
The same goes for servers. If you want to apply different settings for different silos, then make one policy object for each silo and apply it to each silo. (As a quick side note here, remember that you can apply server name policy filtering at the folder level, so if you have server silos then put your different groups of servers into subfolders and apply/filter your policies based on the folder name, rather than each individual server.)
If you decide to apply policies based on the client name, keep in mind that smart or crafty users can change their client name to whatever they want, so you shouldn’t make security-type settings based on client name.
As I alluded to earlier, the only downside to creating all these policies is that since the policy object listing in the IMA data store is flat, you’ll end up with one huge list of policies for your whole farm. Therefore you need to be very intentional about your naming scheme. I prefer policy names that specify how a policy is filtered. Good policy names are things like:
- Client IP – outside
- Client IP – inside
- Server – Enterprise Silo
- Server – Accounting Silo
- Server – Office Silo
- User – Citrix Users Group
- User – Administrators Group
A naming scheme like this makes it very easy to see what’s what, even with a hundred policy objects.
Of course this whole scheme only works if you only apply/filter each policy object to one target AND if you only make the settings within each policy object that you want applied with that policy.
What about Priorities?
Of course once you start making all these policies, you need to rank/prioritize/stack them up. Citrix policies are applied based on priority. In the event of conflicting settings in multiple policies, the setting in the policy with the highest priority (“highest” meaning the closest to the Number 1) wins. So what should you do in the real world?
First of all, I like to start out with a farm-wide baseline, or default policy. I usually call this policy something like “farm wide default” and make all the settings in it that I want to be the default for my farm. Then I apply/filter it based on servers and check the box for the highest level “servers” folder. (This has the effect of applying this policy to all the servers in your farm.) If you put this policy at the bottom of your list then it will apply your baseline settings. If other higher-ranked policies override them, then great, but if not, it gives you good baseline settings for all the servers in your farm.
Once you have the baseline policy set, go ahead and build up your policies on top of that. You’ll have to make the decision at your company as to how you rank the different policies in your farm. (What has priority? A user’s client IP address or the server they’re connecting to? This will depend on your environment.)
I’ve shown a snippet from the Presentation Server Console of what this might look like. (Hey! How did the Citrix administrator’s policy get the highest priority?)
Okay, that’s pretty much all you need to know for a crash course on how to use Citrix policies. The key takeaways are:
- Don’t be afraid to have as many policies as you want.
- Only apply one type of filtering to each policy.
- Only make the specific settings in a policy that you must control at that level.