A test environment is the best place to do this type of investigation.
Once you determine this, then you can add your WMI filters back into the equation. The goal is to ensure the policies you are expecting to apply are actually applying. You may want to consider temporarily unlinking any WMI filters for troubleshooting purposes. As a general rule, you should try to keep your WMI and security filtering as simple as possible - but ESPECIALLY when loopback is involved. If you are configuring custom security filtering on your GPOs, loopback can get confusing quickly. Loopback processing issues usually come down to incorrect security filtering Once you determine which GPOs or which settings are not applying as expected, then you have a place to start your investigation. 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). However, in a production environment with potentially multiple delegated GPO admins, this is much more difficult. In a lab environment where you control everything, it's pretty easy to keep track of desired configuration. 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 a good indication that we have loopback enabled in a GPO linked in the path of the computer account.
Notice that the link location includes the Computers OU, but we are in the User Details section of the report.
Loopback test windows#
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. Look for GPOs linked to computer OUs under theĬommand from a Windows Server 2012 member server. Output can also help you find GPOs containing user settings that are linked to computer OUs.
If your OU structure separates users from computers, the Unfortunately, it does not list all GPOs with loopback configured, just the one with the highest precedence. Output will show you the winning GPO with loopback enabled. Since loopback is a computer configuration setting, you will need to run GPResult from an administrative command prompt. The easiest way to know if loopback might be causing troubles with your policy processing is to collect a The Group Policy engine reads this value and changes how it builds the list of applicable user policies based on the selected loopback mode. Loopback processing is aĮveryone feels better now, right? The loopback setting configures a registry value on the computer to which it applies. Take a deep cleansing breath and say it again. 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. The first step in troubleshooting loopback is to know that it is enabled. Know if loopback is enabled and in which mode Is the loopback setting configured in the same GPO or a separate GPO from the user settings?Īre the user settings configured in a GPO with computer settings? The security filtering requirements when using loopback To whom should the settings apply or not apply? Which settings from which GPOs are "supposed" to be applied? the actual state configuration of applied policy The status of the loopback configuration. To troubleshoot loopback processing you need to know and understand: 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).
Now, we're going to go into a little more detail to help you identify and troubleshoot Group Policy issues related to loopback processing. In my first post, the goal was to keep it simple. For those of you joining us a little late in the game, you'll want to check out Thanks for all the comments and feedback on Part 1. Here once again with the much anticipated Part 2 to First published on TechNet on May 21, 2013
0 kommentar(er)
