Link to home
Start Free TrialLog in
Avatar of SWCBTechServices

asked on

User OU Group Policies are not applied when user logs into Citrix Server

I have recently published Office 2013 on our XenApp servers. I created a GPO with a bunch of Office 2013 settings in it, and linked this GPO to an OU that contains all of our users. However, when a user runs the published application (logs into the XenApp server), the user GPO's are not being applied. In fact, none of the GPO's linked to the Users OU are applying when logging on to the XenApp Server.

The GPO's apply when the same user logs into other computers and servers (these computer objects are in a different OU from the Citrix servers). The Citrix Server OU does not have Block Inheritance enabled. There are no Deny permissions on the User GPOs. The User GPO's only have "Authenticated Users" for Security Filtering. There are GPOs applied to the Citrix Servers OU with loopback processing enabled in Replace mode, but as far as I understand, this shouldn't block the User GPOs...
Avatar of Brian Murphy
Brian Murphy
Flag of United States of America image

Is your Central Repository setup right on your SYSVOL?

Or did you place the ADMX files in PolicyDefinitions under C:\Windows?

You did not mention, so have to ask.

Centralized policies and the PolicyDefinitions folder on SYSVOL hosts the ADMX aforementioned.

GPO Policy links don't work if that is not done correct.

First guess.
Avatar of SWCBTechServices


We don't have a Central Store. My understanding is that the Central Store only provides the policy definitions, not the actual policies themselves (ie: the registry settings). So, with Central Store when viewing a GPResult report, the policies will be categorized and sorted nicely and include the nice descriptions of each setting, because the definitions are available. Without a Central Store the settings are still applied, but show up in a GPResult report under the "Extra Registry Settings" heading.

In fact, I fairly certain this is true, because the settings are applied to other computers without the Central Store.
First time hearing that one.  We use Central store for everything.  Registry settings are customized into the ADMX files.  Otherwise your talking local policies (gpedit.msc) and you cannot control those at the OU level.

Not possible.
Also, not porting them to the Store is "tagging" the registry.

Any registry key can be moved to GPO Central Store.

Then you have Group Policy preference.
Administrators can modify the registry by using Registry Editor (Regedit.exe or Regedt32.exe), Group Policy, System Policy, Registry (.reg) files, or by running scripts such as VisualBasic script files. 

Same concept for GPO

Just a little out dated.
Ok, sorry...I can see the registry.pol file in \\domain\sysvol\policies\<GUID>\User

This file contains the registry settings for the Office 2013 GPO I created. So computers should have no problem reading the settings from this store, correct?

Remember, other computers in my domain are applying these settings correctly, only my Citrix XenApp servers seem to be excluding them.
You can use WSUS, or Group Policy
Configure Automatic Updates using Registry Editor 

Here are the Schema files, not sure if most updated
Anything in that OU or having that GPO Linked should apply, yes.

Even if someone copied earlier version of files to local PolicyDefinitions your OU takes precedent.

So, if they are in the same Domain, simply link that Group Policy in Active Directory to the OU that has your Citrix Servers?
The only other thing that comes to mind is how you made the settings change.

I'm assuming you used the Enterprise Tools for Group Policy Management, yes?

Or are you asking very specific to making Registry setting manual changes not listed in your Group Policy settings.  Like custom registry settings?  Whether command line or regedit?

If it is applying to your other computers and works on all of them but not Citrix - you ruled out some stuff like not blocking.  If the Citrix servers are in a OU beneath another OU, blocking is usually the issue.

I usually put Citrix OU in the Top level and separate from all other servers, workstations, et cetera.

So, easy way to tell is logon to a Citrix Server.

Open CMD prompt (as local administrator and logged on with AD Domain account).


Open the HTML file and see what's going on.
The GPOs in question contain User Configuration. Yes, I understand I could enable loopback processing on the policy to have User Config applied to a Computers OU, but that should not be necessary should it?

