Group Policy 2

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.

 

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.

 

 

Group Policy Links

 

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.

 

 

Group Policy Inheritance

 

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.

 

 

Group Policy Security - 'Filtering'

 

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.