Starting an OU Design

As with Active Directory domain design, OU design should be kept simple and expanded only if a specific need makes the creation of an OU necessary. As you will see, compelling reasons for creation of OUs are generally limited to delegation of administration, in most cases.

As with domain design, it is important to establish a frame of reference and common design criteria when beginning design of the OU structure. Organizational units are often graphically represented by a folder that looks like the icon in Figure 6.4.

Figure 6.4. Folder icon in Active Directory.

Another common method of displaying OU structure is represented by simple text hierarchy, as shown in Figure 6.5.

Figure 6.5. Simple text hierarchy for an OU structure.

Whichever way is chosen, it is important to establish a standard method of illustrating the OU design chosen for an organization.

The first step in the design process is to determine the best method of organizing users, computers, and other domain objects within an OU structure. It is, in a way, too easy to create organizational units, and often domain designers create a complex structure of nested OUs, with three or more for every department. Although this approach will work, the truth of the matter is that it gives no technical advantages, and instead complicates LDAP directory queries and requires a large amount of administrative overhead. Consequently, it is better to start an OU design with a single OU and expand the number of OUs only if absolutely necessary.

Mapping the OU Design to an NT Resource Domain Layout

OUs in Active Directory can essentially serve as a replacement for NT resource domains. In a nutshell, this factor alone could make it easier to redesign your network environment. For example, consider the fictional company, CompanyABC, whose NT environment was composed of numerous NT resource domains similar to those shown in Figure 6.6. Each domain is administered by a local IT team.

Figure 6.6. Multiple resource domains in Windows NT4.

When migrating to Windows Server 2003, CompanyABC discovered the administrative advantages to organizational units, as shown in Figure 6.7, and restructured its environment with a single domain to take the place of the NT resource domains that previously existed.

Figure 6.7. Windows Server 2003 single domain with multiple organizational units.

The original purpose of resource domains in NT 4.0 was to separate groups of domain administrators from having control over each other's environment. This, in addition to replication concerns, is what caused so many IT environments to administer an enormous quantity of NT domains. Active Directory allows for these domains to be collapsed into an equivalent OU structure, while allowing for a much greater amount of control for the central IT structure.

Overuse of OUs in Domain Design

Administrators have heard conflicting reports for years about the use of organizational units in Active Directory. Books and resource guides and pure conjecture have fueled the confusion and befuddled many administrators over best practice for their OU structure.

The basic truth about OUs, however, is that you more than likely do not need as many as you think that you need. Add an OU to a domain if a completely separate group needs special administrative access to a segment of users. If this condition does not exist, and a single group of people administers the entire environment, there is often no need to create more than one OU.

This is not to say that there may be other reasons to create OUs. Application of Group Policy, for example, is a potential candidate for OU creation. However, even this type of functionality is better accomplished through other means. It is a little-known fact that Group Policy can be applied to groups of users, thus limiting the need to create an OU for this expressed purpose. For more information on how to accomplish this, see the section "Group Policies and OU Design" later in this chapter.

OU Flexibility

Domain designers are in no way locked in to an OU structure. Users can be moved back and forth between OUs during normal business hours without affecting domain functionality. This fact also helps designers to easily correct any design flaws that may have been made to the OU structure.

OUs were introduced as part of Active Directory with the release of Windows 2000. There are essentially no technical differences between the functionality of OUs in Windows 2000 and the functionality of OUs in Windows Server 2003. However, real-world experience with OU design has changed some of the major design assumptions that were previously made in Windows 2000.