The GPO's in question are linked to a User's OU, and the User is logging into the Citrix server, therefore GPO's linked to that User should still apply where ever that User logs in. That's how it works everywhere else in our Domain...except for these Citrix Servers in the Citrix Server OU.

So obviously something with the Citrix Servers OU is blocking the User OU GPOs from applying...I just can't figure out what. I need to get to the root cause of this issue.
Citrix servers are not like any other, you do actually have to enable Group Policy Loopback processing.

Computer Configuration > Administrative Templates > System > Group Policy > User Group Policy loopback processing mode and enable the setting.

Select the mode to Merge.

Feel free to create a GPO that only has the loopback being enabled (maybe called Enable Loopback - Merge) (or Replace in a lot of cases) and link that to each OU you have Citrix servers in.

Remember that GPO's are cumulative. The processing procedure merges all the GPO's applying to the OU together (with higher priority ones applied last, thus overwriting previous settings if there are conflicts) and then applies that result to the server.

It obviously gets even more complicated with loopback. With Replace, the only GPO's processed are the ones attached to the OU that the computer is in. With Merge, the GPO's attached to the user's OU are also added in (that is, the USER parts of them), but BEFORE the computer OU ones - so the computer OU GPO's will override any settings from the users's OU.
But what I'm saying is I should not have to link the User GPO to the Citrix Server OU!

What could be blocking the User GPO from applying to the User when logging into Citrix servers?
Avatar of Brian Murphy
Brian Murphy
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Finally the last comment that Brian has stated is correct. You need to use Loopback Processing "Merge Mode". For what you are looking for.

This is so that when you login to the Citrix Server the User Policies that are tried to this machine are applied to the user rather than applying the User sided GPOs from the OU where the users reside in.

Loopback Processing is Citrix 101 with Group Policy. First thing I configure when implementing Citrix.

Yes finally thank you guys...the clear answer is that a GPO with Loopback Merge Mode enabled must be applied to the Citrix servers.

So, when XenApp was installed on the server, something is put in place to block User OU GPO's? Does the XenApp installer do this? Does the Citrix administrator do this? If so, how is this block achieved? Local Policies? Registry change?
Think of it like a workstation OU but you need computer policies to apply to all users.  Per that last link:


Setting loopback causes the User Configuration settings in GPOs that apply to the computer to be applied to every user logging on to that computer, instead of (in replace mode) or in addition to (in merge mode) the User Configuration settings of the user. This allows you to ensure that a consistent set of policies is applied to any user logging on to a particular computer, regardless of their location in Active Directory.
Brian, we're going in circles here...

Let me explain my understanding of loopback processing:
- If I have USER CONFIGURATIONS in a GPO, but I link that GPO to an OU that contains COMPUTER objects, I need loopback enabled so that those USER CONFIGURATIONS apply to any user that logs into that COMPUTER (which resides in the COMPUTERS OU)

Please let me know if that understanding is correct???

However, we have all of our USER CONFIGURATIONS in GPO's that are only linked to OUs that contain Users. We keep our COMPUTER CONFIGURATIONS is separate GPOs that are only linked to OUs with COMPUTERS in them. I believe this is best practice. Therefore loopback processing is not required since we don't try to apply USER CONFIGURATIONS to OUs with computers.

But, what you and Will are saying is that, somehow, Citrix servers break this default behavior of group policy, and I must have Loopback Merge enabled on my Citrix Servers OU (which contains Computer objects) in order for the USER CONFIGURATIONS GPOs linked to my Users-only OU to apply when said user logs in to a Citrix server.

Can we agree on any of those statements?
Citrix or just Remote Desktop or Terminal Services is where you need User settings to apply to those computers regardless of where the "Users" exist in AD OU / GPO Land.

I use Lookback Merge as well on my Citrix Servers OU which does only have Citrix\RDS servers which like a workstation need User settings to apply.

