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