Citrix Policy Basics 101


As a Scouser (Endearing term for those of us born in Liverpool) who moved towards the south of England, every now and then I venture out and have a night out on the tiles. I will approach a bar and order some extravagant dressed up beverage. This is fine until my northern mates come to visit and smack me right back down to Earth and say, “Remember your roots lad!”

It is at this point the rounds turn in to the stuff of legend.

(These days I am a father of two so this is not common place nor was I ever really the stuff of legend ) 😉

Why do I mention this? Well, with anything in life, no matter how far you progress it is important to remember your roots. Most of us like to venture forward but without a solid grounding as a base we will begin to make mistakes.

This is the same with technology. Mistakes are quite often made with common tasks. People tend to concentrate on the latest and greatest and  sometimes forget about the fundamental basics.

As a support orientated consultant, I often see this happen in my field. I see very clever implementations done by very clever people but now and then issues arise and often it is due to some sort of oversight at those basic levels. Whether it is on premises or cloud the fundamental building blocks of any infrastructure will dictate how successful your implementation will be.

This series of  “101” articles will serve as a refresher about those basics starting with Citrix Policy 101.

I will talk about policy processing and precedence, best practices, policy modelling, locations policies are stored, tips and tricks and enough information to provide you with effective troubleshooting skills.

Stored Policy Locations

Citrix policies are stored in the Xenapp and Xendesktop Site database. They apply to systems that have the VDA agent installed. They are configured within the Studio console.

Site Policies in Active Directory are stored in the sysvol folder which replicates amongst domain controllers in a domain. They are configured using the group policy management console. (gpmc.msc)

Domain policies in Active Directory are stored In the sysvol folder which replicates amongst Domain Controllers in a domain. They are configured using the group policy management console. (gpmc.msc)

OU policies in Active Directory are stored in the sysvol folder which replicates amongst Domain Controllers in a domain. They are configured using the group policy management console. (gpmc.msc)

Local policies apply to the local machine and are stored in the registry of the local machine. They are configured using the local group policy editor (gpedit.msc)

All policies can contain Microsoft and Citrix settings apart the ones in Studio (Just Citrix)

As shown policies can be configured in multiple locations – the Group policy engine or the Citrix policy engine.

Tip! It is advised as part of best practice to choose a single location to configure your policies as this streamlines any troubleshooting you may have to carry out.

Best practice would be to configure your policies using the Group Policy Engine (Sysvol) but as a Citrix administrator, if you do not have access to AD GPO you can use the Citrix policy Engine using Citrix Studio console (Site DB).

Processing and Precedence

Policy Processing

  • Local GPO is processed first
  • Citrix Policies Created with Studio
  • Site GPO
  • Domain GPO
  • OU GPO – Processed last

Policy Precedence

  • OU GPO – Highest/Winner
  • Domain GPO
  • Site GPO
  • Citrix Policies Created with Studio
  • Local GPO
NOTE: Citrix Policies in Studio will be overridden by Citrix Policies at the OU level.

Citrix Policies rank from 1 upwards. The lower the number the higher the priority. So, a Citrix policy setting that has a priority of 1 will take precedence over a setting with the priority of 2.

Some Citrix Policies rely on underlying Microsoft functionality. If this is not enabled the Citrix policy will not apply.

Policies only configured in lower priority only will take affect over non-configured policies in higher priorities.



Assess the security requirements (Session limits, clipboard redirection, client mapped drives, authentication/encryption, removable media)


Assess your end user locations so you can successfully make bandwidth optimisation/restriction decisions. These will be decisions on printing bandwidth limits, dpi, audio, video etc. Also assess your OS optimisations and plan on a way of implementing these.

Virtual Infrastructure

Assess the virtual machine settings (updates, local client or server time, start menu, power button, Icons, shortcuts)

Policy Types

Identify Citrix and Windows policies that are required to achieve your goals.

A list of policy references can be found in the following link to help you assess:

Limit amount of Policies

There is a school of thought that it does help separate policies out according to functions (Printing, Bandwidth etc). Although easier for the Administrator it can cause a performance hit.

In addition, try to avoid duplicate policy settings as this increases logon time.


Filters define the criteria that is used to apply a policy to a computer or user object.

Apply your base foundational policies by setting them to the broadest filter. This eases administration when applying later policies that should only apply to specific situations.

