Module 5: Designing Active Directory to Support Group Policy

Module 5: Designing Active Directory to

Support Group Policy

Overview

Identifying Business Needs

Applying Group Policy in Active Directory

Planning for Group Policy

Group Policy is used in Microsoft® Windows® 2000 Active Directory™ to administer many aspects of client computer configuration, from installing software to managing the user environment. The Group Policy object (GPO) is used to apply Group Policy to users and computers in the Active Directory directory service at the site, domain, and organizational unit (OU) level.

How an organization will use Group Policy depends on the level of client management desired. The plan for using Group Policy will impact the creation of lower-level OUs in the design of the Active Directory structure.

At the end of this module you will be able to:

Identify administrative needs that can be managed through Group Policy.

Determine the appropriate site, domain, or OU level at which to apply a Group Policy.

Design a Group Policy plan based on the administrative needs of an organization and design an Active Directory structure to support the plan.


Group Policy Is Applied:

Frequently in Highly Managed IT Networks

Infrequently in Minimally Managed IT Networks

Group Policy Is Used to:

Enforce Security

Create Common Configurations

Simplify Computer Build Process

Limit Distribution of Applications

When determining how Group Policy will be implemented in an organization, begin by identifying which areas of the organization require a high level of management and which areas require less management. Next, determine the ways in which GPOs will be used to fulfill management needs.

Level of Management

The extent of Group Policy use to manage client computers is determined by the level of service the Information Technology (IT) department will provide to the user. Because network administration can be delegated, you can use different levels of IT management in different areas of the organization. The two types of management environments are as follows:

Highly Managed. In highly managed environments the administrators of the domain or OU will use Group Policy to configure user and computer environments. Such Group Policy settings might include software distribution and maintenance, desktop security, offline folders management, and logon, logoff, startup, and shutdown scripts.

Minimally Managed. Environments that do not require a great deal of management will, to varying degrees, perform their own troubleshooting, install their own software, and may even replace their own hardware. Administrators in this type of environment use Group Policy sparingly.

Group Policy Objectives

To determine the business reasons for using Group Policy, you need to know the functions Group Policy can perform. You can use Group Policy to perform the following tasks:

Enforce common security standards. GPOs can be used to set consistent security parameters for all computers of a particular class. For example, it is recommended that domain controllers all have common security parameters restricting who can log on to the computer locally, and who can gain access to the domain controller remotely. Security policy is most commonly applied to domains, domain controllers, and servers.

Enforce computer and user configuration. Groups of computers and users will likely require common configurations. For example, while some users may log on at several workstations as a part of their job functions, they may still require a common configuration at each workstation.

Simplify the process for configuring computers. Group Policy can distribute applications, which can simplify computer configuration. Group Policy allows the administrator to send, or push a set of applications to a workstation or user with minimum effort. This process of distributing applications is especially useful in highly managed environments where the IT department is responsible for distributing and managing all applications in the enterprise.

Limit distribution of applications. Group Policy can simplify enforcing the legal compliance of computers and users by allowing the network administrator to restrict the distribution of applications for which there is a limited number of licenses.


Applying Group Policy at the Site Level

Applying Group Policy at the Domain Level

Applying Group Policy at the OU Level

Design Guidelines

GPOs can be created for sites, domains, and OUs. Applying GPOs at any of these three levels has advantages and disadvantages that can affect the scope of the GPO and how inheritance is passed between containers. For example, applying a GPO at the site or domain level affects more objects than applying a GPO an OU level. However, applying GPOs at the site or domain level offers less control over each individual object than does applying GPOs at the OU level.

In this lesson you will learn about the following topics:

Applying Group Policy at the site level

Applying Group Policy at the domain level

Applying Group Policy at the OU level

Design guidelines

Applying Group Policy at the Site Level

Single Site GPOs Affect All Domains Within the Site

Site Level GPOs Can Cross Domain Boundaries

Site

Domains

GPOs can be applied on a site, or a collection of subnets, on a network. GPOs applied at the site level are enforced on all computers and users physically located at that site. A policy set at the site level will not affect mobile users from that site if they access the network from another site.

