Group Policy not applying
Hello,
I am testing mapping printers via group policy preferences. I have a test GPP setup that is working flawlessly. I am mapping printers using ILT to a security group with computers in it and loopback processing enabled. This is a test policy only at this point. I created a new GPP with the same basic parameters, but with a different policy name, a different shared printer and a different security group. It is setup identical to the test policy in that it is a user side policy linked to the Users OU, with ILT to a security group with the computer I want the policy assigned to in that group.
Well, it is not working. By that I mean, the printer is not mapped to the assigned computer. I can map the printer through my test policy just fine. But when I enable the second policy, it just does not assign the same printer to the computer?
Is there some type of waiting period on group policy or something? I remember when I first created my test policy, it didn't seem to work at first, then it started working and working as it should? This is really weird to me. This is a Windows 2008 network with Win 7 clients.
Thanks
I am testing mapping printers via group policy preferences. I have a test GPP setup that is working flawlessly. I am mapping printers using ILT to a security group with computers in it and loopback processing enabled. This is a test policy only at this point. I created a new GPP with the same basic parameters, but with a different policy name, a different shared printer and a different security group. It is setup identical to the test policy in that it is a user side policy linked to the Users OU, with ILT to a security group with the computer I want the policy assigned to in that group.
Well, it is not working. By that I mean, the printer is not mapped to the assigned computer. I can map the printer through my test policy just fine. But when I enable the second policy, it just does not assign the same printer to the computer?
Is there some type of waiting period on group policy or something? I remember when I first created my test policy, it didn't seem to work at first, then it started working and working as it should? This is really weird to me. This is a Windows 2008 network with Win 7 clients.
Thanks
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
Thanks
http://deployhappiness.com
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,
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
Thanks
The only difference between a shared printer and a TCP/IP printer is that the shared printer uses a single machine to manage the queue. For small environments this is usually not desirable as one print job can cause the whole queue to stall. Large organizations usually have monitoring software as well as advanced deployment tools where neither the queue freezing is an issue, nor is deploying a shared printer.
But if you really want to, the most common method is to create a policy linked to a computer OU. Turn on loopback processing. Then set the user preference for a shared printer. Loopback processing will ensure that the policy gets applied. And again, no reason to mess with ILT, security filters, or WMI given the conditions you've posed so far. This will work "as is" and will only apply to users logging into computers in the computer OUs the policy is linked to.
But if you really want to, the most common method is to create a policy linked to a computer OU. Turn on loopback processing. Then set the user preference for a shared printer. Loopback processing will ensure that the policy gets applied. And again, no reason to mess with ILT, security filters, or WMI given the conditions you've posed so far. This will work "as is" and will only apply to users logging into computers in the computer OUs the policy is linked to.
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?
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,
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.
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.
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.
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.
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial