I have an OU that, including inheritance, has four GPOs applied. There is the default domain policy, linked at the domain level, two more policies with generic settings for our SOE, and finally, a GPO linked to the OU that contains the computers in question.

This last GPO contains some settings that override settings contained in the standard SOE GPO; namely, our standard is to have the screensaver enabled, require UN/PW to unlock, and to automatically start after 300 seconds. The workstations in this OU require the screensaver to be permanently disabled.

Looking in inheritance, the GPO which disables the screensaver has a priority of one. However, the screensaver is still coming on. When I run a results wizard, I see that these settings are being applied and the winning GPO is one of the SOE GPOs, linked at a parent OU and showing a lower precedence in inheritance. None of these GPOs are enforced, no links or GPOs are disabled (in fact other settings from this GPO are being successfully applied).

How do I even begin to troubleshoot this? I'm not seeing any errors, everything appears as it should be.

UPDATE: Sorry should have mentioned this originally. These settings ARE applied to the computers' OU, not the users, and they do have loopback processing enabled. The reason for this is that these workstations must not have the screensaver come on, regardless of who logs on. The same applies to the workstations elsewhere; we can't apply these settings to the user OUs because it's not relevant which user logs on, the location of the workstation is what's important (e.g public area, secure area, area which critically depends on not having the screensaver come on).

UPDATE2: The loopback mode on both GPOs is set to Merge. This is required as there are other GPOs applied to the user OUs which we require.

  • What do you mean that loopback mode is set to Merge in both GPO's? Which GPO's are you referring to? Loopback policy processing should only be configured in the computer OU linked GPO.
    – joeqwerty
    Nov 9, 2011 at 1:23
  • There are four GPOs applied to this OU - one directly and three through inheritance. Two of these contain the screensaver settings, one which enables it at a parent OU, and the one linked to this OU which disables it. Both have loopback processing enabled in Merge mode.
    – Matt
    Nov 9, 2011 at 2:17
  • OK, I've never seen that scenario before and I'm not 100 % sure how it should work, but I believe that the user settings from the two computer GPO's that have loopback configured should still be applied with the same precedence... so I think it should work, but as I said I've never seen that scenario before. My suggestion would be to disable loopback policy processing on the higher level GPO (at the domain or parent OU) and set loopback only in the GPO linked to the computer OU and see if that resolves the problem.
    – joeqwerty
    Nov 9, 2011 at 2:36

3 Answers 3


Screensaver policies are User settings, while you mentioned that the GPO is linked to the OU that the computers are in - the GPO settings in the User tree from that GPO wouldn't apply.

You'd need to enable loopback processing to get the desired result, but be careful with enabling it - it causes a second run of User policy processing against the computer's OU, and those settings take precedence over those that apply to the user's OU (or supplant them completely, if you run in loopback replace mode).

  • Hmmph!! 22 seconds. Dag-gone-it!!
    – joeqwerty
    Nov 9, 2011 at 0:16
  • @joeqwerty Several times now that we've done that! Yours is longer though :) Nov 9, 2011 at 0:17
  • I would make a Michael Scott joke about the last sentence in your comment, but this is a family show.
    – joeqwerty
    Nov 9, 2011 at 0:20
  • @joeqwerty Well, I certainly would have had it coming. Nov 9, 2011 at 0:21
  • Thanks, loopback processing is enabled. I've updated my question.
    – Matt
    Nov 9, 2011 at 0:31

The only screen saver GPO settings I can find are under User Configuration, not Computer Configuration, in which case the GPO needs to be linked to the user OU, not the computer OU unless you're using loopback policy processing in the computer OU GPO (computer settings apply to computers and user settings apply to users that fall within the Scope of Management of the GPO unless you use loopback policy processing to make user settings configured in the GPO linked to the computer OU apply to users logging on to those computers).

Since GP settings are applied to objects in the Scope of Management of the GPO, my assumption is that the GPO that sets the screen saver settings is linked to the domain and therefore the settings are applied by the domain linked GPO, not the computer OU linked GPO, since that's not where the user objects exist.

  • Thanks, loopback processing is enabled. I've updated my question. The GPO with the screensaver settings is not linked to the domain, but to the top level OU which contains all workstations. Under here we have an OU structure that reflects our building layout (more or less), with the GPO that disables the screensaver settings applied at a child OU that represents the department.
    – Matt
    Nov 9, 2011 at 0:31
  • 1
    That's strange because in Merge mode the user settings from the Computer OU linked GPO have a higher precedence than the settings from the user OU linked GPO. I might suggest running gpresults from GPMC to look for any GPO's that have a blocked SOM and to check the settings and see which GPO is winning for setting those settings. You could also run RSOP while logged on to one of the workstations to check the source GPO for the settings, but I think gpresults will give you more info to work with.
    – joeqwerty
    Nov 9, 2011 at 1:09

Occam's Razor. As it turns out, despite protestations to the contrary, the users had not in fact been rebooting their workstations or shutting them down at night. Once this had been done Group Policy was able to update and everything was fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.