Welcome back! Kim Nichols here once again with the much anticipated Part 2 to Circle Back to Loopback . Thanks for all the comments and feedback on Part 1. For those of you joining us a little late in the game, you'll want to check out Part 1: Circle Back to Loopback before reading further.
In my first post, the goal was to keep it simple. Now, we're going to go into a little more detail to help you identify and troubleshoot Group Policy issues related to loopback processing. If you follow these steps, you should be able to apply what you've learned to any loopback scenario that you may run into (assuming that the environment is healthy and there are no other policy infrastructure issues).
To troubleshoot loopback processing you need to know and understand:
Know if loopback is enabled and in which mode
The first step in troubleshooting loopback is to know that it is enabled. It seems pretty obvious, I know, but often loopback is enabled by one administrator in one GPO without understanding that the setting will impact all computers that apply the GPO. This gets back to Part 1 of this blog . . . loopback processing is a computer configuration setting.
Take a deep cleansing breath and say it again . . . Loopback processing is a computer configuration setting. :-)
Everyone feels better now, right? The loopback setting configures a registry value on the computer to which it applies. The Group Policy engine reads this value and changes how it builds the list of applicable user policies based on the selected loopback mode.
The easiest way to know if loopback might be causing troubles with your policy processing is to collect a GPResult /h from the computer. Since loopback is a computer configuration setting, you will need to run GPResult from an administrative command prompt.
The good news is that the GPResult output will show you the winning GPO with loopback enabled. Unfortunately, it does not list all GPOs with loopback configured, just the one with the highest precedence.
If your OU structure separates users from computers, the GPResult output can also help you find GPOs containing user settings that are linked to computer OUs. Look for GPOs linked to computer OUs under the Applied GPOs section of the User Details of the GPResult output.
Below is an example of the output of the GPResult /h command from a Windows Server 2012 member server. The layout of the report has changed slightly going from Windows Server 2008 to Windows Server 2012, so your results may look different, but the same information is provided by previous versions of the tool. Notice that the link location includes the Computers OU, but we are in the User Details section of the report. This is a good indication that we have loopback enabled in a GPO linked in the path of the computer account.
Understand the desired state vs. the actual state
This one also sounds obvious, but in order to troubleshoot you have to know and understand exactly which settings you are expecting to apply to the user. This is harder than it sounds. In a lab environment where you control everything, it's pretty easy to keep track of desired configuration. However, in a production environment with potentially multiple delegated GPO admins, this is much more difficult.
GPResult gives us the actual state, but if you don't know the desired state at the setting level, then you can't reasonably determine if loopback is configured correctly (meaning you have WMI filters and/or security filtering set properly to achieve your desired configuration).
Review security filtering on GPOs
Once you determine which GPOs or which settings are not applying as expected, then you have a place to start your investigation.
In our experience here in support, loopback processing issues usually come down to incorrect security filtering , so rule that out first.
This is where things get tricky . . . If you are configuring custom security filtering on your GPOs, loopback can get confusing quickly. As a general rule, you should try to keep your WMI and security filtering as simple as possible - but ESPECIALLY when loopback is involved. You may want to consider temporarily unlinking any WMI filters for troubleshooting purposes. The goal is to ensure the policies you are expecting to apply are actually applying. Once you determine this, then you can add your WMI filters back into the equation. A test environment is the best place to do this type of investigation.
Setting up security filtering correctly depends on how you architect your policies:
The thing to keep in mind is that if you have what I would call "mixed use" GPOs, then your security filtering has to accommodate all of those uses. This is only a problem if you remove Authenticated Users from the security filter on the GPO containing the user settings. If you remove Authenticated Users from the security filter, then you have to think through which settings you are configuring, in which GPOs, to be applied to which computers and users, in which loopback mode....
Ouch. That's LOTS of thinking!
So, unless that sounds like loads of fun to you, it’s best to keep WMI and security filtering as simple as possible. I know that you can’t always leave Authenticated Users in place, but try to think of alternative solutions before removing it when loopback is involved.
Now to the part that everyone always asks about once they realize their current filter is wrong – How the heck should I configure the security filter?!
Security filtering requirements:
Merge mode requirements (Vista+):
User account: |
READ
and
APPLY
(these are the default
|
Computer account: |
Minimum of READ permission |
Replace mode requirements:
User account: |
READ
and
APPLY
(these are the default
|
Computer account: |
No permissions are required |
The number one tool for troubleshooting loopback processing is your GPRESULT output and a solid understanding of the security filtering requirements for loopback processing in your GPO architecture (see above).
The GPRESULT will tell you which GPOs applied to the user. If a specific GPO failed to apply, then you need to review the security filtering on that GPO and verify:
The same strategy applies if you have mysterious policy settings applying after configuring loopback and you are not sure know why. Use your GPRESULT output to identify which GPO(s) the policy settings are coming from and then review the security filtering of those GPOs.
The
Group Policy Operational logs
from the computer will also tell you which GPOs were discovered and applied, but this is the same information that you will get
from the
GPRESULT
.
After working my fair share of loopback-related cases, I've collected a list of recommendations for using loopback. This isn’t an official list of "best practices", but rather just some personal recommendations that may make your life easier. ENJOY!
I'll start with what is fast becoming my mantra: Keep it Simple. Pretty much all of my recommendations can come back to this point.
1. Don't use loopback :-)
OK, I know, not realistic. How about this . . . Don't use loopback unless you absolutely have to.
2. Use a separate GPO for the loopback setting; ONLY include the loopback setting in this GPO, and do not include the user settings. Name it Loopback-Merge or Loopback-Replace depending on the mode.
3. Avoid custom security filtering if you can help it.
4. Don't enable loopback in a GPO linked at the domain level!
5. Always test in a representative environment prior to deploying loopback in production.
That’s all folks! You are now ready to go forth and conquer all of those loopback policies!
Kim “1.21 Gigawatts!!” Nichols
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.