Did you ever want to fully automate your XenApp 6.5 farm? Did you manage an automated unattended installation or image, but  you are struggling to automate farm configurations? Would you like to learn how to create and configure policies for XenApp 6.5 with PowerShell? In this case, this article is just for you.

Automating Citrix consists of various components. You need to configure:

• Citrix administrators
• Citrix worker groups
• Citrix user and computer policies (explained in this article)
• Citrix load evaluators

Note: see the article PowerShell Fundamentals if you are new to PowerShell or if you just want to refresh your memory. Especially important is the part about loading snap-ins and modules. Remember, the appropriate extensions need to be loaded before Citrix commands can be executed!

Creating and configuring Citrix policies using PowerShell

Creating and configuring Citrix policies is one of the more complex items to script. It is complex because there are multiple steps involved and sometimes there is more than one option within a single step:

• Citrix policies can be created within a local Microsoft group policy, a Microsoft group policy in Active Directory or within an IMA based policy stored in the farm data store;
• Citrix policies need to be created, configured and applied to an object (such as an Active Directory security group);
• Policies need to be prioritized. If not, the policy which was created last will automatically be applied first (which may not be the correct order);
• Last but not least a policy contains many settings. Knowing the names of your settings can be quite a challenge.

Creating policies involves the following steps:

• Creating the corresponding drive (for Active Directory connections only)
• Creating the policy
• Configuring the policy
• Adding filter(s) to the policy
• Prioritizing the policy

The following script creates an IMA-based group policy. The policy name is “Main user policy” and the description is “Allow client drive and printer redirection”. The script configures the following user settings:

• Allow client drive redirection
• Allow client fixed drives
• Deny client floppy drives
• Allow client printer redirection
• Do not adjust the user’s default printer

The policy is filtered on the user group “%domain%\CitrixUsers” and clients starting with the name “WI*”. After configuring the policy the priority is set to 1. This makes it the highest policy so it is executed last.

The rest of this article analyzes the script in detail.

General

The script can run as-is in any environment. Simply copy the script into Notepad or any other (more sophisticated) tool and save it as a *.PS1 file. Change the following values according to your specifications:

• $PolicyDrive -> possible values are LocalFarmGPO (default), LocalGPO or ADGPO*
• $PolicyName -> choose a name for the policy (the name can contain spaces)
• $PolicyType -> possible values are User or Computer
• $PolicyDescription -> write a description for the policy (optional)
• $PolicyPriority -> enter a number (1 or higher) to determine the priority level**

*The value LocalFarmGPO stores the policy in the Citrix data store, LocalGPO stores the policy in a local group policy object and ADGPO stores the Citrix policy in an Active Directory policy. Make sure that the Active Directory policy exists before executing the script.

**Priority 1 is the highest, which means that the policy is executed last.

Also, the actual policy configurations and filter need to be configured according to your preferences as well.

For more information go to the section Configuring the policy.

For more information go to the section Adding filter(s) to the policy.

Part 1 of 5: creating the corresponding drive

Before you create a Citrix policy you have to decide if you want to store it in the farm data store, in a local Microsoft policy or in Active Directory. This is done by entering the corresponding value in the variable $PolicyDrive (see previous paragraph).

After loading the Citrix snapins the PowerShell drives “LocalFarmGPO” and “LocalGPO” are created by default.

Only a connection (drive) to Active Directory needs to be created. The script checks the value in the variable $PolicyDrive; if “ADGPO” is entered a new PowerShell drive connecting to Active Directory is created. The new PowerShell drive is a non-persistent drive used only within the session.

Note:
I recommend always placing your policies in the data store. My reasons are the following:

• Citrix policies cannot be managed on every Windows server in your domain and I want always to be able to manage my Microsoft policies from whichever server I choose.
  Explanation: Citrix policies are associated with Group Policy Objects (GPOs) using console extensions. You need the Citrix group policy engine to manage settings and this engine is only part of the Citrix console. The policies are archived in Sysvol, but no ADM files are used to configure these policies and there is no Active Directory schema extension. Sysvol is merely used as a distribution mechanism.
• I do not like the whole look and feel of the Citrix extension within a Microsoft policy. I find it confusing that you can create multiple Citrix policies in one Microsoft policy. I am worried you may lose track of which setting is configured where. Also, I am not happy with the fact that I have to use a Citrix tool to manage settings in a Microsoft policy.

