Lesson 2: Group Policy Implementation Planning

Before implementing group policies, you should create a plan to manage them. You can plan your GPO settings and GPO implementation methods to provide the most efficient group policy management for your organization. This lesson examines GPO settings and GPO implementation strategies.

After this lesson, you will be able to

Recognize management options for group policies

Estimated lesson time: 15 minutes

Designing GPOs by Setting Type

You can create GPOs based on the type of settings they contain. There are three main GPO setting designs:

Single Policy Type includes GPOs that deliver a single type of group policy setting—for example, a GPO that includes only security settings.

Multiple Policy Type includes GPOs that deliver multiple types of group policy settings—for example, a GPO that includes both software settings and application deployment, or a GPO that includes security and scripts settings.

Dedicated Policy Type includes GPOs dedicated to either computer configuration or user configuration group policies.

Figure 12.6 illustrates these GPO setting types.

Figure 12.6 GPO setting types

Single Policy Type

With this approach, the goal is to separate each type of group policy setting into a separate GPO. To do this, create a GPO for software management settings, a GPO for user documents and settings, a GPO for software policies, and so on. Give Read/Write access only to the user or users who need to administer a GPO.

This model is best suited for organizations in which administrative responsibilities are delegated among several individuals.

Multiple Policy Type

With this approach, the goal is to include multiple types of group policy settings in a single GPO.

This model is best suited for organizations in which administrative responsibilities are centralized and an administrator may need to perform many or all types of group policy administration.

Dedicated Policy Type

With this approach, the goal is to include all user configuration group policy
settings in one GPO and all computer configuration group policy settings in a separate GPO. This model increases the number of GPOs that must be processed at logon, thereby lengthening logon time, but it can aid in troubleshooting. For example, if a problem with computer configuration policy is suspected, an
administrator can log on as a user who has no user configuration policy assigned so user policy can be eliminated as a factor.

GPO Implementation Strategies

When planning an Active Directory structure, consider how group policy will
be implemented for the organization. Delegation of authority, separation of
administrative duties, central versus decentralized administration, and design flexibility are important factors to be considered when designing group policy and selecting which scenarios to adapt for an organization.

The group policy implementation strategies described in this section are samples that illustrate principles of design for group policy. Most organizations will combine several of these strategies to create custom solutions.

Layered vs. Monolithic GPO Design

These design strategies provide decentralized (layered) and centralized
(monolithic) locations for policy settings within GPOs.

Layered GPO Design

With a layered GPO approach (see Figure 12.7), the goal is to include a specific policy setting in as few GPOs as possible. When a change is required, only one (or few) GPO(s) has to be changed to enforce the change. Administration is
simplified at the expense of a somewhat longer logon time (due to multiple
GPO processing).

To achieve this goal, create a base GPO to be applied to the domain that contains policy settings for as many users and computers in the domain as possible. For example, the base GPO could contain corporate- or group-wide security
settings such as account and password restrictions.

Next, create additional GPOs tailored to the common requirements of each
corporate group, such as engineering, sales, marketing, executives, and administrative assistants, and apply them to the appropriate OUs.

This model is best suited for environments in which different groups in the organization have common security concerns and changes to group policy are frequent.

Monolithic GPO Design

With a monolithic GPO approach (see Figure 12.7), the goal is to use very few GPOs (ideally only one) for any given user or computer. All of the policy settings required for a given site, domain, or OU should be implemented within a single GPO. If the site, domain, or OU has groups of users or computers with different policy requirements, consider subdividing the container into OUs and applying separate GPOs to each OU rather than to the parent.

A change in the monolithic design involves more administration than the layered approach because the settings may need to be changed in multiple GPOs, but logon time will be shorter.

This model is best suited for environments in which users and computers can be classified into a small number of groups for policy assignment.

Figure 12.7 Layered vs. monolithic design

Functional Roles vs. Team Design

