Design Considerations for Organizational Unit Structure and Use of Group Policy Objects

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

This section discusses issues you need to consider when planning and implementing your organizational unit structure, and highlights recommendations for the use of GPOs.

Organizational Unit Structure

The Group Policy architecture is flexible and allows for many types of design. The guiding principle as you design your organizational unit structure should be to create a structure that is easy to manage and troubleshoot. There are two key reasons to create an organizational unit:

• To enable delegation of administration.

• To scope the application of GPOs.

In general, do not try to model your organizational unit structure based on your business organization. Rather, design your organizational unit structure based on how you administer your business. Information about planning for Active Directory is available in Best Practice Active Directory Design for Managing Windows Networks at https://www.microsoft.com/technet/prodtechnol/ad/windows2000/plan/bpaddsgn.asp.

In most organizations, organizational unit structure is likely to fall into one of the following categories:

• Flat organizational unit structure: 1 or 2 levels

• Narrow organizational unit structure: 3 to 5 levels

• Deep organizational unit structure: more than 5 levels

For organizations with simple administration requirements, it is recommended that administrators use a simple model in which a flat organizational unit structure is used and GPOs are linked at the domain or organizational unit level. Limited use of security groups or WMI filtering to filter GPOs is recommended. If you need additional flexibility, it is suggested that you reconsider your organizational unit structure.

For organizations with moderate administration requirements, it is recommended that administrators use a narrow organizational unit structure and GPOs are linked at the site, domain, or organizational unit level as necessary. Limited use of the Block Policy Inheritance options, the Enforce Policy options, security groups or WMI filtering to filter GPOs is recommended.

For organizations with complex administration requirements, the Active Directory namespace may use flat, narrow, or deep organizational unit structures. In such cases, administrators should consider the following issues:

• Flat organizational unit model: use security groups and DACLs or WMI filtering to filter effects of GPOs as a primary method, and Block Policy Inheritance and Enforce Policy options as secondary methods.

• Narrow organizational unit model: link to GPOs at site, domain, and organizational unit. As a secondary method, use Block Policy Inheritance and Enforce Policy options, and security groups and DACLs, or WMI filtering for filtering effects of GPOs.

• Deep organizational unit model: link to GPOs at site, domain, and organizational unit with security groups filtering and DACLs or WMI filtering. As a secondary method, use Block Policy Inheritance and Enforce Policy options.

Design Principles

This section presents general guidelines for using GPOs and policy features, and includes examples of GPO design.

Administration of Group Policy Objects

Delegation of authority, separation of administrative duties, central versus distributed administration, and design flexibility are important factors you'll need to consider when designing Group Policy and selecting which scenarios to use for your organization.

How you design your organizational unit structure and GPOs will depend on the administrative requirements and roles in your corporation. For example, if administrators are organized according to their duties (such as security administrators, logon administrators, and so on), you may find it useful to define these policy settings in separate Group Policy objects.

Delegation of authority will depend largely on whether you use centralized or distributed administration in your corporation. Based on their particular corporate requirements, network administrators can use security groups and Discretionary Access Control List permissions to determine which administrator groups can modify policy settings in GPOs. Network administrators can define groups of administrators (for example, Software Installation administrators), and then provide them read and write access to selected GPOs, allowing the network administrator to delegate control of the GPO settings. Administrators who have read and write access to a Group Policy object can by default control all of the contents of that Group Policy object; however, you can restrict access by setting policy to control which MMC snap-ins can be loaded by that user, as described earlier in the "Delegating Group Policy" section.

Separate Users and Computers into Different organizational units

It's recommended that you separate users and computers into separate organizational units. This is useful for these reasons:

• This simplifies GPO design because you need to focus on only configuration of either user or computers.

• Typically users and computers are administered differently, perhaps by different groups within your organization, which facilitates administration.

• You can reduce Group Policy processing time because you can disable the unused half of the GPO. It is possible to disable only the User or Computer portion of the GPO. To do this, right-click the GPO, click Properties, click either Disable Computer Configuration settings or Disable User Configuration settings, and then click OK. These options are available on the GPO Properties page, on the General tab.

• This type of design is required to enable loopback processing. See the "Group Policy Loopback Support" section for more information.

• For increased security and ease of administration, you should specify different organizational units for all new user and computer accounts when they are created, as explained below.

Redirecting the Users and Computers Containers in Windows Server 2003 Domains

New user and computer accounts are created in the CN=Users and CN=Computers containers by default. It is not possible to apply Group Policy directly to these containers, although they inherit GPOs linked to the domain.