Apply a GPO at the site level only when the policy setting is needed at that specific site. Site-specific GPOs can be used to manage traffic over slow network links. For example, to prevent software installation over slow network links, you may decide that you only want packages to be delivered within a single site. You would then publish the software using a GPO for the site so that installations would only occur to the computers within the site.

Single Site

In an environment containing a single site and a single domain, applying a GPO at the site level has the same effect as applying a GPO at the domain level. To simplify administration in this example, apply GPOs only at the domain level and not at the site level. In a single site with multiple domains, all domains will be affected by the site GPO.

Multiple Sites

Group Policy applied at the site level in a multiple-site structure can cross domain boundaries and be applied to computers and users in multiple domains. Therefore, you must be a member of the Enterprise Admins group to apply Group Policy at the site level.

Applying Group Policy at the Domain Level

In Single Domain, GPOs Affect Entire Domain and Cannot Be Delegated

In Multiple Domains, Domain Level GPOs Do Not Affect Other Domains Unless Linked

Parent Domain

Child Domain

Single Domain Multiple Domains

GPOs set at the domain level are applied to all computers and users within the domain.

Single Domain

You can create all of your GPOs at the domain level to eliminate the potential conflicts that can occur when GPOs also exist at the site or OU level. However, if you apply GPOs at the domain level only, you will not be able to delegate administration to other department administrators within the organization. All GPOs will need to be administrated at the domain level.

Multiple Domains

GPOs created in a parent domain cannot create conflicts with GPOs in a child domain. Domains define an administrative boundary in Active Directory and are administered independently of each other. As a result, Group Policy created at the domain level only affects users and computers in that particular domain.

You can apply Group Policy settings from one domain to users and computers in a second domain by linking the existing GPO to the second domain. However, this method creates additional network traffic. To avoid creating additional traffic, you can create a new GPO within the second domain that contains the same Group Policy settings as the GPO in the first domain. GPOs cannot be copied.

Group Policy Settings Commonly Set at the Domain Level

Group Policy can be set at either the OU level or at the domain level. However, even if Group Policy is set at the OU level, there are some Group Policy settings that are usually set at the domain level.

The following table describes the Group Policy typically set at the domain level.

Note: Domain Controller settings would normally be applied in an OU containing all of the domain controllers.

Group Policy typically set at the domain level

Target Level for the Target Level for the GPOGPO

Objective of the Objective of the Group PolicyGroup Policy

Group Policy SettingsGroup Policy Settings

Domains Security Password, Account, Kerberos Policy, Public Key Trust List

Domain Controllers Security User Rights, File/Registry Discretionary Access Control Lists (DACLs), Audit/Event log, Local Policies

Domain Controllers Applications Assign or Publish Administrative Tools

Domain Controllers User Environment Disable standard user settings

At OU Level, GPOs Are Inherited from Parent to Child OU

Applying Group Policy at the OU Level

Same Group Policy Inherited from GPO of Parent OU

GPO Linked to Parent OUs

OU Specifically Created for Group Policy

OU

OUOU

OUOU

OUOU OU

Applying Group Policy at the OU level allows you to tightly control the application of Group Policy to specific users and computers. For example, you can create OUs to group together subsets of users with common needs, and then apply a GPO appropriate to their needs to the OU. Creating GPOs for OUs gives the network administrator precise control over applying Group Policy settings, because it eliminates the need to filter Group Policy settings. However, it also means that there are more GPOs to manage. Also, conflicts between GPOs can occur because OUs can be nested, and because Group Policy is inherited from parent OU to child OU. Careful planning of OUs and GPOs can reduce conflicts caused by inheritance.

When you delegate, or decentralize, OU administration, you also delegate the administration of GPOs that are assigned to the OU. If you want to retain centralized administration of GPOs, do not delegate administrative control of OUs.

Group Policy Commonly Set at the OU Level

You set Group Policy at the OU level for the computers and users contained within a specific OU. The following table shows the typical areas and objectives for Group Policy settings at the OU level.

Group Policy Commonly Set at the OU Level

Target Level for Target Level for the GPOthe GPO

Objective of the Objective of the Group PolicyGroup Policy

Group Policy SettingsGroup Policy Settings

Workstations Security User Rights, File/Registry DACLs (access control lists), Audit/Event log, Local Settings

