OU Design Guidelines
As the Windows administrator of your department, you
should plan your Organizational
Unit (OU) structure prior to implementing your OU or
domain. This document was created to assist Windows
administrators in the design of their portion of the Active
Directory (AD), i.e. in the child domain or OU within a
child domain. No OU design is allowed in the root domain.
There are different ways to design OU structures, but some
work better than others. All of the user objects in the
Stanford Windows Infrastructure are in a different domain
than your computers will be, so as you investigate different
designs, you will see that basing your OU model on user
objects is less important than on the computer objects. The
most important thing to keep in mind when designing your OU
is the administrative purpose that OU will serve.
OUs are directory containers for directory objects (i.e.
user, computer, and policy objects). OUs can contain other
OUs to 63 levels. The primary purpose of an OU is to make
administration easier in terms of management and delegation.
You will want to keep in mind that every OU you create will
primarily serve to help a Windows administrator manage a
common set of directory objects for which he/she is
responsible. OU administrators will primarily use OUs to
distribute Group
Policy Objects (GPOs), which are a set of common
configuration settings like distributing software or changing
the user environment, to help manage directory objects such
as computers and users. These GPOs are only applied to
directory objects within that OU or within OUs nested beneath
that OU. Directory objects can only be in one container, but
don't forget that the object may inherit GPOs from parent
containers, so your model needs to be carefully designed.
As you consider the following design models, keep the
following criteria in mind:
First, are there groups within your department that need
to be managed differently? Do administrators, staff, faculty
or student employees have different levels of access to their
own workstations? Are restrictions based on the computers or
the users?
Second, are there distinct political or geographic
divisions within your group that have different computer
management needs? Make sure your design is based on the
management of resources and users and not solely on political
boundaries. Politics and geography can be useful in guiding
your design, but the goal of OU design is to make
administering your resources easier.
Third, familiarize yourself with the settings available in
GPOs. They may contain more, or less, than you think they do.
Your OU design will be more effective if you are familiar
with the set of configuration settings that Group Policy
Objects can modify, the GPO processing order, and the
loopback processing functionality. Microsoft has written
7 or more white papers addressing Group Policy which you may
wish to review. The best, in terms of breadth and technical
detail, is perhaps
Windows 2000 Group Policy. Our site has an overview of loopback
functionality and processing order which better explains
how this functionality works. A short overview of Group
Policy functionality is as follows: Group policy objects
(which are themselves a directory object) are applied to a
directory container (i.e. a site, domain, or OU), and affect
all objects within that container. Fortunately, one can apply
ACLs
to a GPO and limit which directory objects (i.e. user objects
or computer objects) within that container can read and apply
the GPO. Loopback processing is also applied to a directory
container, and specifically affects users who log into
computer objects within that container. This allows an
administrator to apply GPOs on users based on which computers
the user logs into.
Fourth, keep in mind that differing levels of access to
resources (file servers or printers) are controlled directly
at the computer level via ACLs using security groups, so
file/print resource management should not figure into your OU
design planning. This means you should not create an OU
structure based on a group's permission to a file or print
resource.
Fifth and most important, ask yourself: What
administrative purpose does this potential OU serve? Are
there Group Policies I want to apply to the directory objects
within this OU? Does our administrator need this additional
OU to more effectively manage computers and users or is it
simply an arbitrary division?
Sample Designs
There are hundreds of ways to design an OU structure, but
four basic designs have proven themselves useful over time.
They are:
-
Political/Functional
-
Geographic
-
Resource-based
-
User classification
Each of these designs has merits and drawbacks. You should
look at which design(s) fit your environment. In many cases
you'll need a combination of two or more designs. The size of
your department, and the way it is organized, tend to have a
significant effect on the design(s) you choose.
Political/Functional Design
A functionally based design is useful for larger
organizations and for organizations where different
functional groups have different computing needs or
environments.
While this design seems like a natural choice for many
people, it usually does not reflect the IT management needs
of smaller departments. Larger departments that use this
design should consider implementing it in conjunction with
one of the other designs. For example, each of the subgroups
of the department could be further organized by resource or
user classification. Some combined designs will be shown
later.
Geographic Design
Departments that are spread across campus or between
campus and other facilities may want to consider a geographic
design. This design is only useful if geographic boundaries
also represent IT management divisions.
This design is obviously less useful for units housed in a
single location, or when location per se does not affect how
IT is managed. As with the political/functional design, this
design can be used in conjunction with other designs, such as
the resource-based design.
Resource-based Design
Often it is best to manage computing resources by type of
resource: desktop computer, server, printer, etc. This design
is most useful when all resources of a given type, like
servers, are managed in the same way.
These divisions can be sub-divided if a resource, like
workstations, is generally managed in a certain way, but a
few of them have additional management requirements. Computer
labs and public kiosks are excellent examples of additional
types of resource-based divisions. These sub-divisions may
rely on one of the other OU designs, especially the user
classification design.
User Classification
Resources can alsobe managed based on users' jobs or
functions within a department.
This design allows for differing levels of restriction
based on users' needs. You'll notice that there can be
overlap between the resource-based classification and the
user-based classification because, for example, students may
typically use computer labs. This is a useful design for
smaller departments that have no need for political or
geographic divisions and that maintain mostly desktop
computers (reducing the need for a resource-based
design).
Hybrid Designs
The previous design can be combined in a number of ways
for more granular organization. Hybrid designs are most
useful for larger departments attempting to manage large
numbers of computers. Here are some examples of hybrid
designs:
Resource-User Hybrid
Geographic-Resource Hybrid
Re-used with permission from Stanford University for which
Brian Arkills originally wrote this documentation, http://windows.stanford.edu/docs/OUDesign.htm,
that document was adapted from OU Design Suggestions for
Windows 2000 Administrators at UCB, University of Colorado,
http://www.colorado.edu/its/windows2000/adminguide/OUdesign.html.