Redirusr.exe (for user accounts) and Redircomp.exe (for computer accounts) are two new tools included with Windows Server 2003 that enable you to change the default location where new user and computer accounts are created so you can more easily scope GPOs directly to newly created user and computer objects. These tools are located in %windir%\system32. By running Redirusr.exe and Redircomp.exe once for each domain, the domain administrator can specify the organizational units into which all new user and computer accounts are placed at the time of creation. This allows administrators to manage these unassigned accounts by using Group Policy before the administrators assign them to the organizational unit in which they are finally placed. You might want to consider restricting the organizational units used for new user and computer accounts by using Group Policy to increase security around these accounts.

For more information about redirecting users and computers, see article 324949, "Redirecting the Users and Computers Containers in Windows Server 2003 Domains," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

For more information about the redirusr.exe and redircomp.exe tools, see the Redirecting Users and Computers link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Best Practice Organizational Unit Structure

Because you cannot apply Group Policy directly to the CN=Users and CN=Computers containers, if you wanted to define policy settings for users and computers to be stored in their default container you needed to do so on the root of the domain. To prevent policy settings that are defined on a superior container (the root of the domain) from applying to users, computers, and groups in subordinate CN and organizational unit containers, you needed to define complex ACLs on the policy setting in the root of the domain.

The solution for Windows 2000 and Windows Server 2003 domains is to deploy the best-practice organizational unit structure where Users, Computers, Groups, Service Accounts and Admin accounts are each in their own organizational unit.

The following list describes the benefits of using the best-practice organizational unit structure:

• It permits administrators to link GPOs directly to the containers that are hosting users and computers.

• It permits administrators to match GPOs to objects of a common object class. For example, User or Computer policy settings can be linked directly to organizational units that are hosting user or computer accounts.

• It permits non-administrators to apply policy on containers that are not hosting security-sensitive users and groups such as Domain Admins, Schema Admins, or Enterprise Admins.

• It can minimize the effect if an organizational unit is accidentally deleted (this assumes that the parent container is correctly protected).

• It permits you to restore users and groups independently of each other in recovery scenarios. User accounts must exist before the restoration of the group. Having users and groups reside in different containers permits you to restore them and mark them as authoritative independently of each other.

Note that the CN=USERS and CN=COMPUTERS containers are computer-protected objects. You cannot (and must not) remove them for backward compatibility purposes although they can be renamed.

The best-practice organizational unit structure works well for storing existing users, computers, and groups in Active Directory because those objects can be moved into the appropriate organizational unit container on Windows 2000 and Windows Server 2003 domains regardless of its domain or forest functional level. New user accounts, computer accounts, and security groups that are created with earlier-version APIs used by GUI and command-line management tools do not allow administrators to specify a target organizational unit. As a result, these objects will initially be created in the CN=Users and CN=Computers containers until they are moved by the administrator or an administrator-defined script.

For more information about best-practice organizational unit structure see the "Creating an Organizational Unit Design" section of the Best Practice Active Directory Design for Managing Windows Networks at https://www.microsoft.com/technet/prodtechnol/ad/windows2000/plan/bpaddsgn.asp

Functional Compared with Geographical Organizational Unit Structure

When organizing organizational units, there are two basic models to start with: functional and then geographical, or geographical and then functional. The key is never to implement a structure that forces an artificial layering, which means that the organizational unit structure for computers may be very different than that for users—it all depends on how they are administered.

Minimize the Number of Group Policy Objects Associated with Users or Computers

You should note that the number of GPOs that are applied to a user affects the logon processing time. (Similarly, the number of GPOs applied to a computer affects boot time). The greater the number of associated GPOs, the longer logon will take to process them. During logon time, each GPO from the user's site, domain, and organizational unit hierarchy is applied, provided the user has both the Read ACE and the Apply Group Policy ACE. Note that if the Apply Group Policy ACE is not set, but the Read ACE is, the GPO will still be processed (although not applied), thus impacting logon time. Therefore, if you implement filtering based on security groups, you should also clear Read Access for those users that you clear Apply Group Policy for.

Minimize the Use of the Block Policy Inheritance Feature

As mentioned previously, you can prevent Group Policy settings of parent Active Directory containers from affecting users and computers in lower-level parent Active Directory containers. This is a useful and powerful feature that you should use judiciously only when a particular situation requires it. Blocking the inheritance of policy from parent Active Directory containers can complicate troubleshooting policy.

Minimize the Use of the Enforce Feature

You can also ensure that the policy settings you specify in a given GPO at a higher-level parent Active Directory container are enforced on lower-level parent Active Directory containers by using the Enforce option. Only use this powerful feature when circumstances require it. Overuse of this feature with other related features, such as Block Policy Inheritance, can complicate troubleshooting policy.