By having an unfiltered policy this will apply to all. Also apply a baseline policy with the lowest priority so exceptions can take precedence.

A default unfiltered policy is provided to apply your broadest settings. If you do not wish to use this default unfiltered policy, you can disable it. This policy applies to all users and computers in the Farm/Site as no filter is set.

NEVER set a policy setting to its default value unless you are overriding a setting in a lower precedence policy. Setting default values requires extra work which requires extra time which adds to policy processing time. (Tip from Carl Webster)

An example of filters to apply is shown in this table:

Filtering Mechanisms

There are 3 filtering mechanisms –

GPO link location – This is Site, Domain or OU targeting. Careful planning of OU structure is required to be effective.

Security Filtering – This is used to restrict the policy set in an ou from applying to certain objects. A common example is Disabling lockdown settings to Admins so they have full functionality logging on to a VDA. Denying a group, a policy via security filtering or removing the group from Security filtering prevents the GPO from applying to that group.

WMI Filtering – This is used to further restrict how a GPO is applied. At this level you can specify the OU should only apply to 64 bit and not 32 bit computers. Just be aware that WMI filters can cause logon delays.

Understanding the LOOP-BACK policy

Allows user settings to be applied to a computer object.

You have two modes –

Replace – This will only apply the user settings specified to the computer object in the OU. No user policies outside this will be applied.

Merge – Other user settings outside the OU will apply.

I usually go with REPLACE but that is my preference.

Citrix Policy Templates

Citrix provide “best practice” templates to reduce your administrative tasks. There are a set of predefined templates for use cases that apply to certain situations such as low bandwidth, WAN and internal connections.

Additional predefined templates can be obtained via the Citrix support web site.

Simply open a template and use the configured settings or apply your own from this best practice point.

The below table highlights how to carry out actions using templates.

Backing up and Importing Policy

You can also import and export policy templates from the Actions tab. So, if you have your own predefined best practices from out in the field you can use these templates and configure as necessary.

Another way to backup your policy settings would be to use Powershell.

To import the Policy, carry out the following cmd.

Comparison and Modelling

Citrix provides a tool for comparing policies.

Warning signs indicate conflicting settings. You can drill down in to the warning signs for more information.

There are also two wizards provided which help you assess how policies are applied to your users connecting to VDA’s.

The Citrix Group Policy Modelling Wizard will show you results of Citrix and Microsoft GPO’s. This is found in the Group Policy Management Console.

You also get the Citrix Modelling Wizard. This will only show you the Citrix Policies and is found in the Studio console.

How Policies are Applied

Computer policies will apply at a system start. So, changes made will take affect after a reboot.

User Policies will apply when a user logs on. So, make your change, log the user off and back on for it to apply.

Policies are refreshed every 90 minutes plus 0-30 minutes.

Reconnecting a session will cause policies to re-evaluate and using GPUPDATE /FORCE will also trigger a refresh.

The Full Process

  • User logs in and Winlogon process starts up.
  • Client Side Extensions are then loaded. Both Microsoft and Citrix.
  • Citrix CSE will start to process policies (Local GPO first)
  • The Citrix CSE will then process Farm policies
  • Lastly the Citrix CSE will process Active Directory policies.
  • Now the precedence order will take effect.
  • A resultant set of policies file is generated (RSOP.GPF)
  • This file is used to make the actual policy settings in the registry.
Policy Folders

The Citrix Client-Side Extensions are responsible for caching the policies on your VDA system. The CSE is contained within the VDA itself.

  • HDXSite – Indicates it is a Citrix Policy
  • GUID – Indicates it is an AD GPO
  • Local Group Policy – Indicates a local GPO
  • 0 = User Policy
  • 1 = Computer Policy

The other folder of significance is where RSOP files are stored on the machines. These are the active combined policy settings. The numeric folders indicate the session ID.

Tip: Deleting the contents of both folders and performing a GPUPDATE /FORCE will completely refresh the policies.
Registry Policy locations

The below registry location is where policies are stored in the registry.

(Note: User Profile Manager settings too!)

This registry directory requires some explaining.

The numeric numbers are the user policy settings stored under a session id.

In each of the folders you will see the values of the policies set.

Events – This is the timestamp of the last computer update. There is an Events key also located in the User session ID folders. Using this key you could figure out when the user last logged on. As this would be when user session policies applied.

Evidence – This is where the filter criteria is tracked and stored.

