Administration has changed quite a bit in XenApp 6. Not only have a few Citrix-related policies have been added or modified, but there are new options for administration. Citrix policies are now based on user or computer policies, and they can be administered as Active Directory GPOs. That combined with Worker Groups based on OUs may initially seem complex but really can mean much more efficient administration of your XenApp servers via Active Directory—if you understand your options.
First, let’s take a look at the options that are available for administration of Citrix computer policies based on the Citrix recommended preference order:
Worker Groups can be based on OUs, Server Group Accounts, or Farm Servers. Essentially, it is a grouping of servers that will take on the same characteristics, and each server can belong to one or more worker groups. If OUs are used as the basis for Worker Groups, servers that are added or deleted from OUs automatically take on the characteristics of a specific Worker Group. Please see CTX124481 for more information about Worker Groups.
Where possible, Citrix recommends administering XenApp 6 via Active Directory using the Group Policy Management Console; it is installed by default with XenApp 6 for this purpose. However, the administrator must have administrative rights to the OUs that house the Citrix servers. Please see XenApp 6 Policies and Group Policy Integration for more information about XenApp 6 policies.
To take it one step further, when Citrix Provisioning services is used to create new XenApp servers, these can automatically be assigned to an OU. If published applications and Citrix policies are configured based on Worker Groups and Worker Groups are based on OUs, administration is greatly simplified. Let’s walk through that flow:
• New server gets provisioned via Citrix Provisioning services; it is automatically assigned to an OU
• The server automatically inherits characteristics based on the Worker Group designation, including published applications and Citrix policies
Thus, the only process initiated was the provisioning of the new XenApp server. If the applications are embedded in the XenApp image or automatically streamed, the server is now functional.
Additionally, an administrator should:
• Apply the correct load evaluator (newly installed server defaults to the default load evaluator)
• Move the server to a different zone if required
That’s it!
Citrix does not recommend mixing administration methods. A mix-and-match approach can cause undesired results because the policies are applied from different sources and may overwrite in ways not intentioned. It’s kind of like three business partners having access to a bank account and no one looks at the balance before making a withdrawal—the results may not be good.
As an example, if you import policies via the XenApp 6 Migration Tool, those policies are written into the IMA Data Store. If you plan to administer your new XenApp 6 farm by means of Active Directory, you’d have policies in two repositories, i.e., AD GPO and IMA Data Store. Keeping in mind that Citrix policies are applied based on hierarchy – i.e., the precedence order is child OU; parent OU; subsequent parent OU; Domain; Site; IMA; Local – having policies in more than one place may produce results other than what you had intentioned. If you want to streamline the imported Migration Tool policies into an AD GPO, additional steps are required. Look for an upcoming blog from Juliano Maldaner that explains this.
XenApp 6 provides multiple options for administration. If unsure as to which is best and you have administrative rights to Active Directory for OUs that house the XenApp servers, use the Group Policy Management Console. Nonetheless, make a decision initially as to how you will administer your XenApp farm and then continue to use that method.
