Best Practices for Citrix Policy design for Presentation Server 3 or 4

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.

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:

  1. 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.
  2. 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.
  3. 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:

  1. Don’t be afraid to have as many policies as you want.
  2. Only apply one type of filtering to each policy.
  3. Only make the specific settings in a policy that you must control at that level.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you have any data about how policies scale and how they affect the login process? For example, I have a possible scenario where I need to assign session printers to each client IP address (subnet or group will not work for me), and this will mean several hundred, maybe even over a thousand policies. It would be a great alternative to scripting this or using AD, but there is no data to backup this kind of usage scenario.

Is this workable, cant find any data anywhere which discusses this level of use.
I think you just elected yourself official tester of the scalability of citrix policies.
This is a great writeup. Can anyone say something about how to know when/if policies will override any settings made in the per-server ICA connections configuration???

For example, we set the Citrix Admins to have multiple logons in the top-most policy but this doesn't work...

We set in an All Users policy to not allow A: drive and CD drive, but this doesn't work either...

Some further information about how the ICA connection settings and policy settings interact with each other, if at all, would be nice...

Thank you!! This is a great website!!
Like everything in computing, the most restrictive setting applies. However, you have to be careful with the wording of stuff to figure out which is the most restrictive. For example, "disabling" a certain feature is very different than not "enabling" it.

So, for example. if your connection does not allow client drive mapping, then that means that the connection doesn't allow it. Period. It doesn't matter what your policies are set towards because the connection won't physically support it. That's why the phrasing of most of the policies is to "disable" certain settings. So you can use a policy to explicitly disable a certain setting, but you cannot "enable" a setting per se. All you can do is not disable it--but the setting may be disabled somewhere else along the line.
If yo design you farm right, you won't need that many policies to begin with.. Besides, there are only a limited number of policies to work with (mfps 3.0) PS 4.0 doesn't added anything other that integrate with MSAM (which no one uses or want to pay for anyways).

Also, why are you knocking Citrix's PS Console as a MMC wanna be? It is much nicer and easier than Citrix's MMC. The Access Suite Console is $#!+.
I think you may want to check those PS4 policies again. There are a few more than just MSAM policies.
Brian, thanks for spotlighting Citrix policies. It's where things are going... (Session printers, anyone?) But I don't think that more is necessarily better. I don't think that you should have few policies because something might break, I think that fewer is better for simplicity's sake. Actually, fewer/more is a red herring. How about the correct number for your environment? Not a gratuitous amount, not too few, but just the amount that you need?
Never played much with citrix policies before. Maybe time to give it more attention. I use the windows 2003 server policies much more
PS4 has taken the use of policies to control your farm to a whole new level. Not just MSAM. As Brian said "In PS4, you can control just about every conceivable Citrix option via policies"
We have about 250 Citrix policies and logon time is as quick as before...
Oh, really? Theres are may 5-6 new settings that are not included in MFPS 3.0... For filtering, the only thing that's added over MFPS 3.0 is MSAM.
Not true... Can you control PN Desktop/Start Menu settings based on which Published desktop you launch? Or from which client you connect from. Can you filter apps (NON MSAM) users can see depending if they are external or internal?

Can you control Session, idle and disconnect timeouts via CTX Policies? Nope. You'd think this would have be a given by now.


Not true... Can you control PN Desktop/Start Menu settings based on which Published desktop you launch?

No, you can do that through group policy if need be.

Or from which client you connect from. Can you filter apps (NON MSAM) users can see depending if they are external or internal?

Definately needed. Couldn't agree more

Can you control Session, idle and disconnect timeouts via CTX Policies? Nope. You'd think this would have be a given by now.

Again, GPO's.
Thanks SNA, sounds my intended use of several hundred 'session printer' policies may not be a complete waste of time.
It would be wonderful to have an essay here on using group policies for some of the things mentioned above by the experts:

1. controlling desktops etc. for published apps
2. session, idle, disconnect timeouts
3. etc. etc. etc.

Thank you!!

P.S. Maybe change the spam number once in a while??
I'm not sure why you'd go to the trouble of creating a thousand policies rather than script it. You could do a simple MFCOM script that reads the client IP, references the IP in a text file, and maps an associated printer.
Yeah, I agree that would be a great writeup.

Re: changing the spam number... Why should I change it? The spammers robots haven't figured it out yet, so we're good.. As soon as I start seeing comment spam again, I'll change it.

I have a user who will not be disconnected from citrix no matter how long he has been idle. I do not have this issue with anyone else. Does anyone have any idea as to how I might be able to correct this. Your help is appreciated.
I figured this out, maybe someone can help me with another issue. I am running presentation server 4.0 and when someone hits it from the web it doesnt automatically install the client. Any ideas?
Great write up, thanks.  I was wondering if there is a way to find out what policies were applied to any given client.  (Something akin to 'gpresult.exe' for Group Policy).  I have created a policy for drive mappings (Turn off Remote drive=no) which is not working.  It has been assigned to the users, which didn't work, at which point we applied it to the server.  Still, the client does not seem to get the policy.  I want to establish if the policy is being processed by the client.

thanks for any assistance.
Session reliability?    
Is there a way to track who creates a Citrix policy.  I would like to be able to audit this behavior. 

I have one group which will logon to two different silo servers. I would like to build a policy which will enable that group to have clip board copy & past feature between two siloed servers. Can you please advise me.



is there a report available that show the settings for an enabled policy such as properties and filters?

You could use Microsoft's Group Policy Management Console (GPMC) with Service Pack 1 (SP1) which can be downloaded from Microsoft free of charge. It allows you to view Policies and create reports showing exactly what settings are enabled. It even allows you to do GP modeling and you can use the GP results wizard to view the Group Policy Results (the cummulative effect of all the GPs) for any user on any PC or Server on your network. I use it all the time for testing before I apply a new policy, documenting each policy and troubleshooting policy issues as well.
WTF are you talking about this article is citrix policies not GP's