So, I have a GPO, which runs a quick start up script to delete locally installed IP printers from all machines on our AD domain during computer start up. This works great...the issue appears when we try to exempt a few machines from this (a few small offices without print servers.)
I have created a global security group, and put the computer accounts (since this is a startup, not a login script) into the group. I then set permissions on the GPO to deny access to that group. For some reason, this has no effect. It also has no effect if I set deny permissions for that group on the script itself.
Interestingly, though, if I cut out the group, and set deny permissions on the GPO or script for the computer account directly, permissions are denied properly.
These issues persist across multiple "gpupdate /force" commands, as well as reboots.
Am I missing something about how computer accounts group group sids? Why are the group based deny permissions not working?
Group Policy Filtering: You're doing it wrong (or at the very least you're doing it the hard way).
Create a Security group for the computers that you DO want the policy to apply to.
Add the appropriate computer accounts to the group.
On the Scope tab of the GPO, in the Security Filtering section, remove all entities and add the Security group you created in step 1.
Done.
I do what you're looking at doing all the time. When you say "I then set permissions on the GPO to deny access to that group" it's not clear what you're doing. Here's my workflow for denying a group the rights to apply a GPO:
The permission editor within the Group Policy Management console is inferior to the Group Policy Object Editor. You don't see the actual ACL in Group Policy Management unless you click the "Advanced" button on the "Delegation" tab. I'm "old school" and got used to modifying GPO permissions back in the days before the Group Policy Management console, so I still go about it the way I described above. Now get off my lawn! >smile<
If you're concerned that the computer isn't "picking up" its group memberships execute a "whoami /all" as SYSTEM on the machine and review the output. That'll show you what the computer's security token actually includes. I have not had experiences with computers not "recognizing" group memberships.
I am not really sure, because I have no way to test here, but as far i remember you will not be able to put computers in groups and deny the group. You should put each computer and deny each one....
Maybe you can find something using GPP.