Workstations Applications Mandatory Core applications

Users Security EFS policy

Users Applications Publish optional applications and components

Users User Environment

Logon Scripts, Folder redirection, Desktop lockdown.

Design Guidelines

Create As Few GPOs As Possible

Map Each GPO to a Single Site, Domain, or OU Container

Avoid Linking GPOs Between Domains

Minimize the Number of GPOs Applied to a User or Computer

The following are general guidelines for applying Group Policy to Active Directory objects to support the Group Policy needs of your organization. Create a domain or OU design that will allow the fewest GPOs

possible. The more GPOs you have associated with any object, the more network traffic will be generated and the longer it will take for users to log on to the network. Create lower-level OUs based on the need for GPOs.

Map each GPO to only one site, domain, or OU container. This strategy will reduce confusion over inheritance rules and aid in troubleshooting conflict problems.

Avoid linking GPOs between domains to reduce users' logon time. Minimize the number of GPOs that are applied to a user or computer.

It is better to include many policy settings in a single GPO than to create many GPOs. One GPO with one hundred Group Policy settings processes faster than one hundred GPOs with only one Group Policy setting each.


Designing Group Policy to Meet Administrative Needs

Prioritizing Application of Group Policy Objects

Filtering Group Policy Objects

Group Policy Inheritance and Blocking

Optimizing Group Policy Performance

Testing and Documenting the Group Policy Plan

Design Guidelines

You can configure Group Policy settings in conjunction with Active Directory in your organization to define client standards for an entire organization, or specifically for members of a single workgroup, job function, or location. An effective Group Policy plan accommodates the needs of the organization and the organization's administration model. Use filtering to refine the application of Group Policy to particular subsets of users and computers within a given group. You can also block inheritance to prevent Group Policy from being applied to particular subsets of users and computers.

In this lesson you will learn about the following topics:

Designing Group Policy to meet administrative needs

Prioritizing application of Group Policy objects

Filtering Group Policy objects

Group policy inheritance and blocking

Optimizing Group Policy performance

Testing and documenting the Group Policy plan

Design guidelines


StrategyStrategyStrategyStrategy

Delegate the Right to Create New GPOs Throughout Active Directory

Delegate the Right to Create New GPOs Throughout Active Directory

Delegate the Right to Modify an Existing GPODelegate the Right to Modify an Existing GPO

Delegate the Right to Link GPOs to a Site, Domain, or OU

Delegate the Right to Link GPOs to a Site, Domain, or OU

There are various levels of administration for GPOs, including who can create them, who can link them, and who can modify them. The following table lists the administrative roles with regard to GPOs and the individuals who are assigned the task.


Administrative Administrative RoleRole

Assigned toAssigned to CommentsComments

Creating Members of GPO Creator - Owner Group

Whoever creates the Group Policy object owns it.

Modifying Users listed in GPO ACLs that set who can administer Group Policy objects

Because user rights can be granted to specific users, it is possible to delegate very precise control over Group Policy settings.

Linking Users listed in Active Directory container ACLs that set who can link GPOs to objects in Active Directory

An IT group may create a standard set of GPOs that can be linked by lower level Group Policy administrators.

Prioritizing Application of Group Policy Objects

GPOs Are Processed in Order of Priority

Loopback Applies Group Policy to a Specific Computer

An object that has multiple GPOs assigned to it will process them in order of priority. You can set the order in which GPOs are applied. For example, if a GPO that restricts access is applied to an OU containing some users that need access, you can prioritize the application of that GPO to occur after another GPO that secures access to the necessary users. When several GPOs are applied on the same object, some GPOs may contradict others. Remember that the last GPO applied to an object will determine which Group Policy is applied (if there are Group Policy settings that conflict with one another).

Loopback is a feature that allows administrators to override existing Group Policy on a particular computer. Override user-based Group Policy with computer-based Group Policy using loopback only when you want the computer environment to be the same no matter which user logs on.

Filtering Group Policy Objects

Roanoke OU

__Apply Group Policy to Roanoke Admins

__Apply Group Policy to Roanoke Admins

Users

Roanoke Admins

DENY

Filtering Prevents Group Policy from Being Applied

