Nice easy one, hopefully.
I used to work for a very large company in education who did things a "certain way" - this certain way was to pretty much mirror what RM did for CC3 (and later on, 4) - so GPO modelling on a vanilla setup was pretty much a mirror replacement for the CC3 systems they managed. In a nutshell, this is large single GPs per OU (so for computers in a certain area, they'd have a certain GP applied to them with just about everything else included).
Before I worked in Education (and I'll admit it was easy to switch to working to the above method), I used to abide by the MS method, and even reading up now it appears as if this is still the preferred way; again in a nutshell, a policy was made very nearly per setting, so for instance you could have many many GPO's applied to OUs/security groups/containers such as one to do printer mapping, one to do drive mapping, one to do user security restrictions, one for station security, one for startup scripts, so on and so forth.
The former method is very "clean" however not particularly easy to administer should you need to find a single GPO in one huge lump of settings unless you've gone OCD and documented each setting in each policy. So, what are people's methods here in this day and age? :)
You need to get the right balance. I wouldn't recommend you have 100's of GPOs, but I wouldn't recommend you have one massive GPO either.
For example, I typically have Curric GPO, Staff GPO and MIS GPOs and they're all very similar, but tweaked for that specific user group. These contain a fair few GPO settings which I know won't change at all or will change rarely.
I then for example would create another GPO called Adobe Flash and link this GPO to each required OU. You then only need to edit the GPO once and this can save you a considerable amount of time, as the GPO is linked in the correct places. If you combined this into Curric GPO, Staff GPO and MIS GPO, you'd have to make the same change three times.
I hope this is clear enough about getting the right balance and when to create a separate GPO.
As above. Each GPO adds size to your sysvol, so you don't want hundreds of them, but managing a super policy is a swine. I don't do things quite as recommended - I have a few settings in the Default Domain Policy, things like turning off Autorun - I know this is then properly domain wide. I then have a separate GPO for Teachers, Admin staff, students, teacher PCs, student PCs. I then have lots of GPOs for things like running a particular fix or script, installing MSIs etc, that aren't left applied.
Going through some of the Minasi books and having watched a few of the seminars that were streamed I tended to the following for planning GPOs.
Put everything you want into a super GPO as if you only have one computer and one user, then look at the differences in how you need different computers set up (i.e. software, security, etc) and then look at how you want different users set up.
Where possible keep it as simple as you can, only do loop backs if there is no other way of doing things and then once you have finished planning go away and come back in a week to repeat the task ... see if you come up with the same policies.
Then have a look at what is going to be scripted. Do any of the scripts replace or duplicate what is done in your GPOs?
Then look at the startup and logon times. Is there a vast difference on the different computers and with different users? Can you see what makes the difference and is it acceptable?
Finally, look at the policy settings / scripts which may change on a regular basis. These should be kept as independent of the other GPOs as you can to help with fault finding should anything go wrong when making changes.
And then ... you've guessed it ... go through it all again, see if you made the same decisions for the same reasons ... and *then* try it on a test network. Rinse, repeat.
And then put it into production.
We have followed Microsofts approach pretty much down the line. Our domain currently has about 200 policies within. This sounds like it would be a pain to manage, but if they are named appropriately it really is quite simple. We would also have 2 different policies for Computer and User e.g.
Windows7_BL (Computer Part)
Windows7_BL (User Part)
BL stands for baseline, once this is signed off, any further changes would be made to Windows7_Inc (Computer and User part respectively). This is so worst case scenario we could disable the _Inc policy and be left with a good set of policies.
The theory is that our Baseline should rarely ever change.
The reason we have this level of granularity is
A) We have a change department, that we obviously have to go through to get a GPO change authrorised. It is a lot easier to negate risks if you're not having to change 1 single GPO with thousands of settings.
B) We run a multiple domain setup, with a lot of our devices in a seperate domain from the users, so have seperate User Part\Computer Part policies with loopback works really well.
C) GPO's can from time to time become corrupt, and although this can obviously be resolved by a restore, it has less impact if you don't have 1 huge GPO.
D) Multiple people can work within Policy editor, without fear of impacting each other (as you would have with 1 policy)
Cheers. Sounds like you're coping well with FITS, much common sense involved :) We're building from scratch, and I'm concentrating on the baseline stuff at the moment. Basic security things - dissallowing autoplay, document folder redirects etc. Just struggling with libraries but that's something else (in the w7 forum). We probably won't be going down the line of change departments due to the size of our team however any changes will be fully documented. Or else! :)