Group Policy Exemptions using filters

I have set a policy to enforce screensaver with a lockout after 7 minutes prompting for password. I have found that there are a few machines as exemptions. I have made another policy to disable the screensaver for devices that are part of a particular group. I have set a loopback also because the screensaver policy is on the user group policy but I want it applied on a per computer basis. So using filtering I have made it so that the group policy is applied to all users except if you are on one of the "exempt" machines. I run gpresult on the machine and it is getting the correct policies applied however the policy to get the screensaver is applied first which is then preventing the disabled setting for screensaver from running. Is there a way to let the computer policy run before user policy? if so how and is there a better way to do this?

Solution 1:

What Izzy says is fine, if you only needed computer policy. What you are looking for is loopback group policy processing.

Screensaver-related policy settings are user policy settings, so you need to enable loopback group policy processing (Computer Settings - Administrative Templates - System - Group Policy - User Group Policy loopback processing mode) for "Merge" mode (to allow your existing user settings to continue to apply) in a new or existing GPO that already applies to the computers that need "exemption" from the otherwise universal screensaver settings. If you only want this "exemption" to apply to a subset of computers under the OU where the GPO is linked, create a security group containing those computers, add it with permission to "Read" and "Apply Group Policy" to the GPO containing this loopback group policy processing, remove "Authenticated Users" from the permission, and add "Domain Users" (more below) with "Read" and "Apply Group Policy" permission if needed.

Once you've done that, you'll need to set necessary policy settings to "disable" the screensaver settings. Those are user settings, and you can put them into the same GPO where you turned on loopback group policy processing. If you do use the same GPO that sets the loopback group policy processing setting and you've filtered that GPO's application to a security group be sure to add "Domain Users" with "Read" and "Apply Group Policy" permission to that GPO, since the actual application of the user settings happens in the context of the logged-on user, not the computer.

Reboot one of the "exempt" computers and try it out.

When these "exempt" computers are booted they will apply the GPO that enables loopback group policy processing in "merge mode". This means, effectively, that after all the normal user GPO settings apply, a second pass over domain is made, looking for GPOs that contain user settings but that apply to the computer object's location in the directory (think of loopback policy processing "merge mode" as "magically" putting a copy of the user object into the same container as the computer during logon, thereby targeting any user settings in GPOs above the computer to the user, too).

Chances are you're not already using loopback group policy processing so this very simplistic method I've described above will work fine. If you are already using loopback GPO processing then filtering by security group for the "exempt" computers becomes problematic (and beyond what I'm willing to describe in this answer). If you're there already, you should already know how to do what you're trying to do... >smile<

Obviously, I'd recommend reading up in loopback group policy processing and running some tests with a scratch computer in a test OU before you do this to your production computers / OUs. This is one of those cases where understanding the algorithm that the Group Policy client uses to select the policies that apply to the user / computer, rather than just relying on tools like GPMC "planning mode" is a huge win. I'd direct you to an article from Microsoft, but they've got nothing that doesn't suck (i.e. talks about "priority" of GPOs and other such silliness, rather than just explaining the algorithm in detail... >sigh<).

Someday (NOT today, Kyle! I don't have time today...) I'll write up a description of the algorithm for Server Fault.

Solution 2:

A neater way to do this is to apply the screensaver policy only to machines that should have it. It's better than applying the policy to everything, then trying to undo some of it.

You'd do this by filtering the GPO by security group (eg. Screensaver Enabled), and then making all the machines that should have the screensaver GPO a member of the Screensaver Enabled group.

With so few objects not requiring the GPO, create a security group called Screensaver Disabled, make the target computers a member of this group, edit the security of the Screensaver GPO, add the group Screensaver Disabled, and select the Deny for the Apply Group Policy permission.