Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
I then set permissions on the GPO to deny access to that group. Wait, what? Explain that, please. – HopelessN00b Dec 20 '12 at 23:14
Group policy objects have permissions, just like everything else....see the "Delegation" tab while the GPO is selected...then checkout the "Advanced" button. Works quite well with group filtering for users. – woodsbw Dec 20 '12 at 23:38
Yes, I'm aware of that, but it's not much of an explanation. How do you think you're denying permissions? – HopelessN00b Dec 20 '12 at 23:57
It should (and does, with user polices) prevent the policy from applying to the machines in the group with "denied" permissions...and it is not. – woodsbw Dec 21 '12 at 0:30
What does gpresult /R show? You can update your question with the relevant output. – jscott Dec 21 '12 at 15:22
up vote 4 down vote accepted

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:

  • Create Global Security Group "Computers exempt from printer deletion"
  • Open Group Policy Management, locate the GPO to delete printers, and "Edit" the GPO
  • Right-click the top-level node in the Group Policy Object Editor console, move to the "Security" tab, add the "Computers exempt from printer deletion" to the permission, and set the permission for the "Computers exempt from printer deletion" group to include "Apply Group Policy" with "Deny" permission

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.

share|improve this answer
Great information. The permissions on the GPO ("Delete Local Printers") for the group ("ExemptLocalPrinterDeletion") has deny permissions set for all options (Full Control, Read, Write, Create all child objects, Delete All Child Objects, Apply Group Policy.) The script the GPO runs is sitting in NETLOGON and SYSVOL\<domain>\scripts. Yet, even with correct permissions set, it runs the script. – woodsbw Dec 21 '12 at 21:35
How do I best run whoami as system? I cannot do a simple "runas" to system, can I? – woodsbw Dec 21 '12 at 21:37
@woodsbw: I'm immediately suspicious that the test machine has stopped updating Group Policy for some reason and is using a cached instruction to execute that script. Setting permissions on the script itself would definitely stop the execution. (I frequently assign multiple startup scripts in a single GPO and use permissions on the script files to limit execution. That generates errors in the event log, though, so I can't say it's the best idea.) re: a SYSTEM command promit - Use PSEXEC - psexec -i -s cmd.exe – Evan Anderson Dec 21 '12 at 23:15
I was worried you would mention psexec. I will need to do some modifications to get that working (admin shares totally disabled by policy.) I'll get back to you. – woodsbw Dec 24 '12 at 20:14
Thanks for your help Evan! It looks like everything is now working! – woodsbw Jan 7 '13 at 18:24

Group Policy Filtering: You're doing it wrong (or at the very least you're doing it the hard way).

  1. Create a Security group for the computers that you DO want the policy to apply to.

  2. Add the appropriate computer accounts to the group.

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

  4. Done.

share|improve this answer
I'm going to have to disagree. Groups to exempt from policies make far more sense when you have policies that only a dozen or so of 700 users or machines need to be exempted from. Doing small exemptions the way you suggest would mean that every new user or machine would have to be added to a dozen groups just to get company base-line policy. That being said, this still doesn't address the question at hand...which is the fact that the machine doesn't seem to get it's group memberships correctly on start-up. – woodsbw Dec 21 '12 at 0:31
I'll have to respectfully agree to disagree. Whitelisting (which is what my method is) is more reliable, predictable and easier to troubleshoot then blacklisting (which is what your method is), IMO. – joeqwerty Dec 21 '12 at 0:56
Well, regardless, it doesn't explain why the machine isn't getting it's group memberships? – woodsbw Dec 21 '12 at 5:54
@joeqwerty: I must voice disagreement with you re: "whitelisting" being more "reliable" than blacklisting. ACLs are processed in a deterministic manner. Neither "flavor" will parse more "reliably" than the other and the end result is the same. My issue w/ "whitelisting" versus "blacklisting" is exactly what woodsbw says-- you end up having computers (or users) being members of more groups than they really need to be. My take on this is that the design that ultimately results in the least group memberships is the best because that keeps security tokens smaller for the typical case. – Evan Anderson Dec 21 '12 at 16:25

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.

share|improve this answer
-1 - You absolutely can use groups to deny computers access to objects (GPOs, files, etc). – Evan Anderson Dec 21 '12 at 16:25
Using GPP with item level targeting still isn't a bad idea. – SturdyErde Dec 21 '12 at 18:43
No it is't a bad idea...I love GPP and item-level targeting. But, it won't do the dynamic printer deletions that I need, in this case. A script is the only way to go. – woodsbw Dec 21 '12 at 21:06

Your Answer


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.