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...
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Brian MurphyIT ArchitectCommented:
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.
Brian MurphyIT ArchitectCommented:
Oh, "Central Store" that is
SWCBTechServicesAuthor Commented:
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.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Brian MurphyIT ArchitectCommented:
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.
Brian MurphyIT ArchitectCommented:
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.
Brian MurphyIT ArchitectCommented:
Brian MurphyIT ArchitectCommented:
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.
SWCBTechServicesAuthor Commented:
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.
Brian MurphyIT ArchitectCommented:
You can use WSUS, or Group Policy
Configure Automatic Updates using Registry Editor 

Here are the Schema files, not sure if most updated
Brian MurphyIT ArchitectCommented:
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?
Brian MurphyIT ArchitectCommented:
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.
SWCBTechServicesAuthor Commented:
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.
Brian MurphyIT ArchitectCommented:
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.

Brian MurphyIT ArchitectCommented:
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.
SWCBTechServicesAuthor Commented:
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?
Brian MurphyIT ArchitectCommented:
Loopback processing.

Forces user settings to be applied when logging on to Citrix.
Will SzymkowskiSenior Solution ArchitectCommented:
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.

SWCBTechServicesAuthor Commented:
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?
Brian MurphyIT ArchitectCommented:
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.
SWCBTechServicesAuthor Commented:
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?
Brian MurphyIT ArchitectCommented:
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?
Brian MurphyIT ArchitectCommented:
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.
Brian MurphyIT ArchitectCommented:
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
SWCBTechServicesAuthor Commented:
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)
Brian MurphyIT ArchitectCommented:
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.
Brian MurphyIT ArchitectCommented:
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.
Brian MurphyIT ArchitectCommented:
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.

SWCBTechServicesAuthor Commented:
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.
Brian MurphyIT ArchitectCommented:
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.
Brian MurphyIT ArchitectCommented:
Revised Picture
Brian MurphyIT ArchitectCommented:
Revised further
Brian MurphyIT ArchitectCommented:
Any help or need more?
SWCBTechServicesAuthor Commented:
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)
Brian MurphyIT ArchitectCommented:
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

Brian MurphyIT ArchitectCommented:
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.
SWCBTechServicesAuthor Commented:
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?
Brian MurphyIT ArchitectCommented:
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?
SWCBTechServicesAuthor Commented:
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.
Brian MurphyIT ArchitectCommented:
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
SWCBTechServicesAuthor Commented:
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.
SWCBTechServicesAuthor Commented:
I think I found the problem. There was a GPO with Loopback Replace enabled applied to the Citrix Servers OU. Even though I unlinked the GPO, I didn't seem to fix the problem until I deleted the Loopback Replace GPO and rebooted the server. Now I can see the UserSettingsGPO being applied.

Thanks for all your help!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Brian MurphyIT ArchitectCommented:
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.
SWCBTechServicesAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.