Loopack processing explained by MS AD blog team:
Previous explanation:
Group Policies are normally applied to the user or their PC depending on where they are located in Active Directory. There are occasions, especially for terminal servers, when you wish users to have certain policies applied depending on which computer they log on to. This is where the loopback policy comes into its own.Two modes options when applying loopback processing:
  1.      Replace Mode: The user policy is defined entirely from the GPOs associated with the machine. Any GPOs associated with the user are ignored.
  2.      Merge Mode: The user policy settings applied are the combination of those included in both the machine and user GPOs. Where conflicts exist, the machine GPOs “win”.
A common use of loopback is on Terminal Services machines. In this scenario, it is common for the Group Policy administrator to set specific user policy settings for the server to ensure that all users using the machine receive a defined set of user policy settings.
In order to define the Loopback Processing setting, the following steps should be followed.
   1. Open the Group Policy Object editor (gpedit.msc). See Create/Edit GPOs for details.
   2. Expand the Computer Configuration node. Under Computer Configuration, expand the Administrative Templates node.
   3. Within the Administrative Templates node, expand the System node, and then the Group Policy node.
   4. Locate the setting “User Group Policy loopback processing mode”. Double click this setting, and define the setting as needed.
    * Merge Mode: When Merge mode is selected, application of user-based group policy begins as normal:
·         The distinguished name of the user is evaluated for it’s location in the Active Directory. For example, the user John Smith in the Boston OU at BigCompany Corporation might have a distinguished name of CN=John Smith,OU=Boston,DC=BigCompany,DC=Com.
·         Group policy parses the Distinguished Name, and attempts to locate policies that apply to users at each “stage” of the name. The search is performed from left to right (e.g. the Boston OU is searched first, then the domain root of BigCompany). Finally, the Active Directory Site of the user is evaluated for user policies.
·         Based on the effective permissions of the user, Group Policy determines which of these policy objects (if any) should apply to the user.
·         Policies are then applied in a last in, first out (LIFO) series. So, any policies that applied at the site level are applied first, then the domain, and finally at the OU containing the user. If multiple policies were defined at the OU or domain level, the policy with the highest precedence is added to the list first (so it will be processed last, and overwrite earlier policies).
To this point, policy processing is exactly like normal. However, once ‘normal’ processing has completed, a second iteration begins:
·         As before, Goup Policy evaluates the Distinguished Name – except this time, it is the Distinguished Name of the Computer, rather than the User. For our example, let’s say that the computer is in the Headquarters OU under the BigCompany root. The Distinguished Name is OU=Headquarters,DC=BigCompany,DC=Com.
·         The same processing rules apply as before: Group Policy evaluates policies at each level of the Distinguished Name, adding policies to the stack of policies to apply. The difference is that Group Policy is now searching for User policies that are defined in the computer’s organization structure.
·         This second set of policies is applied (again, Last In, First Out), with any policy setting conflicts being “won” by the last policy to apply the setting. So, if more restrictive settings are defined for users in a policy object linked to the Headquarters OU, those settings will apply to the user when logging onto a machine with Merge mode applied.
Typically, Merge mode is defined on Terminal Servers in an environment. The reason for this is that Administrators typically want to enforce a specific set of desktop and security settings, to help minimize potential variables that lead to unpredictable behavior on the Terminal Server. By enabling Merge mode, and defining all potential problem policy settings, the Administrator can enforce a consistent user experience.
    * Replace Mode: Replace mode is actually simpler to explain than Merge mode:
·         In Replace mode, the user’s Distinguished Name is not evaluated for Group Policy processing. Instead, we rely entirely on the Distinguished Name of the machine the user is logging onto.
·         Again using the previous example, the Distinguished Name OU=Headquarters,DC=BigCompany,DC=Com would be evaluated for User Policies, with any policies that the user has permissions to read and apply being enforced.
·         As before, the list of policies to apply is built from closest to farthest away (OU=Headquarters first, then DC=BigCompany, etc..). The list is then applied in reverse order, so that the OU settings have highest precadence.
·         The “normal policy set” for the user is ignored completely. Part of policy application is to delete the settings applied previously, so no (managed) settings will carry over to apply when Replace is defined, unless that setting was also defined in the User Settings applied during Replace mode.
Replace mode is useful for environments where specific policies are required regardless of the rights and settings of the user. Kiosk systems are a good example of this; an Administrator would typically have an unrestricted desktop experience. If that user logs onto a Kiosk machine, he or she would normally have a “wide open” desktop. This might be dangerous, so it may be useful to enable Replace mode to enforce a specific set of enforced settings.
Use case:Citrix XenApp
For the AD set-up I’d recommend the following set-up for the Citrix Xenapp environment:
·         Creation of a separate OU for your VDI/Xenapp environment.
·         This will allow to create a GPO with loopback processing enabled. Loopback processing will allow to apply user settings to computer objects in that OU, while normally you can only configure user settings in GPOs and apply them to OUs where the user objects reside. Loopback processing can be either configured in merge or replace mode. In merge mode, the users will receive both settings from GPOs applied to their own OU and from GPOs applied to the VDI/Xenapp OU. In replace mode, only the GPOs applied in the Xenapp/VDI OU will be applied. Normally I’d recommend replace mode to have better control and to avoid ripple effects.  Reasons for doing this? In the first place I’d strongly advice against storing user data and settings (profiles) on your VDI/Xenapp servers and move this data to a file server. The benefit of this approach is that the user data and settings is on the file server where it is properly backed up. Besides this it gives you more flexibility in case you want extend your environment: user settings are kept across your VDI/Xenapp infrastructure in case you add additional Xenapp servers or VDI machines or in case you need to rebuild your machine as a result of system crash. In addition to that, it will allow you to centrally manage your settings, such as specific drive mappings, applocker policies, registry keys and so on.. This can all be arranged with GPOs applied to the newly created OU.  At first sight it looks like introducing complexity in the environment, but once the principle of this is understood it’s actually very simple and it might prevent you from having to manually configure items and firefight issues. That’s the reason why this is considered as good practice in such type of environments.