I was on a call with a colleague and friend of mine Paddy McHale. We were walking a new PowerBroker Desktops (PBD) customer through some initial planning and setup. Being a Group Policy Extension quite commonly the topic of how many GPOs are required to maintain this software frequently comes up. Specifically, should a company maintain all PBD policies in one or two GPOs, or should they be separated into several GPOs; commonly referred to as Monolithic and Functional GPOs. It was at this point Paddy simply said, "Does this GPO make me look fat?". After I picked myself up off the floor and iced my ribs, I thought about this more. As humorous as the question was, it actually sums up what folks that are new to the product have to consider; how do I limit GPO Bloat and Group Policy refresh times in my enterprise while implementing this software? Keep in mind the purpose of PBD is to manage the privileges of an application, regardless of what rights the logged on user has. It needs to perform this task without negatively impacting the user experience or an admin's already taxed resources.
Ultimately the choice is yours, and the school of thought you're most familiar with. Our best practice suggestion, and that of popular thought, is it's always best to maintain the least amount of separate GPOs you can. While there are reasons, and in many cases current native GPO functionality that necessitates a higher number of GPOs, there are features available within the PBD software you may not be aware of that will help keep your GPO count down with your PBD rollout.
Item-Level Targeting (ILT):
Similar to what exists within MS Group Policy Preferences, you can assign specific policies or groups of policies to a subset of who the GPO is linked too. As an example, let's say you link a GPO at an OU called 'USERS', and under this OU you create Sub-OUs that relate to various geographic regions or roles within your organization. By default any of the PBD policies under User Configuration would apply to every User in the USERS OU and any Sub-OU. There is some functionality at the GPMC level to adjust this, but it's limited. With Item-Level Targeting you can assign a policy to only apply to a User if they are in a particular security group, on a specific computer or computer security group, apply only if a specific application is installed, have particular hardware installed, or any combination of these and 20+ other targeting criteria.
Collections:
Collections allow you to combine policies into logical groupings. Think of these the same way you would an OU or Security Group, but managed within a single GPO rather than a global AD setting. Commonly collections are used to group policies from a particular vendor, (Adobe, Java, etc.). It helps when you want to go back and edit or view rules affecting the respective vendors software. You can also use Collections based on roles, (Developer, Marketing, Retail). In other words, you would create policies that only Users or Computers responsible for this role would require. By doing so you can assign Item-Level Targeting criteria to the group of policies, rather than assigning the same Filtering to each policy within the Collection.
Collections can also be used to enforce a specific action, meaning instead of having to assign the same settings to fifty different applications that simply allow it the appropriate privileges or deny it from running, you can assign this behavior at the Collection level and any policy in that collection takes on that action. Both this and ILT at the collection level will save you time when creating policies, as well as when you need to edit the GPO.
By utilizing these two features within PBD, you can see how the need to separate policies that target different applications or different groups of users is not required. You can successfully implement a Least Privilege solution and keep your GPO on a diet. In other words, you can have your cake and eat it too, we're just making sure the cake is apple sauce, diet coke and sugar substitute rather than eggs, oil and the real stuff.