ICAPolicies – Computer settings


The following information will provide you with good troubleshooting knowledge and methodology.

The Full Policy Troubleshooting Process

  • Check  Citrix CSE versions (Client Side Extension folder -CitrixCseEngine.exe)
  • Check the GPMC version (Group Policy – Management Components folder – CitrixGPMCConnector.dll)
  • Compare the versions to your appropriate product version (Support Site)
  • Check AD cached policies in C:\ProgramData\CitrixCseCache
  • Use the GUID to take a closer look in AD
  • Search in GPMC (Unique id) or use powershell to find a match
  • Look at the Created and modified dates of the GPO and compare this with the cache folder. This will tell you if the cached folder is up to date.
  • If it did not match you could issue a GPUPDATE /FORCE
  • If this does not work check event viewer for errors
  • Now check the Studio Policies in C:\ProgramData\Citrix\GroupPolicy
  • Computer and User files will both contain rollback and rsop gpf files if not something is wrong.
  • Check the registry locations
  • Check how policies are filtered
  • Check HKLM\Software\Citrix\ICA\Session\ (shows connection details – name, client address and full client version). Issues with policies not applying could be due to subnet changes or client rebuilds.

High Level Troubleshooting Methodology

  • Find out the problem
  • Replicate the problem
  • Gather evidence
  • Investigate
  • Test scenarios
  • Resolve

On a shared hosted server system, you may need to RDP to the server as an administrator and drill in to the registry and folder locations highlighted in this document to figure out issues.

You may need to set the policy priority to the highest and apply to a test user to see if the policy applies.

Use the tools at hand you have been provided to gather evidence such as the comparison and modelling tools, resultant set of policy etc.

Corrupt policy cache scenarios could involve deleting the contents of the CSE folder locations and the RSOP folder locations for the policies.

Sometimes you may have a locked down environment and you will need to relax this for troubleshooting if you have no run command or cannot access the registry.

One other method to get around this is to inject a cmd shortcut in to the affected users profile and opening elevated.

I find the following command is also useful to provide you with RSOP information from the GPO whilst logged in to a user’s session.

Command Prompt:

GPResult.exe /H %TEMP%\%USERNAME%.htm





Troubleshooting Policies Using Tools


CtxCseUtil is a tool that can generate resultant set of policy (RSOP) report (per computer, per user or both) for Citrix policies on a device that has the Group Policy Management Console installed.

It can be run locally or remotely against a server VDA. This tool will convert RSOP.GPF to HTML report. The end user does not have to be actively logged in but does need to have logged in at some point. This tool needs WinRm configured so it can run on the machine you are running it from and the target.

Also run the tool with AD privileges.

Example elevated cmd prompt targeting a logged in user using the /u switch and c/ switch (u= user/ c=computer)

Retrieved Citrix User Policies

Retrieved Citrix Computer Policies

Citrix Group Policy PowerShell Module

Import-Module C:\Citrix.GroupPolicy.Commands.psml

The following commands will provide you with help on how to use this module –



This command will backup your policy settings in to the specified folder.

Export-CtxGroupPolicy c:\Tools\GroupPolicy

Exporting Citrix Policies from AD GPO is outlined here – CTX140039 and more on using powershell to create policies can be found here –

WMI Issues

WMI filters can cause issues. Logons and reconnects can take a long time to occur.

You should enable Group Policy logging – HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics\

“GPSvcDebugLevel”=dword 00030002

The log file location is %WINDIR%\debug\usermode\gpsvc.log

If you see FilterCheck: Evaluate returned error. hr=0x80041069 – This means AD is timing out on WMI calls.

Event Viewer will also highlight WMI errors.


Having a fundamental grasp on how policies work is vital. After all the hard work of implementation is done you are left with the user experience. If this is not good, all that hard work goes down the drain. This is what people hear about, the user gripes, frustrations, session experience etc.

Citrix have supplied you with great tools to troubleshoot HDX environments and getting your policies right for your devices and connections whether they are WAN, LAN, REMOTE or VIRTUAL/PHYSICAL is paramount and once your users are satisfied then you as a Consultant can relax. Remember policy best practices are always changing so, after the implementation is all said and done never forget to do the following:

Manage – Maintain – Assess – Re-evaluate- Improve – Manage – Maintain – Assess – Re-evaluate – Improve – Pay Rise!!!



Carpe Diem!