Active Directory's OU structure was designed to facilitate ease of administration and delegation of authority. The OU structure may represent the functional roles within the organization or it may not. When designing group policy for an organization with a functional role OU structure, design the group policy by delegating control to the OU levels. If the OU architecture does not represent group organization, then use OU delegation of control, but also choose to use groups as a filtering mechanism for applying group policy.

Functional Roles Design

With this approach (see Figure 12.8), the goal is to use an OU structure that
reflects the functional roles within the organization for applying group policy.
A minimum number of GPOs is used, with each tailored to a group's
specific needs.

To do this, create a GPO for each OU. Network administrators can set access control list (ACL) permissions for GPO administration either at the domain
administrator level or at each OU administrator level.

This model is best suited for organizations designed according to functional roles—groups of users organized according to users' occupations such as
engineering, sales, marketing, and so on. Each functional role requires specific group policies. The OU architecture reflects the functional roles within the
organization.

Team Design

With this approach (see Figure 12.8), the goal is to use groups as a filtering mechanism in applying group policy in an organization that uses the virtual team concept. Individuals within the organization form teams to perform a task or project and each individual is a member of multiple teams. Each team has
specific group policy requirements.

To do this, create GPOs for each virtual team. As users can exist in only one OU at a time, it is best to create a single GPO at the top of the hierarchy that filters down to each OU. Then, create GPOs for each team as necessary. This approach eliminates complexity by strategically applying the GPOs at only one location, allowing administrators to centrally administer the GPOs and minimizing the GPO-to-OU assignments.

This model is best suited for organizations that need an efficient and flexible method of managing group policy in a dynamic environment with an OU
architecture that does not reflect the team structure.

Figure 12.8 Functional roles vs. team design

OU Delegation with Central or Distributed Control

The administration of OUs can be delegated and OU administrators may need to be allowed to block group policies that have been assigned to their OUs at higher organizational levels. However, certain policies may need to be enforced and OU administrators will not be allowed to block them. This can be accomplished using a central or distributed control design.

Central Control Design

With this approach (see Figure 12.9), administration is delegated to OU
administrators, yet there is also centralized control.

To do this, use the No Override option on OUs. For example, create a GPO
including only security settings for a domain, and then set the No Override
option so that all child OUs are affected by the security options specified at the domain level. For all other types of policy, control of those GPOs could be
delegated to the specific OU administrators.

This model is best suited for organizations that choose to delegate administration of OUs, but would like to enforce certain group policies throughout the domain (for example, specific security policies).

Distributed Control Design

With this approach (see Figure 12.9), administrators of OUs are allowed to block group policies from being applied to their OU. However, the administrator cannot block group policies that are marked as No Override.

To do this, create GPOs for each OU. Set ACL permission allowing OU administrators full control over GPOs. Then, set the Block Policy Inheritance option for each OU.

This model is best suited for organizations that choose to minimize the number of domains but do not want to sacrifice autonomous administration of OUs. It allows administrators to enforce certain group policies throughout the domain.

Figure 12.9 Central vs. distributed control

Lesson Summary

In this lesson you learned that GPOs that deliver a single type or multiple types of group policy settings can be created. GPOs can also be dedicated to either computer configuration or user configuration group policies.

You also learned various strategies for implementing group policy. The layered GPO design model is best suited for environments in which different groups in the organization have common security concerns and changes to group policy are frequent. The monolithic GPO design model is best suited for environments in which users and computers can be classified into a small number of groups for policy assignment.

The functional role design model is best suited for organizations designed
according to functional roles—groups of users organized according to users'
occupations such as engineering, sales, marketing, and so on. The team design model is best suited for organizations that need an efficient and flexible method of managing group policy in a dynamic environment with an OU architecture that does not reflect the team structure.

The central control design model is best suited for organizations that choose to delegate administration of OUs, but would like to enforce certain group policies throughout the domain. The distributed control design model is best suited for organizations that choose to minimize the number of domains but do not want to sacrifice autonomous administration of OUs.