This is a question I get all the time, so I thought I'd take a moment and share some thoughts on this question.

Before we get to "What is the right amount of GPOs", let’s start off with "Can I have too many GPOs?"

One of the problems with Group Policy, in general, is that there isn't much "organization" inside the Group Policy Objects node within the GPMC. Simply, you get a flat list of GPO names – listed alphabetically. This isn’t ideal if you have, say, thousands of Group Policy Objects and are looking for one, in particular, needle in a haystack.

So, yes, when I see companies with thousands of GPOs, it’s likely (though not impossible) that means they have “too many GPOs”. If only for the reason that the list is very long and difficult to manage.

But then there’s the flip side to this question: Can I have “too few” GPOs. I’ve seen lots of environments with just this particular problem. Too few GPOs. What does “too few GPOs” look like?

First, it could mean that the organization has decided not to utilize Group Policy – a crying shame considering it has 39 “superpowers” in the box ready to deliver and manage your desktops. However, it also frequently means that administrators have tried to cram too many functions into one Group Policy Object. They’re mixing their policies and their preferences. They’re mixing their user side and their computer sides.

In short, they’re trying to cram as much stuff as they can into as few GPOs as possible. Not a good idea.

So, going back to the question of “What is the right amount of GPOs” – the answer will vary for each environment. However, my suggestion is only to put together items which make sense to be together, and create new GPOs for each unrelated set of items.

For instance, creating one GPO which handles “Firewall settings for Sales” could be 30 different settings inside one GPO. That’s a great use of putting things together (which are similar, and headed to manage the same type of resource).

However, creating a GPO which “Deploys WinZip, deletes U: Drive, and secures c:\Temp” is not a suggested way to have one GPO function. Instead break that GPO into different pieces so it becomes easier to troubleshoot if something goes wrong.

So – I tend to suggest more GPOs over less GPOs. The “penalty” might be slower login times if a client is set to receive lots of GPOs, but in my experience, even lots of GPOs applying to a client doesn’t significantly hinder login performance. As always, be sure to test this in your environment as different configurations could yield different results.

Note, that in no case can a client process more than 999 GPOs before the Group Policy engine gives up and dies.

And that’s definitely too many GPOs.