This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
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.
){kind=small}
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 you choose, it is important to establish a standard method of illustrating the OU design chosen for your 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 your 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 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 our favorite company, CompanyABC. Its 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 .NET 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 .NET 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 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, thus negating 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 .NET Server 2003. However, real-world experience with OU design has changed some of the major design assumptions that were previously made in Windows 2000.