Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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 '11 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 '11 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 '11 at 2:36
add comment

3 Answers

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).

share|improve this answer
    
Hmmph!! 22 seconds. Dag-gone-it!! –  joeqwerty Nov 9 '11 at 0:16
    
@joeqwerty Several times now that we've done that! Yours is longer though :) –  Shane Madden Nov 9 '11 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 '11 at 0:20
    
@joeqwerty Well, I certainly would have had it coming. –  Shane Madden Nov 9 '11 at 0:21
    
Thanks, loopback processing is enabled. I've updated my question. –  Matt Nov 9 '11 at 0:31
show 4 more comments

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.

share|improve this answer
    
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 '11 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 '11 at 1:09
add comment
up vote 0 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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