Just deciding to turn on loopback everywhere, without thinking about where your existing user setting GPOs are linked is a recipe for disaster. That said, for this kind of scenario, it still requires planning. 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. Not a great solution in many cases because accidental targeting becomes a real challenge. 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. 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. Well, one scenario where Loopback Everywhere makes sense, might be the following. So what are the reasons why you might consider doing Loopback Everywhere? When It Makes Sense 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.Īdd 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. 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. 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. 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 imagine a user in the Marketing OU, logging into a loopback merge enabled VDI instance. The Downside of Loopback Everywhereįor example, imagine a GPO, linked at the domain level, that contains a logon script that all users in the domain run. 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. Now, when I first saw this, my initial reaction was, “Uh-oh”. However, occasionally in the past and in this recent customer discussion, I have encountered environments that have loopback enabled on ALL of their workstations. 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. If there are conflicts, then the computer-object-linked GPO user settings override the user’s normal settings, while logged into that computer. 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.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.Just to review, the way loopback works is different, depending upon whether you choose Replace or Merge, as follows: Enabling loopback processing on a computer
0 Comments
Leave a Reply. |