Just the other day I was talking to a customer about Group Policy loopback. If you’ll recall, loopback is that feature in Group Policy processing that allows you to override a user’s *normal* user policy settings when they log into specific machines–such as kiosks or Remote Desktop Services/Citix XenApp servers or VDI systems, where it’s mostly commonly used. When a Windows computer has been enabled for loopback–using the following policy found under Computer Configuration\Policies\Administrative Templates\System\Group Policy\User Group Policy Loopback processing mode, you have the option to use either “Replace” or “Merge” loopback.

Enabling loopback processing on a computer

Just to review, the way loopback works is different, depending upon whether you choose Replace or Merge, as follows:

• Replace: When the user logs into a computer enabled for loopback, instead of getting the user policy settings they would normally by virtue of their user account’s location in AD, they get user settings in GPOs that apply to the computer object.
• Merge: When the user logs into a computer enabled for loopback, they first process their “normal” user settings for their user account, then they process any user settings in GPOs that apply to the computer object. If there are conflicts, then the computer-object-linked GPO user settings override the user’s normal settings, while logged into that computer.

Loopback is great for those scenarios I described above, when you have regular users occasionally logging into these specialized machines with their regular user accounts. However, occasionally in the past and in this recent customer discussion, I have encountered environments that have loopback enabled on ALL of their workstations. Now, when I first saw this, my initial reaction was, “Uh-oh”. Loopback processing can add complexity to a Group Policy if it’s not designed well, and making all of your workstations loopback-enabled can cause no end of issues if it’s not planned out.

The Downside of Loopback Everywhere

For example, imagine a GPO, linked at the domain level, that contains a logon script that all users in the domain run. Then imagine a user in the Marketing OU, logging into a loopback merge enabled VDI instance. When they log in, they will first process the user settings for their “normal” user location, which means they’ll run that domain-linked logon script. Then they will process the user settings that apply to the computer object, which also includes that domain-linked GPO with the same logon script. The result? The same logon script runs twice for the user! Now if all workstations in the domain are set to loopback merge mode, this happens every time the user logs on. If you multiply this time all the other settings that apply at the domain level, or any higher level in your AD hierarchy, then suddenly Group Policy processing times increase for no good reason.

Add to that the complexity of having to know which GPOs user settings are applying to a given computer, in addition to regular user settings, and you can quickly envision the mess that “Loopback Everywhere” can cause.

So what are the reasons why you might consider doing Loopback Everywhere?

When It Makes Sense

Well, one scenario where Loopback Everywhere makes sense, might be the following. What if you have an AD structure where all of your users are in a single, flat OU, and you can’t or won’t re-organize them? The normal way we distinguish per-user settings is by linking those GPOs to OUs that are specific to the user type (e.g. Marketing, Sales, Dev, etc.). If you don’t have the luxury of such granularity, then you are forced to rely on something like security group filtering on those GPOs linked to the single user OU. Not a great solution in many cases because accidental targeting becomes a real challenge. So, in those cases, if your workstations ARE segregated by business function, you could rely on Loopback to provide the user settings targeting by virtue of computer location in AD. Totally legitimate!

That said, for this kind of scenario, it still requires planning. Just deciding to turn on loopback everywhere, without thinking about where your existing user setting GPOs are linked is a recipe for disaster. So what I would say is that, while I no longer think its just a bad idea to do this, I think it does require proper planning, and care should be taken to ensure that you know what you’re getting into. Loopback DOES increase the complexity of delivering user settings, so as you go in eyes-wide-open to that, it’s all good!

Darren