Filtering is used to exempt objects from Group Policy. For example, you will want to exempt the group that administers who is responsible for a particular OU from a Group Policy that prevents the users in the OU from editing the registry on their workstations.

Using Security Groups to Filter GPOs

Consider creating another OU if you find that you must link multiple GPOs to a single OU. A filter will affect all of the settings stored in a GPO. You cannot filter certain settings from the GPO to apply or not apply to a group.

If you must use groups within an OU to achieve the desired filtering result, consider creating another OU.

Note: Group Policy settings for folder redirection or software installation are not vulnerable to prioritization conflicts. In both cases, you can use ACLs to refine how a GPO is applied.

Apply GPOs at a level where they affect the greatest number of computers and users without creating the need for Group Policy filtering.


When Blocked, GPO Does Not Apply to Child OU

GPO Linked to Parent OU

OUOU

OUOU

OU OUOUOUOU

Inheritance BlockedOU


Within a domain, GPOs are inherited from one Active Directory container to another, so that in the Active Directory structure, any Group Policy applied to a parent container will also be applied to child containers.

Any GPO created at the domain level will be passed down through inheritance to all objects within the domain. Any GPO applied to a parent OU will be applied to all of its child OUs.

Blocking

You can block the inheritance of Group Policy. At the OU level, use the Block Policy Inheritance setting in the GPO to prevent the OU from inheriting Group Policy settings from a parent container. However, if the GPO of the parent container has the No Override (enforce) option set, the Block Policy Inheritance setting will have no effect. Use Block Policy Inheritance and the No Override settings sparingly as these settings make the troubleshooting of GPOs difficult and time consuming.

When users log on, any local Group Policy settings, or settings applied to an individual workstation, are processed first, with non-local or Group Policy settings for Active Directory objects processed last. This means that Group Policy settings based in Active Directory will have precedence over any local Group Policy settings. However, local Group Policy objects cannot be blocked. Therefore, local Group Policy objects are always applied.

Optimizing Group Policy Performance

Optimize Group Policy Performance Over Slow Connections by Adjusting:

Slow Link Processing

Periodic Refresh Processing

Client Side Extensions

To optimize performance over a network, many Group Policy settings can be configured to run only when there is an adequate network connection. The speed of the link can be set by the administrator to best use the available bandwidth and ensure that Group Policy settings don't consume bandwidth required by other processes and applications.

Processing Group Policy over Slow Links

Users logging on to the network from portable computers and branch locations may encounter slow links. To prepare for these encounters, Group Policy settings can be set to process only when there is an adequate network connection.

Optimizing Group Policy Performance …

The following table shows the default Group Policy settings for allowing processing over slow links, and whether the Group Policy setting can be changed for particular types of Group Policy when a slow link is detected.

Default Group Policy settings for allowing processing over slow links

Type of Group PolicyType of Group Policy DefaultDefault Changeable?Changeable?

Security Settings ON NO

Administrative Templates ON NO

Software Installation and Maintenance OFF YES

Logon/Logoff and Startup/Shutdown Scripts OFF YES

Folder redirection OFF YES

Internet Explorer Maintenance OFF YES

To view a list of all of the Group Policy settings for which you can change slow link behavior, open Computer Configuration\Administrative Templates\System\Group Policy in any GPO.

Setting the Group Policy Periodic Refresh Rate

By default, Group Policy settings are refreshed every 90 minutes with a 30 minute randomized offset, which is a random time added to the refresh interval to avoid peak loads on the network. This added time ensures that users who log on at the same time will not congest the network with Group Policy refreshes 90 minutes after they log on. Therefore, Group Policy refreshes may occur from 90 to 120 minutes apart.

You can control the frequency of Group Policy refresh intervals. The refresh interval could be shortened for a test environment, for example, or lengthened to lessen the impact of Group Policy refreshes on network bandwidth. The Group Policy refresh interval for domain controllers can be set separately from all other computers. Setting the domain controller to update more frequently ensures that changes are replicated to other domain controllers in a timely manner.

GPOs are applied or refreshed when users log on, but only if a setting has changed, in which case all GPOs are refreshed to ensure correct priority of inheritance.

Client-side Extensions