Use Loopback Processing Only When Necessary

You can set User Configuration per computer and thus override user-specific policy settings with computer-specific policy settings. This is useful when you want to provide a specific desktop configuration regardless of which users log on to the computer, such as a kiosk or other public terminal. To set User Configuration per computer, you would use the Administrative Templates node under Computer Configuration in the Group Policy Object Editor. For more information about this feature, see Group Policy Loopback Support.

Avoid Using Cross-Domain GPO Assignments

Although you can assign GPOs from different domains to a single Active Directory container if a particular situation requires it, you should note that in such cases Group Policy processing would be slower. This is because domain boundaries are crossed.

Avoid Editing the Default Domain GPO

Instead of editing the default domain GPO, create a new GPO, link it to the domain GPO, and set the new GPO to have precedence over the default domain GPO.

Design Examples

This section presents several models of GPO design. These examples are not intended as guidelines, but they do illustrate various ways to approach GPO design. In most corporate environments, administrators may use a combination of these or similar models, tailored to their business requirements.

The key overriding approaches are either functional or geographic models. The rest are usually variants of those.

Layered GPO Design Model

The objective of this design model is to create GPOs based on a layered approach. This approach optimizes maintenance of GPOs and facilitates delegation.

The following graphic illustrates an example of this model.

Monolithic GPO Design Model

The objective of this design is to create GPOs based on a monolithic design—an approach that reduces the number of GPOs that apply to a user and/or computer but may not be optimal for delegation.

The following graphic illustrates an example of the monolithic GPO model.

Single Policy Type GPO Design Model

The objective of this design is to create GPOs that deliver a single type of Group Policy, for example, policy for security settings. Such a design optimizes separation of duties for administrators; however, it may increase the number of GPOs that are applied to a given user or computer.

Each GPO delivers only one type of policy (security GPOs are different from script Group Policy objects, for example). Large corporations often create separate administrator groups based on administrative duties; this scenario would be useful in such corporate environments.

The following graphic illustrates an example of the single policy type GPO model.

Multiple Policy Types GPO Design Model

The objective of this design is to create GPOs that deliver multiple types of policy. This is a hybrid of the single policy and monolithic models. Each GPO delivers several types of policy settings.

For example, you can create a GPO that includes Group Policy settings for software settings and application deployment and create another GPO that includes security and scripts settings, and so on. A GPO design that supports multiple policy types is useful in delegating administration environments and can reduce the number of GPOs that apply to a user and/or computer.

The following graphic illustrates an example of the multiple policy types GPO model.

Teams or Matrix Organizations GPO Model

This model applies to organizations that leverage 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. The organizational unit architecture does not reflect the team structure. This model works by using security filtering.

The following graphic illustrates an example of the team GPO design model.

Public Computing Environment GPO Model

This scenario applies to environments were you want the computer Group Policy settings to always have precedence over the user Group Policy settings. This scenario is useful for training classes and kiosk-type environments in which you want to provide the same desktop environment regardless of which user logs on to the computer.

The following graphic illustrates an example of the GPO design for a public computing environment. The loopback policy feature with Replace mode is used in this example. See "Group Policy Loopback Support" in this document for more information.

Normal Group Policy processing specifies that users in the Sales organizational unit get these GPOs: Domain Policy GPO, Accounting GPO, and Sales GPO. With the loopback policy enabled in Replace mode, when users from the Sales organizational unit log on to a computer in the Kiosks organizational unit, the user will process only these GPOs: Domain Policy GPO, Accounting GPO, Resources GPO, and Kiosks Loopback Policy GPO—the users' list of GPOs is not gathered in this case. More specifically, the user settings specified in the Kiosks organizational unit (and those inherited) are the only GPOs processed for the user logging onto computers in that organizational unit. Those in the Users organizational unit tree are not processed.

Delegation with Central Control

This model applies to organizations that choose to delegate administration of GPOs, but would like to enforce certain Group Policy settings throughout the domain (for example, specific security policy settings).

The following graphic illustrates an example of GPO delegation with centralized control, and use of the Enforce option.

Delegation with Distributed Control

This scenario applies to organizations that want to allow administrators of organizational units to prevent Group Policy settings from being applied to their organizational unit. Administrators of an organizational unit can block Group Policy settings that have been assigned at higher levels in the hierarchy from applying to his or her organizational unit. However, administrators cannot block Group Policy settings that are marked as Enforce.

This feature allows organizations to minimize the number of domains without sacrificing autonomy.