Circle Back to Loopback

아티클
02/08/2013

Hello again! Kim Nichols here again. For this post, I'm taking a break from the AD LDS discussions (hold your applause until the end) and going back to a topic near and dear to my heart - Group Policy loopback processing.

Loopback processing is not a new concept to Group Policy, but it still causes confusion for even the most experienced Group Policy administrators.

This post is the first part of a two part blog series on User Group Policy Loopback processing.

Part 1 provides a general Group Policy refresher and introduces Loopback processing
Part 2 covers Troubleshooting Group Policy loopback processing

Hopefully these posts will refresh your memory and provide some tips for troubleshooting Group Policy processing when loopback is involved.

Part 1: Group Policy and Loopback processing refresher

Normal Group Policy Processing

Before we dig in too deeply, let's quickly cover normal Group Policy processing. Thinking back to when we first learned about Group Policy processing, we learned that Group Policy
applies in the following order:

Local Group Policy
Site
Domain
OU

You may have heard Active Directory “old timers” refer to this as LSDOU. As a result of LSDOU, settings from GPOs linked closest (lower in OU structure) to the user take precedence over those linked farther from the user (higher in OU structure). GPO configuration options such as Block Inheritance and Enforced (previously called No Override for you old school admins) can modify processing as well, but we will keep things simple for the purposes of this example. Normal user group policy processing applies user settings from GPOs linked to the Site, Domain, and OU containing the user object regardless of the location of the computer object in Active Directory.

Let's use a picture to clarify this. For this example, the user is the "E" OU and the computer is in the "G" OU of the contoso.com domain.

Following normal group policy processing rules (assuming all policies apply to Authenticated Users with no WMI filters or "Block Inheritance" or "Enforced" policies), user settings of Group Policy objects apply in the following order:

Local Computer Group Policy
Group Policies linked to the Site
Group Policies linked to the Domain (contoso.com)
Group Policies linked to OU "A"
Group Policies linked to OU "B"
Group Policies linked to OU "E"

That’s pretty straightforward, right? Now, let’s move on to loopback processing!

What is loopback processing?

Group Policy loopback is a computer configuration setting that enables different Group Policy user settings to apply based upon the computer from which logon occurs.

Breaking this down a little more:

It is a computer configuration setting. (Remember this for later)
When enabled, user settings from GPOs applied to the computer apply to the logged on user.
Loopback processing changes the list of applicable GPOs and the order in which they apply to a user.

Why would I use loopback processing?

Administrators use loopback processing in kiosk, lab, and Terminal Server environments to provide a consistent user experience across all computers regardless of the GPOs linked to user's OU.

Our recommendation for loopback is similar to our recommendations for WMI filters, Block Inheritance and policy Enforcement; use them sparingly. All of these configuration options modify the default processing of policy and thus make your environment more complex to troubleshoot and maintain. As I've mentioned in other posts, whenever possible, keep your designs as simple as possible. You will save yourself countless nights/weekends/holidays in the office because will you be able to identify configuration issues more quickly and easily.

How to configure loopback processing

The loopback setting is located under Computer Configuration/Administrative Templates/System/Group Policy in the Group Policy Management Editor (GPME).

Use the policy setting Configure user Group Policy loopback processing mode to configure loopback in Windows 8 and Windows Server 2012 . Earlier versions of Windows have the same policy setting under the name User Group Policy loopback processing mode. The screenshot below is from the Windows 8 version of the GPME.

When you enable loopback processing, you also have to select the desired mode. There are two modes for loopback processing: Merge or Replace.

Loopback Merge vs. Replace

Prior to the start of user policy processing, the Group Policy engine checks to see if loopback is enabled and, if so, in which mode.

We'll start off with an explanation of Merge mode since it builds on our existing knowledge of user policy processing.

Loopback Merge

During loopback processing in merge mode, user GPOs process first (exactly as they do during normal policy processing), but with an additional step. Following normal user policy processing the Group Policy engine applies user settings from GPOs linked to the computer's OU. The result-- the user receives all user settings from GPOs applied to the user and all user settings from GPOs applied to the computer. The user settings from the computer’s GPOs win any conflicts since they apply last.

To illustrate loopback merge processing and conflict resolution, let’s use a simple chart. The chart shows us the “winning” configuration in each of three scenarios:

