But that would mean you would have policies that overlap in their settings.
I would recommend multiple policies with each policy doing "less". Each
policy would do one simple specific thing. You then just apply multiple
policies to an OU to get the aggregated effect you want.
So, what is your suggestion for policy objects across OU's (or even
individual groups) where there are slight but significant changes to
the policies for each site/group? Going through the manual creation
and testing when there's already one you know works and can use with
simple minor modifcations seems like an unecessary chore to me. And
as the OP pointed out, you just might want to change a complex policy
and test it without touching your existing policy.
I do agree with the many/separate policies point, unless that gets to
be unweildy to manage. But not using an existing resource doesn't
sound very.. ... ..resourceful to me...
As a "preventative FYI", I also recommend you not get "carried way" with
GPOs. Group Policy is not the "Universal Monkey Wrench". It should not be
used for "everything imaginable".
What?? Well what the heck IS it for then - and if it's not a
universal monkey wrench, why does it happen to fit a LOT of the
screws, pipes, nuts, and bolts that I need to turn? As a matter of
fact, it's the only tool that fits in most cases.
There are things about it that will bit
you in the rear-end if you are not careful.
Amen, but isn't that statement as applicable to life in general as it
is to group policies? At least you can test a policy before you roll
it out - there is no such testing for negative reactions in life...
For example, removing or
unlinking a GPO from an OU does *not* put the settings back to the original
state on the effected machines. GPO is somewhat of a glorified registry
editor, and removing or unlinking the GPO doesn't return the settings to
Defaults anymore than closing Regedit returns the settings to Default after
you've changed something using it. Once they are changed,..they are
changed,..until they are "forced" back by another settings change.
O absolutely. But then again, what method of control or configuration
change is there for a workstation that actually does work and then
actually does return to original settings when you're done?
If you think we're screwing up, tell us why - after you've gotten the
pertinent details. If you don't understand why we'd want to do
something that we request help with, ask until you understand, and if
you understand and *still* determine that it's stupid, then tell us
what you would do in our place.
I don't usually argue with anyone with that many letters after their
name, but I don't think discouraging the OP's efforts to understand,
implement and work with group policies is good advice.
Don't take it for granted that we're morons just because we asked.
JeffG (no letters)