When creating the OU structure, you need to base it primarily on administrative needs. Although we keep hitting on that point, it cannot be stressed enough. You should build the OU structure to make the administration of the domain as easy and efficient as possible. You can create GPOs to take advantage of the administrative structure of the OUs, and you can create additional OUs if the Group Policy requirements dictate it, but do so sparingly.
Two containers exist within Active Directory: the Users container and the Computers container. If a user or computer account is created and an OU membership is not specified, then the user account is created in the Users container and the computer account are created in the Computers container. GPOs cannot be set on these containers. The only GPOs that will apply to these users are the settings applied at the site or domain level. If you are following the recommendation that GPOs be applied at the OU level as much as possible, these users and computers will not be under the jurisdiction of GPOs that would otherwise control what the accounts can do.
To avoid this scenario, Microsoft has included two utilities with Windows Server 2003: redirusr.exe and redircmp.exe. As you can probably tell from their names , these utilities redirect the accounts to OUs that you specify instead of the default containers. However, there is one caveat to using these utilities: the domain has to be at the Windows 2003 functional level. Unfortunately, not many organizations are ready to move to this functional level. Those that have had the good fortune to change their domain functional level to Window 2003 will find that they can take advantage of creating new OUs for controlling those new user and computer accounts.
For more information about the redirusr.exe and redircmp.exe commands, see TechNet article 324949, Redirecting the Users and Computers Containers in Windows Server 2003 Domains.
After redirecting new accounts to the new OUs, the rest of the OU structure needs can be identified. Most of the OU structure should already be designed because it is based on the administrative structure of the organization. In Chapter 5, we discussed creating the top-level OUs based on a static aspect of the organization. This still holds true for Group Policy design. If the top-level OUs are based on either locations or functions, the structure is resistant to change. The child OUs can then reflect the administrative requirements. This allows for the administrative staff to have efficient control of those objects they need to manage.
GPOs will use this structure, but other OUs may need to be created to further enhance the Group Policy requirements. Do be careful when you create additional OUs to implement Group Policy. The more layers in the hierarchy, the harder it is to manage the objects within.
Remember, the key to the OU structure is to make administrative tasks easier. Investigate all of the possible options when you are determining how to apply GPOs.
New OUs should be added to the OU structure only if they enhance the application of GPOs and make the assignment of settings and restrictions to a group of users or computers easier than if they were linked at an existing OU. Use the Group Policy Modeling Wizard within the GPMC to determine if the application of policies is going to work as you expect it to.
Experiment with the linkage of GPOs at those OUs that you already have defined. View the results and see which accounts are adversely affected before determining that an additional OU is required. You may find that filtering the GPO to a new group that you create allows you to assign settings to those users within that group while keeping the users within the OU instead of creating a new OU to host them.
Those users who need to create and link the OUs will need the appropriate rights delegated to them. You will also need to identify how you are going to maintain the GPOs and monitor how the GPOs are administered. Once the OU structure has been identified for applying Group Policy, the staff who will be responsible for the creation and maintenance of the GPOs will need rights delegated to them and training provided. If you are delegating the ability to perform specific functions to those users who are working with GPOs, you can give them the ability to create GPOs, edit GPOs, and link GPOS. One user could have the ability to perform all three functions, or you could break the functions up so that only certain users can perform an individual task. The following section will describe how you can design your GPO management for delegated administration.
In smaller organizations, the same administrator who creates user accounts will maintain the servers and work with the GPOs. Such an administrator, sometimes known as the Jack-of-All-Trades administrator, does it all. For this type of administration, identifying who is going to perform the tasks is simple. That administrator has to make sure that they are trained to perform the tasks at hand. In larger environments, however, one administrator cannot do it all. Usually specific tasks are assigned to users, and they are responsible for their own little piece of the organization. In this case, the users who are delegated the tasks of maintaining GPOs have to be trained on the proper methods of maintaining the Group Policy infrastructure.
Different users can be assigned to create GPOs than those who are allowed to link the GPOs. In larger organizations where specialized job functions are assigned to employees , or in organizations that use the hybrid administrative model, users who are in charge of corporate standards can be allowed to create unlinked GPOS and modify GPOs with the settings determined by the corporate administration. The domain and OU owners are then responsible for linking the appropriate GPOs to their OUs or domains.
When you delegate the permission to perform actions on GPOs to users other than administrators who already have that ability, you need to make sure that you are giving the users permission to do so only for the portion of Active Directory that they are responsible for. Within the GPMC, you can delegate the ability to link GPOs at the site, domain, or OU level. By changing permissions within the discretionary access control list for the GPO, you can control who is able to edit the GPO. By granting someone the Read and Write permissions, that user could modify settings within the GPO. Figure 6.10 shows the Delegation tab within the GPMC for an OU.
There is a special group that exists to make the task of delegating the creation of GPOs easier; the Group Policy Creator Owners group. When a user is added to this group, they will be able to modify any GPO that they create, but they will not be able to link the GPO anywhere within Active Directory unless they have been delegated the right to do so at a site, domain, or OU.
When employees are granted the ability to create, modify, and/or link GPOs, they should be trained on the proper methods of handling their responsibilities. Guidelines for the functions that can be performed should be explained to the OU owners, domain owners, and forest owners. Without a basic set of guidelines, users could inadvertently make changes or create GPOs that will not function properly within your environment. Document the guidelines that you want to use and make sure everyone involved understands them.
The Group Policy administration training methodology should include best practices for the following topics:
Setting exceptions for inheritance
Using the Group Policy Modeling Wizard
Using the Group Policy Results Wizard
Backing up and restoring GPOs
Learning which settings apply to specific operating systems
Using WMI filters
Handling security templates
If users understand how each of these work, they will have a better understanding of why GPOs should be implemented the way they are, and as a result, the troubleshooting required to determine problems should ease. The more training and understanding that goes on before the users are allowed to create and maintain GPOs, the less time will be spent troubleshooting later in the life cycle of Active Directory.
For the most part, GPOs should be linked at the OU level. This allows you to use the most versatile method of controlling how the settings are applied. Sometimes you will find that the best method of applying policies is performed if the policy is linked at the site or domain level. As mentioned previously, the account policies are always set at the domain level. You may also find a reason to link them at the site level, such as when all computers at the site need to have an IPSec policy applied to them.
In order for a GPO to be linked at the site level, the administrator who is performing the linking has to have enterprise-level permissions or have the permission to link to the site delegated to them. Adding an account to the Domain Admins global group or Administrators domain local group at the root domain or Enterprise Admins universal group is not a recommended practice unless that administrative account is the forest owner.
Administrative staff responsible for linking at the domain level will need to be members of the Domain Admins global group or have the Manage Group Policy Links permission delegated to them. Members of the Domain Admins global group will also be able to use the GPMC and edit any GPOs for their domain. To have access to GPOs for any other domain, they will need permissions delegated to them for the objects within the other domains, or they will need to be members of the Enterprise Admins universal group.
Policies linked at the OU level require the administrative staff to be members of the Domain Admins global group for the domain or have the proper permissions delegated to them to work with GPOs.
No discussion of GPOs would be complete without touching on the need to have change management procedures in place. Change management procedures are rules that are used to control when and where changes can be made to GPOs. GPOs assist in the administrative control over users and computers and should be treated as a critical part of your Active Directory environment. Changing a setting within a GPO could affect the way users are allowed to work or how they are controlled within the network. Without change management procedures in place, users who control GPOs will not have the proper procedures to follow when implementing changes.
In the following sections we will discuss what goes into the change management procedures and why they are important.
Karlee Hospital is in the design phase of their Windows 2003 Active Directory upgrade. The forest and domain designs have already been decided upon; an empty root forest will be created to host the forest administrators only. Each of the entities that make up the organization has a subdomain structure based on the business units. The forest root domain uses the domain name karlee.local. The insurance division has a domain called insurance.karlee.local and the clinic has clinic.karlee.local as its domain name.
Several administrators responsible for the rollout of Active Directory have been identified as the forest owners. It has been decided by the design team that they will not have the time to oversee the Group Policy structure for all of the organizations. Domain owners will have the ability to control GPOs within their domain and have the right to delegate out the ability to create and link GPOs to administrators within the domain.
Administrators who are OU owners are allowed to create, link, and maintain GPOs. They are also allowed to run the Group Policy Modeling Wizard to determine if the GPOs will work correctly within the hospital s environment. Prior to making any changes to the GPO structure, however, they need to submit a change request to the forest owners who will in turn verify that the change is necessary.
When setting up your change management procedures, you should create a Group Policy change approval committee. The members of this committee should understand how GPOs function and know the Group Policy requirements of the organization. Earlier in this chapter, in the section Understanding the Company s Objectives, we discussed the organization s objectives and why they need to have GPOs. This committee should follow the objectives and make sure that any changes follow the requirements of the organization.
Before creating a change request, the user who is requesting the change should identify exactly why the change should be enacted. Sometimes this change could be something as simple as a change to the menu options available on the Start menu, or as extensive as a new software rollout. Most medium and large companies create a change request form that the user has to fill out and submit.
The change request form should contain the reason for the change request and when it needs to be implemented. It should also include information that will identify the users or computers affected by the change. This information is necessary so that proper testing of the change can take place. Without proper testing, changes could affect the users or computers in unforeseen ways.
While reading through this text, you may think that this section is pretty basic, but there are still things that need to be said about backing up and restoring GPOs. Any change to a GPO could have detrimental effects on the users and computers to which the policy is applied. Having a good backup of the original GPOs will allow you to replace a misconfigured or damaged policy very quickly.
A feature of the GPMC is the ability to back up and restore GPOs without having to retrieve them from a system backup. The backup function will back up both the Active Directory GPO and the Sysvol Group Policy Template. When restored, both parts of the GPO are returned to their proper locations. Part of the change procedures that are put into place should include training the technical staff who are responsible for maintaining GPOs on how to back up and restore using the GPMC.
At the same time, a procedure should be put into place that will identify how the backups will be saved. Sometimes problems with a change will not manifest themselves for days or weeks. Once a change is discovered , there should be a way to reverse it so that the original settings are available once again. Creating a backup scheme that will allow you to keep several revisions of GPOs could save you from administrative hassles and help maintain SLAs.
In the Linking GPOs Design Scenario, you will need to identify the requirements for the users to be able to create and link GPOs at different levels within an organization s Active Directory.
Tom is responsible for linking GPOs within Active Directory. However, he is not allowed to create the GPOs; this is the responsibility of two members of a Standards and Practices Committee ” Susan and DeAnn. After DeAnn creates a GPO and Susan has thoroughly tested it using the Group Policy Modeling Wizard, they notify Tom that he needs to link it to a site within Active Directory.
Question: What level of permissions is required by Susan and DeAnn? Answer: They need to be members of the Group Policy Creator Owners group or be granted permission to create GPOs in a specified domain. If they have the proper permissions to do so, they will be able to work with the GPOs they create, but will not have the ability to link them.
Question: Which utilities could Susan and DeAnn use? Answer: They need to have the GPMC in order to run the Group Policy Modeling Wizard. DeAnn could use the Group Policy Object Editor in the MMC to create the GPO.
Question: What permissions mustTom have to link the GPO? Answer: BecauseTom is linking the GPO to a site, he must either have Enterprise-level administrative rights or have the Manage Group Policy Links permission delegated to him for that particular site.