Group Policy Deployment

Group Policy usage and configuration can vary greatly with each individual implementation. How GP is implemented can depend on the organization's users, sites, corporate culture, and a myriad of other factors. However, there are basic best practices that apply no matter what the Group Policy implementation. The following sections describe the basic best practices and lessons that have been learned through multiple GP implementations in many different organizations.

Less is More

The primary thing to remember with Group Policy is that less is more. Group Policy is very useful and administrators new to it frequently apply a great many Group Policies, using Group Policy as the elixir for all administrative issues. However, it's important to remember that with each Group Policy Object that is implemented and with each new layer of Group Policy, a fraction of a second is added onto computer boot time and user login time. Additionally, the GPOs take up space in SYSVOL on domain controllers, causing replication traffic as well as adding complexity that can make troubleshooting more difficult.

Knowing Resultant Set of Policies (RSoP)

The new Group Policy Management Console (GPMC) provides you with a handy tool for planning and testing Group Policy implementations prior to implementing them. Because Group Policy can cause tremendous impact on users, any Group Policy implementation should be tested using the RSoP tool in planning mode. See the sections entitled "Using Resultant Set of Policies (RSoP) in GPMC" and "Group Policy Modeling Using Resultant Set of Policy (RSoP)" for more information.

Group Policy Order of Inheritance

Group Policy can be configured on many different levels and, by default, is implemented in a particular order. However, by using the Block Policy Inheritance, Enforcement, and Link Enabled conditions the default order of application can be changed. It's a good idea to use these conditions sparingly because they can add a great deal of complexity to troubleshooting problems with Group Policy application. See the sections titled "Understanding GP Inheritance and Application Order" and "Modifying Group Policy Inheritance" later in this chapter for more information.

Knowing the Impact of Slow Link Detection

Slow link detection can change the Group Policy that a user receives, which can be a difficult thing to troubleshoot as an administrator. Understanding the importance of slow links can make troubleshooting a great deal easier for you if you have WAN links that may go up and down or work in an environment with bandwidth issues. See the section in this chapter entitled "Understanding the Effects of Slow Links on Group Policy" for more information.

Delegating GP Management Rights

It is important to delegate the proper rights for administrators to manipulate Group Policy. For example, a very small group of users should be able to edit policies on the domain level, but it might be necessary to allow diverse groups of administrators to configure Group Policies lower down the AD tree-in areas in which they administer.

An administrator can delegate the following rights to other administrators:

Create GPO
Create WMI filters
Permissions on WMI filters
Permissions to read and edit an individual GPO
Permissions on individual locations to which the GPO is linked (Called the Scope of management or SOM .)

Using the Group Policy Delegation Wizard makes it easy to give the right groups of administrators the rights they need to do their job, and continue to administer Windows Server 2003 in the most secure ways possible.

Avoiding Cross-Domain Policy Assignments

Avoiding cross-domain policy assignments is a recommended best practice. The more local the policies are, the more quickly the computers boot up and the users can log on, as the users or machines don't have to go across domain lines to receive group policies from other domains. This is especially pertinent for remote users.

Using Group Policy Naming Conventions

The impact of using Group Policy naming conventions cannot be understated. Naming conventions allow for easier troubleshooting and identification of policies and simplify managing Group Policies, especially in a large environment.

BEST PRACTICE: Using the Proper Naming Conventions

Use common naming conventions for similar policies ("Site_Name Software Policy," or "OU_Name Default Policy") rather than a different naming convention for similar policies. For example, begin Group Policy names with the name of the OU or site to which it applies.
Use descriptive naming for Group Policy objects. Don't use the default "New Group Policy" for any policy. If it's a software push policy, label it so.
Use unique names. It is not recommended to name two group policies the same name ”especially in different domains or forests.

Understanding the Default Domain Policy

The default domain policy is the domain level policy that is installed (but not configured) when Windows 2003 is installed. It should not be renamed , removed, deleted, or moved up or down in the list of Group Policies that exist on the top level of the domain. Certain security settings will only function properly when implemented in the Default Domain Policy (see the following warning). It's also a good idea to lock down the capability to edit the Default Domain Policy to a small number of administrators because security settings and other domainwide policies are set at that level.

By understanding and using these generic best practices, you can provide his users with a more secure, faster running, and uniform application of Group Policies.

Account Policy Settings

Account Policy settings applied at the OU Level affect the local SAM database, not Active Directory accounts. The Account Policy settings must be applied on the Default Domain Policy to affect Active Directory accounts.