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
http://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
http://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 http://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
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 on 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.