It’s been over 2 years since my initial post on XenApp/Group Policy integration… how time flies! This feature is finally seeing the light of day with XenApp for 2008 R2 (in Tech Preview right now). I’m really happy with the results, let me describe how it will enhance management of XenApp farms.

As I described in my previous post, our primary goal for XenApp management was to enable template-based management of XenApp servers. We realized that most environments used Group Policies and Active Directory OUs as a way to define these server templates. Most XenApp environments need GPOs in some capacity to configure RDS, profiles, lock-down servers, configure sessions and the operating system.

GPO integration therefore reduces the number of consoles used for common management task. This sounds counter-intuitive at first: the Group Policy Management Console (GPMC) is an extra console… But the reality is that tasks can be fully performed on the Active Directory consoles: Creating a new app silo or farm? Create a new OU, drop servers there, and assign a new Group Policy Object to that OU. Adding servers to the farm? Just drop to the right OU. Maintaining dev, test, and production farms? Just link the high-level policies to the right OUs, and override any farm-specific setting using child OUs.

Additionally, GPO integration means all GPO management features now apply to XenApp settings as well. GPMC supports backup/restore; migration; and resulting set of policies (planning and modeling). AGPM supports off-line editing; configuration logging; change control; role-based delegation; and more.

Finally, GPO integration allows separation of management roles within IT. XenApp administrators can delegate server provisioning more easily, knowing that the only required step is the correct OU assignment for the server – something non-XA admins can understand and perform without specific XA delegation.

How will it work?

When you install the XenApp for 2008 R2 Management Console, it will include extensions to GPMC and GP Editor. GP Editor will display new Citrix policy nodes under the existing Computer and User nodes. These apply to all servers and/or users under the scope of that GPO (generally the list of OUs the GPO is linked to). The GP Editor extension is also installed at all XenApp servers, so the Local GPO editor (gpedit.msc) will also display XA settings that apply to that computer alone.

This picture shows GPEdit after XenApp management consoles are installed:

In this example, I’ve selected “User Configuration”, “Policies”, and then “Citrix Policies”. The UI is the same as the policy editor found in the native XenApp MMC console. The difference is that these policies are associated with the Group Policy itself, rather than any one farm! In other words, this policy will apply to all computers and users under the scope of this policy, even if the computers are in multiple XenApp farms.

Note that we didn’t use standard ADMX files to represent our policies. ADMC couldn’t handle our filtering requirements. Our policies support session filtering based on the client-side parameters – AAC tags; client IP range; client name; etc – as well as computer filtering based on IMA Worker Groups membership.

You can set any number of policies under “Computer Configuration” and “User Configuration” for a single GPO. Each policy has its own filter – in the example above I’ve set policies for any user connecting from IP addresses different than 10.15.* – representing remote users.

All the Group Policies rules and features apply to the Citrix extension: loopback, enforced policies, ACL and WMI filtering. For example, the following Modeling Report shows Windows and XenApp policies side-by-side:

I’ve launched this simulation from the “Citrix Group Policy Modeling” wizard, added to GPMC after you install the XenApp extension. That wizard replicates all steps of the “Group Policy Modeling”, with one extra page where you can enter client IP, name, and AAC filters you want to simulate with.

Note that you can see which Group Policy setting “won” for every single setting. You can also see which XenApp filters “matched” the simulation, and the resulting policy group within the GPO.

We know, however, that some XenApp admins cannot effectively use Group Policy – they either lack delegated control to the XenApp OU; or they are not using Active Directory. In this case, you can fully manage your farm using the Policy node in the XenApp Delivery Services console. I’ve shown how that is done at this blog post here.

Does this mean we have two policy systems, one in IMA, and another with Group Policies?

Not at all! I will describe how the IMA Policies and Citrix Group Policies extension work together in my next post.