Client-side extensions are Group Policy components that implement Group Policy on a client computer. Some extensions, such as software installation and maintenance, can result in high network traffic and slow performance. You can change the behavior of client-side extensions with two settings: one that sets a minimum connection speed below which the extension will not run, and one that sets the extension to run no matter how slow the connection.

Testing and Documenting the Group Policy Plan

When Testing Group Policy:

Use an Off-Line Test Environment Test During Off-Peak Hours if Testing Environment Is

Not Available When Documenting Group Policy:

List Name of GPO List Site, Domain, or OU Where Applied List Individual Settings List Special Settings

When planning to implement Group Policy, it is important that you test and document your Group Policy plan.

Testing Group Policy Settings

Test the results of GPOs in a wide variety of situations. Many medium and large organizations create a miniature version of the production environment to use as a test bed. In small organizations without the resources to create a test bed, it is recommended that you implement Group Policy in the production environment at off-peak times, and have a solid regression strategy in place to rectify any unwanted results.

Strategies for testing include:

Logging on as representative users at representative workstations to verify that the expected Group Policy settings have been applied and that inheritance conflicts do not occur.

Testing mobile users by logging on in all possible variations to ensure that Group Policy settings are applied consistently in all situations.

Testing portable computers by connecting them to the network from various sites where users are likely to log on.

Use the GPResult.exe command-line utility from the Windows 2000 Server Resource Kit to check Group Policy settings in effect on that particular computer and on the user who is logged on to the computer.

Document the Group Policy Plan

Always keep a detailed list of all of the GPOs deployed in an organization so that you can locate and resolve Group Policy conflicts. It is also a good idea to keep a printed copy of this information. One way to track GPOs is to create a simple database that stores information such as:

The name of the GPO.

The site, domain, or OU where the GPO was applied.

The individual Group Policy settings in the GPO.

Any special settings applied to the GPO, such as No Override (enforce).

Each time that you create a GPO, add the relevant information about the GPO to the database. If there is a Group Policy conflict, you can quickly search the database to locate the problem. For example, if the Run command is removed from a user's Start menu, even though you specifically disabled that Group Policy setting for the Users OU, you can search the database for all Group Policy settings that affect the Run command to find the source of the effective policy.

Design Guidelines

Disable Unused Parts of a GPO

Reduce Need for Filtering By Creating Additional OUs

Use the Block Policy Inheritance and No Override Features Sparingly

When planning Group Policy, remember the following:

Disable the unused portions of a GPO to improve performance and decrease bandwidth demands. Disable the User Configuration or Computer Configuration settings of a GPO if none of these settings are configured. Disabling the unused settings also reduces logon time.

You can exempt a group of users in an OU from a GPO by filtering based on security group membership. The need for filtering GPOs can be reduced by creating additional OUs, thereby isolating the users or computers that require certain policy settings.

Implement straightforward policies to make troubleshooting Group Policy easier. For example, minimize Block Policy Inheritance, No Override, and Filtering so it is easier to locate the source of a particular setting.

Note: One of the ways that Group Policy affects a workstation is by modifying the registry of a workstation, using a policy template file. A number of template files are included with Windows 2000 allowing you to use Group Policy to change the registry and therefore the user environment. You can create your own Group Policy template files.

Recommended strategies for creating GPOs

StrategyStrategy Administrative modelAdministrative model

Create a separate GPO for each type of Group Policy setting

Use when multiple administrators are responsible for different areas of administration. For example, create a GPO for software installation and maintenance, and another GPO for security if each area is administered by a different user.

Create a separate GPO for user configuration and computer configuration

Use when users and computers are administered by different administrators.

Create GPOs for individual applications

Use when an administrator is responsible for the deployment and maintenance of a single application. For example, create a GPO containing software installation and maintenance settings and registry-based Group Policy settings for Microsoft Office 2000.

Create GPOs for user environment management

Use when an administrator needs to manage all user environment-related settings within a single GPO. For example, create a GPO containing folder redirection settings and registry-based Group Policy settings for User Configuration.

Lab A: Designing Group Policy and a Supporting Active Directory Structure

Review




Documents

Module 5: Designing Active Directory to Support Group Policy