Problem in some case is you might not want those to apply but instead have users in another OU for remote users only as example.  They you might actually block the other user settings but still need to set Loopback processing where the Users are in ABC OU and RDS\Citrix Servers are in another XYZ OU.

Did I miss something?
So, if you have Users in a Citrix_Users OU with User settings, those will not apply at logon to Citrix servers in Citrix_Servers OU without Loopback Processing Mode to Merge.

That merges the settings on Citrix_Users OU for user only when users logon to a server in Citrix_Servers OU.
Larger point being you may want to change the Logon Banner, screen savor, et cetera.

There are use cases for merge and replace and depending on where the users reside in OU's.

If it is a top level User setting only OU there are different use case scenarios.

Here, it is Loopback Processing - Merge
So, if you have Users in a Citrix_Users OU with User settings, those will not apply at logon to Citrix servers in Citrix_Servers OU without Loopback Processing Mode to Merge.

So my question is How? How is Citrix blocking the User GPO?  Because for all other windows computers, loopback is not required to have the User settings GPO apply to a user. (Or maybe I have a basic misunderstaning of GP)
I see the confusion.  It is not blocking.  

See picture attached.

You have a Computer only policy applied to Citrix OU?  Yes?

Your telling your Computer only policy to loop back around and apply an User Policies.

If multiple forest scenario, there is the other setting for Roaming Profiles - both in Computer Settings.

You have effectively said don't apply any user policies on this OU.

It is an override.
The user’s account could be located anywhere within the Active Directory structure, creating difficulty with simply applying user configuration based policies.  You would not apply Citrix only settings at the "Domain Level".

Simply applying the user configuration settings at the OU where the Citrix servers are located will also not work, as the user accounts are not located within that OU.

The solution is to apply a loopback policy, which is a computer configuration policy that forces the computer to apply the assigned user configuration policy of the OU to any user who logs onto the server regardless of the user’s location within Active Directory.

Loopback processing can be applied with either merge or replace settings. Using replace overwrites the entire user GPO with the policy from the Citrix server OU.

Merge will combine the USER GPO with the GPO from the Citrix server OU. As the computer GPOs are processed AFTER the user GPOs when merge is used, the Citrix related OU settings will have precedence and be applied in the event of a conflict.
Merge will combine the USER GPO with the GPO from the Citrix server OU. As the computer GPOs are processed AFTER the user GPOs when merge is used, the Citrix related OU settings will have precedence and be applied in the event of a conflict.

Maybe this is the confusion
1. Loopback with Merge
2. User settings from WhereverOU in get process before Computer
3. User settings get applied to Citrix
4. Then Computer Settings

That setting says STOP, process any User Settings BEFORE continuing.

Brian, I really appreciate your efforts here, but I'm still struggling to understand. Can we take Citrix and loopback completely out of the equation for now, and build me up from scratch?

Take a look at this picture I made up and tell me if I'm missing something fundamental in my understanding. Thanks alot.
Okay, quick swag.

Again, you have a User Configuration policy for User1

You have a Computer Policy that only applies to Computer 1.

Where is your GPO setting for Citrix Servers? It is a top level OU under

You need minimum a Citrix_GPO_Computer_Settings

Link to MyCitrixServersOU

You cannot use the other computer policy to disable Administrators.

You need a dedicated Computer Policy, Disable Administrator, Loopback Processing Merge.

So, when User 1 logs on to CitrixServer1, the user Settings from far left get applied.

That 2nd to right is Computer and only works on that OU unless you link it to both OU's.

I recommend a dedicated GPO for Citrix, Link it to CitrixServersOU, enable Loopback.

Loopback will not work for Computer Settings in another OU.  Only User Settings and apply those FIRST then process Computer Settings on THAT OU.
Revised Picture
Revised further
Any help or need more?
Thanks Brian. Sorry, but to clarify in my original picture...

In scenario 3, the USER GPO is not being applied, which is what is unexpected. The computer configuration is not linked to the Citrix OU, so I do not expect it to apply to CITRIXSERVER1.

