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 their delegated OU (or in a domain other than NETID). UW-IT controls OU design in the general areas of the NETID domain.
There are different ways to design OU structures, but some work better than others. All of the user objects in the NETID domain are in a different OU 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 they are 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 many white papers addressing Group Policy which you wish to review or find 3rd party websites on this topic. 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 also be 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.