The same user policy setting is configured in GPOs linked to the user and the computer
The user policy setting is only configured in a GPO linked to the user’s OU
The user policy setting is only configured in a GPO linked to the computer’s OU

Now, going back to our original example, loopback processing in Merge mode applies user settings from GPOs linked to the user’s OU followed by user settings from GPOs linked to the computer’s OU.

GPOs for the user in OU ”E” apply in the following order (the first part is identical to normal user policy processing from our original example):

Local Group Policy
Group Policy objects linked to the Site
Group Policy objects linked to the Domain
Group Policy objects linked to OU "A"
Group Policy objects linked to OU "B"
Group Policy objects linked to OU "E"
Group Policy objects linked to the Site
Group Policy objects linked to the Domain
Group Policy objects linked to OU "A"
Group Policy objects linked to OU "C"
Group Policy objects linked to OU "G"

Loopback Replace

Loopback replace is much easier. During loopback processing in replace mode, the user settings applied to the computer “replace” those applied to the user. In actuality, the Group Policy service skips the GPOs linked to the user’s OU. Group Policy effectively processes as if user object was in the OU of the computer rather than its current OU.

The chart for loopback processing in replace mode shows that settings “1” and “2” do not apply since all user settings linked to the user’s OU are skipped when loopback is configured in replace mode.

Returning to our example of the user in the “E” OU, loopback processing in replace mode skips normal user policy processing and only applies user settings from GPOs linked to the computer.

The resulting processing order is:

Local Group Policy
Group Policy objects linked to the Site
Group Policy objects linked to the Domain
Group Policy objects linked to OU "A"
Group Policy objects linked to OU "C"
Group Policy objects linked to OU "G"

Recap

User Group Policy loopback processing is a computer configuration setting.
- Loopback processing is not specific to the GPO in which it is configured. If we think back to what an Administrative Template policy is, we know it is just configuring a registry value. In the case of the loopback policy processing setting, once this registry setting is configured, the order and scope of user group policy processing for all users logging on to the computer is modified per the mode chosen: Merge or Replace.
Merge mode applies GPOs linked to the user object first, followed by GPOs with user settings linked to the computer object.
- The order of processing determines the precedence. GPOs with users settings linked to the computer object apply last and therefore have a higher precedence than those linked to the user object.
- Use merge mode in scenarios where you need users to receive the settings they normally receive, but you want to customize or make changes to those settings when they logon to specific computers.
Replace mode completely skips Group Policy objects linked in the path of the user and only applies user settings in GPOs linked in the path of the computer. Use replace mode when you need to disregard all GPOs that are linked in the path of the user object.

Those are the basics of user group policy loopback processing. In my next post, I'll cover the troubleshooting process when loopback is enabled.

Kim “Why does it say paper jam, when there is no paper jam!?” Nichols

Comments