So my question would be: In Scenario 3, why would the User GPO not apply to USER1 on CITRIXSERVER1?

(Edit: Updated picture attached)
Just focus on the Citrix Server OU.

If you just create another GPO and link it to that OU, nothing more, enable Loopback - Merge on Computer Settings.

I don't see anything linked to your Citrix Server OU.  If you want User1 policies to apply you must create a new GPO and Disable User Policies, enable Computer only and make one setting.

Turn on Loopback Processing - Merge.  Call it Citrix_Loopback_GPO, Link it to the Citrix OU.

Do a GPUDATE /FORCE on the Citrix Server after NTDS replication in AD.

User policies from far left will apply after you enable Loopback in a new policy only linked to Citrix OU.

Bare minimum, this will work.  No other policies to the left apply.  Only way to get the User Policy far left is to create a GPO For Citrix Servers only, Enable Computer Policies, Enable Loopback Processing Mode - Merge.

That one thing will make User settings apply despite using a "Computer Policy" only

So, why not link the User GPO to Citrix OU?

Won't work.  You would need to move all Citrix users into the Citrix OU.

Users on far left can only get those settings on Citrix Servers if you force Loopback Processing.

It says, I know these are computers only but I want you to take any User related settings applied to the USERS regardless of OU and process those first as if you had the users in the same OU as the Servers - but you don't.  So, Loopback.
Thanks Brian. Yes I understand the changes you suggest will fix my problem...I get that, I really do!

But what I don't understand is WHY!?

Why does the USER policy apply when USER1 logs into COMPUTER1, but the USER policy does not apply when USER1 logs into CITRIXSERVER1.

This is the core of my question! Why does Scenario 1 work as expected, but Scenario 3 requires loopback?
Do you have Users Policies enabled on Users OU and Computer Policies disabled to streamline processing mode?  On Workstation, disable User Policies for that GPO, enable Computer Policies.  Authenticated Users have Read and Apply on both OU's.

How would the Citrix servers know to process the User policies lower down the OU chain.

It looks like you have the first two at same level.  Move user policies up to Domain level it will get processed on both by default unless you Block Inheritance.  

I assume all your Domain level policies apply to both?

GPO processing is the "Higher" up not lower down.  Everything overrides Local Computer Policies, OU Policies, Domain Policies, and Sites and Services policies reign over all.

This sound logical?
Yes this sounds logical and agrees with my understanding of GP.  However:

How would the Citrix servers know to process the User policies lower down the OU chain.
Because the policies are linked to an OU of which the user is a member. Shouldn't matter where in the OU chain the GPO is applied.

I'm thinking that the only way the User OU GPO could be blocked is if Loopback Replace is applied to the Citrix Server OU, but there are no User policies applied to Citrix Server OU, hence a completely empty User Configuration policy. However I have blocked inheritance on CitrixServer OU, but the USER OU GPO is still not applying when the user logs in to Citrix Server.
Correct.  Regardless of where those user policies are.

There are no user policies on Citrix OU.  What about Computer?

That is where your Loopback setting is under Computer Settings.  

That is why I suggested running GPRESULT /H C:\TEMP\RESULTS.HTML

This "should" tell you what all is being applied in a nice HTML report
I have un-linked all policies from the Citrix OU and blocked inheritance on the Citrix OU. So there are no computer policies applied at all.

Gpresult /user Username (ran from the Citrix Server) does not show the UserOU GPOs anywhere...not in Applied or Denied GPOs.

GP Modeling from GPMC does show that the UserOU GPOs should be applied though.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
When you unlinked did you run GPUPDATE /FORCE on the server?

Still might have required reboot, regardless.

But yea, if that had been "Merge" instead of "Replace" would not be having this conversation.
Although a Loopback Replace GPO appears to be the culprit, simply unlinking it did not solve the problem. I had to delete the GPO and reboot the server.