Group Policy Preferences + Preference Item-Level Targeting + Security Groups = One Big Mess

Microsoft. While Group Policy Preferences, when they work, work wonders, when they do not work or the UI breaks them, I lose all confidence.

USE CASE: we recently deployed PaperCut across our multi-function printers (MFPs). [PaperCut, BTW, is an excellent product, especially for Healthcare and HIPAA compliant environments.] Globally I pushed the default, PaperCut virtual printer to all PCs. Users can print to the virtual and then then fetch their print jobs securely on any MFP across campus running the PaperCut embedded application.

However, we had certain user AND computer exceptions to the default printer; e.g. local USB printers or Terminal Services/RemoteApp servers. Loopback merging can get complex rather quickly (another good, quick refresher here). Group Policy Preferences Item-Level Targeting is a better solution. Read about it here from Microsoft directly.

In my default printer example, the intent is to exclude users and computers. To make it easy to manage, I created a Security Group name “PaperCut-NonDefault” that contained both users and computers I wanted to exclude. I then set “Targeting…” on the PaperCut preference.
PaperCut-Printer

In the Targeting Editor I created the following logic:PaperCut-Targeting

Now, up until this point, every seemed very straight-forward and yet the Targeting refused to work properly. If I added the users and computers directly into the Targeting Editor, I was able to get it working perfectly. The moment I used a Security Group, everything broke.

After sleeping on the problem, I finally came across this wonderful post. In short, do not use the “…” button to select your Security Group. Re-read that. In other words, do not use the DOMAIN\SECURITY_GROUP convention; just use the Security Group name only (as I have highlighted in the screenshot above). Based on the comments it appears that Microsoft has a hotfix which may solve the issue but I chose to fix it by dropping the “DOMAIN\”. Also note that I have two “Items” both calling the “PaperCut-NonDefault” Security Group. Targeting Security Group “Items” can only apply to either a computer or user; not both in one item. By having two items, I have one for users, one for computers.

With this subtle but critical change in place, the default printer Targeting works very effectively excluding certain users and computers. To make it even easier for our users, I added a second printer preference that ONLY applied to those in the “PaperCut-NonDefault” group which adds the PaperCut printer but does not set it as default. In other words, even users who do not want PaperCut as their default printer, they still get the PaperCut printer as an option.PaperCut-Targeting-NonDefault

Enjoy. When Targeting works, its effective and powerful. Here are 10 things Group Policy Preferences can do better than your current script!

3 thoughts on “Group Policy Preferences + Preference Item-Level Targeting + Security Groups = One Big Mess”

  1. I love you! I have been pulling my hair out of 3 days with this issue. For me it was even worse. DOMAIN\Group would work fine in Windows 7, but not Windows 10. As soon as a removed DOMAIN from the targeting logic everything started working in both 7 and 10. Thank you thank you thank you!!

    1. Thanks for this! Actually, I had several shortcut items assigned, and only one would work! I then selected them all through the search function. They all started working when I removed the domain.

Leave a Reply

Your email address will not be published. Required fields are marked *