A solution to monitor, manage and archive thousands of
events that are generated by devices across the entire network. Download FREE
trial
Group Policy Inheritance for Windows Server 2003
This page introduces all the objects and techniques that you will need to
create the best Group Policies for your Active Directory. In
particular, I will shows you how to get the most out of your policies by judicious use of
'Enforce' and 'Block Inheritance'.
Group Policy objects have to be created and held in a receptacle.
This receptacle could be at the domain, OU or site level. Do remember
that Windows 2003 comes with two default Group Policies, one for the domain Group and another for the Domain
Controllers. Also remember that yellow folders called Users and Computers are container objects and not OUs. This is not a trivial difference because containers cannot be assigned Group Policies
whereas OUs can. At some point in your Group Policy project you will focus on OUs, so it is best to review your OUs before you create lots of Group Polices.
Sooner or later everyone forgets that the domain level is the one and only
level that you can set domain account policies, for example password length,
lockout duration. It is also easy to overlook the Domain Controller
Group Policy when you are configuring local settings for those particular servers.
A good reason to create more policies is because you want each
department to experience independent desktop settings. The container for
these diverse policies is the OU (organizational unit). It is also
possible to set policies at the site level, but I would discourage this
except for the largest companies. My reasoning is that troubleshooting
policies in two locations is challenging enough, so you do not need the
extra difficulties caused by a policy at the site level which you had
forgotten about. Moreover, setting policies at the site level would
affect all the domains in that site.
A neglected area of OUs and Group Policies is servers. Why not create separate OUs for your servers, workstations and laptops? The benefit is that you
will focus on the Computer Configuration policies for these machines.
Summary, make the domain and OU objects your vehicles for Group Policies. If possible, avoid using Site or Local Group policies.
Troubleshooting
Group Policies is tricky
As an MCT trainer, I can thoroughly recommend TrainSignal because they
provide practical hands on training. In particular, I like the way TrainSignal cover all learning methods, instructor lead, video and of course text material. You can either take one module, for example Group Policy or go for
a combination of modules.
See more about Group Policy training here
Creating
Group Policy objects (GPO).
Just to be clear on the semantics, the settings that I discuss in the
following pages are held in Group Policy Objects (GPOs). These
policies are created in, or linked to, the container objects at the Site,
domain or OU level.
To create your GPO, right click the OU, select Properties, and then click
on the Group Policy Tab. (See Diagram)
Next click 'Open' and choose your OU and select: Create and Link a GPO
here. Now you are ready to edit the Group Policy settings and thus
fashion the desktop of your vision.
Another option is to Link an Existing GPO. otherwise known as : 'The one
I made earlier'. This concept involves recycling policies that you
designed for other OUs. Apart from not re-inventing the wheel, the
benefit is that the links themselves have permissions.
Most of the time you need not worry about Group Policy inheritance,
because if there is no conflict, then there is no problem. If
'Remove Run Command' is enabled at the domain level, and 'Add Logoff
to start menu' is enabled at the OU, there is no fight for control. It
is only when 'Add Logoff' is disabled at the OU then we have a
conflict with 'Add Logoff enabled at the domain GPO.
Group Policy Inheritance
(Local Policy XP and Member Servers)
Site
Domain
OU
Child OU.
Enforced (Also known as No-Override)
Surprisingly, by default, the settings at the lowest level win.
What ever is set at the child OU will override the same policy setting at
the domain level. If you are thinking, 'That cannot be right; that is
not what I intended', then I have just the option for you: 'Enforced'.
If enforced is set on a GPO at a higher level then the child objects and the
sub, sub OUs cannot override that policy.
Block Inheritance
There is one more setting that you should know about and that is Block
Inheritance. This is what I call the anarchists setting. If you
allow delegation at the OU, level then it is possible to stop any policies
coming down from the domain. However any policies that have been
'Enforced', cannot be blocked.
Remember that block inheritance affects the whole OU, not just one
policy.
As you design your policies, keep in mind for whom they are intended. For
instance, is a policy needed for all users or just for one department?
Microsoft calls controlling who gets particular settings as 'Policy
Filtering', Guy calls it adjusting the security tab.
When
you are new to Group Policies it is tempting to experiment with viscous
settings to lockdown the user. The problem arises, if you apply a high
security
policy at the domain level, and then you forget that affects even the administrator.
You only shoot yourself in the foot once, thereafter, you remember to filter the
policy so that only the intended users get your vicious settings.
There are two philosophies for filtering policies, either rip out the
Authenticated users and just add the group you have in mind for that policy;
alternatively, deny the policy to Administrators, so they will not be 'under the thumb'
of an aggressive lockdown policy. If you wish to edit permissions,
navigate to the menu above. Note the Delegation tab and in particular
the Advanced button on the bottom right.
Group Policy Creator Owners
What's new with delegation of permissions? In Windows 2003 there is a new built-in global
group called Group Policy Creator Owners. My own view is that I would
confine configuring Group policies to a small select group of experts and not
allow delegation of Group Policies to people in each OU. My point is that
while I am usually all for delegation, creating users - yes, reset passwords -
excellent use of delegation, but in the case of delegate Group Policies - no.
Leave Group Policies to your top administrator team.