• The fact that the Citrix policies are a client extension they cannot be managed with third-party tools (such as NetIQ for example).
• And last but not least, why bother placing Citrix policies in Active Directory at all? What is the benefit? The policies are only used on Citrix XenApp servers in the first place. Active Directory (Sysvol) is only used as a distribution mechanism, so why not store these settings in the data store? The data store also automatically replicates the policies to all (XenApp) servers.

I simply see no benefits, only disadvantages.

Links:

• FAQ: Citrix Policies in XenApp 6.0 or later Cannot be Configured Using ADM Templates
  http://support.citrix.com/article/CTX125141 (article no longer exists)
• Citrix Group Policy Engine Facts in XenApp Version 6.x
  http://support.citrix.com/article/CTX125152

Part 2 of 5: creating the policy

After connecting to the correct drive the policy is created. This is done via the command:

The command takes its input from the variables $PolicyName, $PolicyType, $PolicyDescription and $PolicyDrive as defined in the beginning of the script.

A newly created policy it is empty: there are no settings configured by default. If the policy already exists the script simply continues with part 3 “Configuring the policy”.

Part 3 of 5: configuring the policy

Two types of policies can be configured; either computer and user. Unlike Microsoft policies, there are no settings that can be configured in both policies.

Policies can contain various types of settings:

• State
• Value
• Other, such as data in XML (e.g. settings for Health Monitoring)*

Many policies contain both a state and a value. When configuring a value the setting itself is enabled automatically. Therefore, it is unnecessary to set a value and explicitly enable the policy.

The script contains the function ConfigurePolicy which can configure either a state or a value. For example, to allow client drive redirection call the function as follows:

The function ConfigurePolicy needs to be called with three parameters: the name of the policy item, the type (“state” or “value”), and the actual state or value.

If you want to know which settings can be configured install the Citrix PowerShell SDK and check the Citrix XenApp 6.5 Server SDK Help file in the section Group Policy Settings. The XenApp 6.5 SDK can be downloaded here:
https://www.citrix.com/downloads/xenapp/sdks/powershell-sdk.html

Part 4 of 5: adding filter(s) to the policy

After creating and configuring the policy needs to be applied to either a:

• Access Control
• Branch Repeater
• Client IP Address
• Client Name
• Organizational Unit
• User or Group
• Worker Group

Before being able to create a filter there is one additional step that needs to be performed. A filter name needs to be created before a filter can be applied. The filter name is never used or seen in any console, so the name is not important. The name has to be unique though. I therefore always use the current date and time (including the seconds) and the Get-Random cmdlet to generate the name.

After creating the filter name the actual filter can be applied. As mentioned several different filter types exist. The function AddPolicyFilter is responsible for applying the filter. Here are some examples:

Apply an ALLOW filter based on an IP range:

Apply an ALLOW filter based on the client name starting with WI (followed by a wildcard):

Apply an ALLOW filter based on the OU CitrixServers*:

*Write the actual name of the (child) OU. Do not enter a path such as “Servers\CitrixServers” and do not enter an LDAP value such as “OU=Servers,OU=CitrixServers,DC=local,DC=com”.

Apply an ALLOW filter based on the domain group CitrixUsers:

Apply a DENY filter based on the worker group PRODUCTION:

Part 5 of 5: prioritizing the policy

After creating a policy it needs to be prioritized. This is the last step in the policy creation process. The policies should be applied in the order of your choosing. Policy ranking is not always important if there are no conflicting settings. The unfiltered policy however should always be applied first since it cannot be filtered on specific computers or users. This means that the unfiltered policy should always have the lowest rank which means that it has the highest number of all policies.

The command takes its input from the variables $PolicyName, $PolicyType, $PolicyPriority and $PolicyDrive as defined in the beginning of the script.

Related articles:

• Automating XenApp 6.5 Part 1 of 4 – Citrix Administrators
• Automating XenApp 6.5 Part 2 of 4 – Citrix Worker Groups
• Automating XenApp 6.5 Part 4 of 4 – Citrix Load Evaluators
• PowerShell “one-liners” for Citrix XenApp 6.x