Anonymous
February 08, 2013
Very good blog Kim and it is going to get a lot of hits because like you said it still causes confusion. I use a very clear name that includes the word loopback on any GPO with it enabled to help admins behind me figure out what is going on a bit faster/easier. I'm officially old #LSDOU The guys over at CB5 also had a great series on Loopback that people should checkout cbfive.com/blog Thanks Mike
Anonymous
February 08, 2013
The comment has been removed
Anonymous
February 08, 2013
Another great post Kim!! #waiting4partdeux
Anonymous
February 10, 2013
Thx for this Blog. I agree many Admins are still confused when they use loopback. One of the main confusions is the first Point of your recap. Once loopback is enabled it is not only for this one policy. it is enabled for the Computer and so for every policy where user configuration is configured and hits the Computer! (Because of this i don't realy understand why i should use the Name loopback in a policy. i can imagine that this make the confusion in this direction bigger) The second biggest confusion i hear often is that the user still Needs 'apply gpo' rights on the policy which is linked to the 'loopback enabled' Computer. There are so many admins who don't understand that even if the policy is linked to a Computer it is still user configuration that must apply and so the user needs to be authorized to apply the user configuration. looking Forward to your next post!
Anonymous
February 10, 2013
Excellent Post Kim! It is easy to understand with the screenshots. However, having a little difficulty when i try to relate with my scenario. Can you kindly help me with this question, I have a set of kiosks in an seperate OU. All users have some IE settings configured in their user portions of GPO. If i want to apply different IE settings for these users if they logon to these kiosks,Can i create a GPO with different IE settings under user configuration and link to the Kiosks machines(security filtering would be left with authenticated users) OU so that I dont need to use loopback processing. Anyways,only GPO which is recently applied Wins,so can i consider this? also, you mentioned that enable loopback processing on GPO. At which place should we enable this? At GPO where we want to restrict this? Thanks for your time.
Anonymous
February 11, 2013
Thanks for this post, very good timing for me as I was starting to be a bit rusty with this topic.
Anonymous
February 11, 2013
Good post. I really do wish there was a configurable option, though, to make loopback only apply user settings in the policy where the user settings are defined. I understand that is not the current behavior, but it required a dramatic reorganization of our OU structure for GP linking because some of our users sometimes met multiple, distinct user settings with loopback. We are K-12 and have students who may have classes in multiple lab environments with user settings specific to each room.
Anonymous
February 11, 2013
Great explanation Kim! One additional to note about loopback merge mode, is that, depending upon where GPOs are linked (esp. when you have a lot of user settings linked at the domain level) you may find policies processing twice (once for the "normal" user object settings and once for the computer object that the user is logged into). This can result in odd visible behavior like logon scripts running twice and unwanted non-visible behavior like user GP processing taking longer. Just something to keep in mind if you use merge mode. It almost requires think "10 steps ahead" to ensure that when you turn on loopback, you understand your full GP deployment. Darren
Anonymous
February 11, 2013
Thanks for all the comments. You all make very good points (some of which I was going to cover in Part 2 :-P). @baschuel - You are correct. The single biggest misconception I see in Support is the belief that Loopback only affects the Group Policy Object in which it is configured. This just isn't the case. We are setting a registry key on the computer and it tells the Group Policy Engine how to process user policy. Once loopback is enable the rules for user policy processing are changed and ANY GPO in the path of the computer which includes user settings will have those settings applied to the logged on user. As for why include Loopback in the name. This is just for discoverability. When an Admin is looking at the GPMC UI, they can easily see that a Loopback policy is applied and at which level it is applied. Also, on your GPResult report you will see a GPO named "Loopback-Replace/Merge" being applied. This makes it very obvious without digging through the settings report looking for the actual setting. This, of course, isn't a requirement. It is just something that can make troubleshooting a little quicker.
Anonymous
February 11, 2013
@Server Engineer - Yes and No. Yes - You can create a GPO with IE user settings and apply that to the kiosk computers. No -If you link the GPO to the OU containing the computers, then you must configure the loopback setting unless, of course, your computers and users are in the same OU. As for where you configure the loopback setting. This can be done in any Group Policy Object that applies to the kiosk computers. As I mention above, my preference is to create a GPO with ONLY the loopback setting and name it something very obvious. Then you would create a separate GPO for the user settings you want applied in Loopback mode. Alternatively, you can create one GPO with both the loopback setting and the IE user settings you want applied in loopback mode. I'll talk about the advantages/disadvantages of both in my next post. @gallwapa - I'd have to see your OU structure to fully understand, I'm sure. But, as you noted, there is no way to accommodate your scenario with the way loopback works. Since it is a computer-wide setting, once the computer is in loopback mode, it is going to apply all of the user settings in the path of the computer regardless of which GPO they are in or where they are linked. Loopback can get highly complex when your OU structure isn't conducive to using it. When this happens, you can get into things like WMI filtering and security group filtering, all of which I recommend avoiding if you can help it. If the set up is overly complex, perhaps it is worth taking a second look at your OU structure if loopback is something you can't get away from. @Darren Mar-Elia – Thanks, Darren. Your point is a good one (planned for Part 2, but I’ll comment anyway). To illustrate your point, typically there are user settings in your Default Domain Policy. Your Default Domain Policy is typically linked at the Domain level and applies to computers and users. In this scenario with loopback merge. The Default Domain Policy will be applied to the logged on user twice. I totally agree, loopback can have unintended and undesirable consequences. This is something that is very important to understand before you start using it. Again, I think it is best to avoid all together if you can help it. But, if you have to use it, definitely set up a comparable test environment and run through the scenarios before deploying in production. Better to be safe than sorry.
Anonymous
February 11, 2013
We had something like dom |-ComputersOU |--Site |---StudentComputers |-UsersOU |-Students Now we have dom |-ComputersOU |--Site |---StudentComputers |----Labs |-----LabName |-UsersOU |-Students And we only apply settings that might conflict at Labname.
Anonymous
February 13, 2013
Thanks again for Explanations Kim! Awaiting for Part 2 ! :)
Anonymous
February 14, 2013
Thanks for the good illustration, Kim! While I think the loopback basics are more or less easy to understand after you have set up some test scenarios, the confusion starts when combining it with security filtering (apply, deny, or both) and having mixed GPO's with User and Computer Settings in it. Therefore I agree with you: Keep your design as simple as possible. Besides, there is one more pitfall: the change in loop back processing (merge mode only) introduced with Vista / Server 2008 which is not documented well. Up to now support.microsoft.com/.../EN-US is very misleading. I know the article is currently under revision, but maybe you can cover this changed behavior and its consequences in part 2 of your blog topic. Patrick
Anonymous
February 18, 2013
Kim, Thanks a lot for taking time to explain Group Policy Loopback processing. I've learned somthing new today. Thanks to YOU.
Anonymous
February 22, 2013
How are extensions such as Group Policy Preferences handled when loopback is in REPLACE mode?
Anonymous
February 28, 2013
Glad to have this as a post to refer people to as I still see a lot of people not understanding this, especially the part about loopback processing affecting all GPOs and not just the one it is enabled in. One thing that I think is worth clarifying (as it tripped me up when I first started working with loopback processing) is that when the computer processes user based GPOs due to loopback processing being enabled it does it in the logged on user's security context and not the computer's security context (i.e. Local System) as would normally be the case with computer policies. So you can still use security filtering and ACLs on the GPO to limit which users get a specific GPO applied even when that GPO is being applied via the computer using loopback processing.
Anonymous
March 01, 2013
@gallwapa - Loopback replace doesn't have any effect on the processing of the client side extensions. All loopback is doing is changing the list of GPOs that are applied to the user at logon (based on the location in AD of the computer rather than the user). Once the list is obtained, processing continues normally. The only exception to this is when you are working with cross-forest group policy processing. When cross-forest policy processing is enabled, by default processing reverts to loopback replace mode. This means that user policies that are applied will come from the any GPOs in the path of the computer in the computer's domain (not the users). Things become more complicated at this point because while the GP Engine understands how to query across forests, not all client side extensions do. One extension that we are aware of that has issues with querying across forests is GPP drive maps. So in a cross-forest scenario, some CSEs may not process properly or completely.
Anonymous
March 06, 2013
Thanks for the refresher. One thing I was hoping you can confirm for me is that if you have multiple policies containing user configuration settings linked to the same computer OU, only one policy linked to that OU needs to have the loopback setting configured. In that case, all user settings from all policies linked to that OU will apply to the logged on user. Doug
Anonymous
March 10, 2013
Kim, thanks for the heads-up about Cross-forest GP processing. Just in time to avert major disruptions @ work. We're currently in a migration process, running a new forest with users still in the old forest. Unfortunately the admins in the old forest have a tendency to implement unannounced untested user GPO's which we then have to work around again or even negate.
Anonymous
March 11, 2013
PLEEEEEEEEEEEEEEEEEEEEEEEESE! Can you (and all Microsoft bloggers) never EVER use jpeg format for screenshots. The images are bad and blurry and the files are bigger. Only use PNG for screenshots (and anything other than photos), please.
Anonymous
March 11, 2013
@Fduch Thank you for that feedback. I'll use .PNGs for our upcoming blog post this week. --Jonathan
Anonymous
April 09, 2013
+1 to gotsch-it question. Can you clarify security filter processing behavior with loopback mode enable? An article (support.microsoft.com/.../EN-US) is pretty confusing.
Anonymous
April 11, 2013
FYI - Part 2 is on the way, but I wanted to let you know that the infamous Vista loopback KB has been updated and is hopefully a little less terrible that it once was :-P support.microsoft.com/.../en-us
Anonymous
May 19, 2014
Pingback from Loopback processing recommendations | Secure Identity

다음을 통해 공유