One of the key benefits of Active Directory
is the way in which it can bring organization to complex network
environments. Before you can begin to implement OUs in various
configurations, you must plan a structure that is compatible with
business and technical needs. In this section, you'll learn about
several factors you should consider when planning for the structure of
OUs.
1. Logical Grouping of Resources
The fundamental purpose of using OUs is to
hierarchically group resources that exist within Active Directory.
Fortunately, hierarchical groups are quite intuitive and widely used in
most businesses. For example, a typical manufacturing business might
divide its various operations into different departments like these:
Each of these departments usually has its own goals
and missions. In order to make the business competitive, individuals
within each of the departments are assigned to various roles. Some
types of roles might include the following:
Managers
Clerical staff
Technical staff
Planners
Each of these roles usually entails specific job
responsibilities. For example, managers should provide direction to
general staff members. Note that the very nature of these roles
suggests that employees may fill many different positions. That is, one
employee might be a manager in one department and a member of the
technical staff in another. In the modern workplace, such situations
are quite common.
All of this information helps you plan how to use
OUs. First, the structure of OUs within a given network environment
should map well to the business's needs, including the political and
logical structure of the organization, as well as its technical needs. Figure 1 shows how a business organization might be mapped to the OU structure within an Active Directory domain.
When naming OUs for your organization, you should keep several considerations and limitations in mind:
Keep the names and descriptions simple.
The purpose of OUs is to make administering and
using resources simple. Therefore, it's always a good idea to keep the
names of your objects simple and descriptive. Sometimes, finding a
balance between these two goals can be a challenge. For example,
although a printer name like "The LaserJet located near Bob's cube"
might seem descriptive, it is certainly difficult to type. Also,
imagine the naming changes that you might have to make if Bob moves (or
leaves the company)!
Pay attention to limitations.
The maximum length for the name of an OU is 64
characters. In most cases, this should adequately describe the OU.
Remember, the name of an OU does not have to uniquely describe the
object because the OU is generally referenced only as part of the
overall hierarchy. For example, you can choose to create an OU named
"IT" within two different parent OUs. Even though the OUs have the same
name, users and administrators are able to distinguish between them
based on their complete pathname.
Pay attention to the hierarchical consistency.
The fundamental basis of an OU structure is its
position in a hierarchy. From a design standpoint, this means that you
cannot have two OUs with the same name at the same level. However, you
can have OUs with the same name at different levels. For example, you
could create an OU named "Corporate" within the North America OU and
another one within the South America OU. This is because the fully
qualified name includes information about the hierarchy. When an
administrator tries to access resources in a Corporate OU, they must
specify which Corporate OU they mean.
If, for example, you create a North America OU, the
Canada OU should logically fit under it. If you decide that you want to
separate the North America and Canada OUs into completely different
containers, then you might want to use other, more appropriate names.
For example, you could change North America to U.S. Users and
administrators depend on the hierarchy of OUs within the domain, so
make sure that it remains logically consistent.
Based on these considerations, you should have a good idea of how to best organize the OU structure for your domain.
