In my previous two posts, I’ve described how XenApp for 2008 R2 configuration can be defined as XenApp Template-based Management, and how it can be defined as Group Policy integration in XenApp for 2008 R2. Today I will cover some common questions I get when explaining this new configuration model. Please feel free to add yours in the comments sessions below, if I didn’t cover here.

Why XenApp has two ways to configure settings?

The Group Policy and the IMA policy system are in fact the same – settings coming from either will merge in a single, predictable Resulting Setting of Policies.

One way to think about it is that IMA has an additional GPO associated with the farm itself, and stored in the IMA data store. This GPO is what you edit when you change Policies in Delivery Services Console.

In case of setting conflicts, which policy document will take precedence?

Group Policy takes precedence over IMA; and IMA takes precedence over Local Group Policies. If you configure a GPO setting “SecureICA minimum encryption level” to RC5 128 bits, then you cannot override this configuration at the farm GPO or LGPO level.

How can I track from where settings are coming from?

The best way to track applied settings of a computer or session is to run a Resulting Set of Policies Logging report from GPMC. This report will show all Citrix settings configured via policy, and which Group Policy object – including the IMA GPO and filters – has actually won the merging calculation.

The policy report doesn’t show the value I’m looking for!

RSoP doesn’t display settings that policies have not configured. If you are looking for a specific setting, and it doesn’t show on reports, then the value being enforced is “default”. You can read the setting description in the policy editor to find what the default value for each setting is.

How does it work exactly?

When you edit a Group Policy object using GP Editor, we store your configuration in a file called \\<domain>\SYSVOL\<domain>\Policies\<guid>\<Machine or User>\Citrix\GroupPolicy\Policies.GPF. When you edit Policies in the Delivery Services Console, we store this same GPF structure in the IMA data store.

Every time Group Policies are evaluated on a XenApp server – server reboot; user logon; and randomized refresh intervals – we will retrieve these GPF files from SYSVOL and the datastore. Our Client-side Extension then evaluates filters and merges the results into a single RSoP, in the system registry (HKLM\Software\Policies\Citrix). Various software components then read the registry values and enforce the settings.

This diagram shows the conceptual model behind XenApp for 2008 R2 policy system.

What is the “Unfiltered” policy, how filtering works?

You will always find a Policy named “Unfiltered” when you edit any GPO. There’s nothing special to it – it’s just a default policy rule that applies to all machines and users in scope of that policy.

What is the “scope of the policy”? Group Policy Objects are linked to one or more Organizational Units in GPMC. GPOs may also have WMI filters. Only servers and users that are under OUs linked by that policy, and that match the optional WMI filters will process the policy. Other computers and users will ignore it. This is standard GPO processing.

The IMA Policy scope is the farm itself – i.e., settings added to the “Unfiltered” IMA policy will apply to all servers and users in that farm.

We’ve added an additional filtering system, allowing you to create additional settings and rules within each GPO. When you select “New…” in our policy editor, you will enter a set of configuration, and rules to apply that configuration. For example, you may set Bandwidth limits for end-point devices of a certain IP range; or restrict clipboard access for users of a specific AD security group.

We’ve created this extra filtering system for two reasons: first, we have additional filters related to the endpoint itself – AAC, endpoint IP, endpoint name – that are not available in WMI; second, some of our customers have very large number of policies (over 1000), and Group Policies wouldn’t scale to those levels.

If you have a very large number of rules based on endpoint IP or name, then you should use the Citrix filtering rules – for example, setting a different Default Printer per endpoint name. Other than that, either way works fine. As a rule of thumb, you should minimize the overall number of Group Policy Objects, as a large number of GPOs may impact logon times.

Should I use Group Policies or configure settings in the DSC?

You should use Group Policies if you can. If you have some control over the server OU structure, and has the necessary delegation to Group Policies, GPO integration will give you the best user experience. You can leverage GPMC and AGPM functionality, and perform server management actions exclusively in Active Directory consoles.

However, if you have no delegated access to AD, then you can still fully manage your farm through the IMA policy.