Group Policy not applying

You've definitely done something additional to your working policy. User policies will only apply to user objects. Item-level targeting does not change this fundamental behavior and if a security group only has computer objects, it will filter out everything and not apply. You basically created a target that is effectively zero members.

I believe this setup is a common practice in order to assign a specific printer to a particular computer or group of computers based on location.  This way, it does not matter who logs onto the computer, they always get the same printer assigned.  Seeing as how we have roaming profiles and several sites, this makes sense to me.  Please refer to this article on setting this up through the user side with ILT:

http://deployhappiness.com/deploying-printers-with-group-policy-preferences/

Thanks

Loopback processing indeed is commonly used, yes. But even with loop back processing, it is being applied to a user object at logon. The loop back is just changing the scope of the OU. Since the actual object is still a user, ILT (or security filters or WMI filters for that matter) must still account for the processing happening for a user object and its memberships. The policy, as described, does not and thus not applying is expected behavior.

Cliff,

Okay, if you wanted a particular printer assigned to a specific computer/computers regardless of who logs on, what would you do?

Thanks,

Well, unless there is something missing from that simple specification, create a group policy. Link it to a computer OU. Add the printer as a preference under computer settings.  No ILT. No changes in security or WMI filters.  Nothing special at all.  Every computer in the OU gets the printer on boot-up and it is presented to the user when they log in.

I see that "Shared Printer" is not an option via the computer side GPP?  Would there be some workaround for deploying a shared printer through the computer side of things?

Thanks

Cliff,

So, instead of linking the policy to the Users OU, it would be linked to the Computers OU?  Hmmm...I think we might be onto something here.  But, I would still use the User side preferences to set the printer?

Correct. And correct.and loop back processing MUST be on or user settings will not get processed. And what I've said earlier about using security groups, either as a security filter or as an ILT still applies. You can set a bad filter and end up with a resulting zero-set. So don't do that if you don't need to, and understand the ramifications.

Please explain the ramifications of a zero-set policy.  I must use ILT as I don't want the entire computer OU to receive the printer in question.  You have been a big help as it appears I was barking up the wrong tree here.  I am not sure how I misinterpreted this procedure though?  Seeing as how it works with my test GPP?  Anyway, I will give this a try and post the results.  Once again, thank you for your help.

Thanks,

Ramifications?  It wouldn't apply!  Zero-set isn't an IT or technology term. It is a math term.  You have a set of things (marbles.) You filter out blue marbles. Then you filter out red marbles. Then you filter out green marbles.  If you end up with a set of zero things and said "dump all the remain marbles in the bucket" you'd dump zero marbles in the bucket. You filtered them all.

If you set a user policy and and then try to use ILT with a computer filter, you will end up filtering out everything because the policy is applied to users, not computers.  You will end up with a set of zero things so the policy will simply not apply.

The easiest way to control the computers it applies to is to further break down your OUs.  It is *usually* a good sign your OU structure is bad when you are trying to do things that require too many other filters.

Another option is to use a security filter (on the policy, not as an ILT) and include just the computers and all the users you want.  The security filter will prevent the loopback setting from being applied to any of the unwanted computers so loopback processing won't kick in.  But for the ones that make that cut, the user policy still kicks in and no filters block the user application.  Again, understanding when and *how* policies are applied to objects is key to making this work properly.

Does the computer I am targeting for the printer install have to be in the computer OU that the policy is linked to?  I am thinking yes.  What about the ILT?

YEs for the OU.  If you are setting a user setting, ILT with computers won't matter.  You can add them, but they'll never match.   Going back to my zero-set analogy.  I have marbles and rocks.  I've separated them into two groups.  I then tell someone to pick up the pile of rocks and set aside any red marbles and any blue rocks.  Well...the red marbles filter will *never* apply so it is worthless telling someone to do that.  You may still get matches (the blue rocks) because you set multiple filters, but that doesn't make the computer ILT any more valid.  User settings...user filters.   Full stop.   ALWAYS.

Also, do we need a logoff/logon to apply this setting?  Or will gpupdate do the trick?

That depends on how you mean the question.

Technically all policies are "applied" when you run a gpupdate.  However some will not have any effect until a logoff/logon.  It is a nuanced, but important, distinction.  Printer preferences are, I believe, processed during the group policy update and do not require a logon to trigger.

I just configured a new GPP.  Linked it to the computer OU that my computer is a member of.  I then enabled loopback processing.  I then set a user side printer preference to install a shared printer with the "Create" parameter.  I only want this printer to be installed on my computer, so how would I accomplish that?  Because as you've so kindly pointed out, ILT to a security group that my computer is a member of does not work?

Make a security group with yourself and your computer as a member and remove "authenticated users" from the group policy security filter and add that group.  Note I am *not* talking about ILT at all.  On the policy itself, there is the OUs it is linked to. The security filter (defaults to authenticated users), and the WMI filter (no default filter applies here.)  

By removing the default security filter and applying your custom one, you are filtering *before* the policy is read, not after, which is extremely important when understanding precedence.

Cliff,

Okay, I will try this again.  Your comments are greatly appreciated.  I'll check back tomorrow.

Thanks,
Mike

Works beautifully.  Thank you.