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'.
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.
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, Windows 7 and Member Servers)
Site
Domain
OU
Child OU.
Block Inheritance
There is one setting that you should know more 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.
Normally all GPOs are applied and settings configured are cumulative as
you go down the directory tree. Where settings contradict, the last
writer wins. Now there may be situations you don't want that
behaviour. This is where Block Inheritance comes into play, for you
to regain control of your vision or master plan for users' settings.
Remember that if you impliment Group Policy's block inheritance it affects the whole OU, not just one
policy.
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.
Guy
Recommends: Permissions Analyzer - Free Active Directory Tool
I like the
Permissions Monitor because it enables me to see quickly WHO has permissions
to do WHAT. When you launch this tool it analyzes a users effective NTFS
permissions for a specific file or folder, takes into account network share
access, then displays the results in a nifty desktop dashboard!
Think of all the frustration that this free utility saves when you are
troubleshooting authorization problems for users access to a resource.
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.
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.
Encouraging computers to sleep when not in use is a great idea -
until you are away from your desk and need a file on that remote sleeping machine!
Wake-On-LAN really will save you that long walk to awaken a hibernating
machine; however my reason for encouraging you to download this utility is
just because it's so much fun sending those 'Magic Packets'. As Wake-On-LAN (WOL) is free, see
if I am right, and you get a kick from arousing those sleeping machines.
WOL also has business uses for example, wakening machines so that they can have
their patches applied.
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 the 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.
Guy Recommends: SolarWinds Engineer's Toolset v10
This Engineer's Toolset v10 provides a comprehensive console of utilities
for troubleshooting computer problems. Guy says it helps me
monitor what's occurring on the network, and each tool teaches me more about how the
underlying system operates.
This page shows techniques to
create the best Group Policies for your Active Directory. In
particular, I you can see how to fine-tune your policies by judicious use of
'Enforce' and 'Block Inheritance'.
If you like this page then please share it with your friends
*
Custom Search
Guy Recommends: Orion's NPM - Network Performance Monitor
Orion's performance monitor is designed for detecting network outages. NPM makes it easy to see what's working, and what needs your attention.
This utility guides you through creating network maps. It also helps troubleshooting by indicating whether the root cause is faulty equipment, or resource overload.
