Jay Paloma's Tech and Music Blog

Sometimes, this writer can no longer distinguish between the two.

Active Directory Organizational Unit Design Principles

with 13 comments

This blog entry was written on July 2006. Since much of it is still relevant in today’s Windows Server 2008 R2 Active Directory, I took the liberty of reviewing and reposting it in my new techblog. – Jay Paloma

Organizational Units (OU’s) are containers within domains. They are the elements of hierarchical structure within domains

Photobucket - Video and Image Hosting

Characteristics of the Organizational Unit (OU)

  • OU’s offer the best method to organize the hierarchical structure in Active Directory. There is a big temptation to reflect the organizational hierarchy in the domain, but as we learned in the Domain Design section, this is not a good idea. The Organization Unit would be best suited for the job.
  • OU’s can easily be renamed, moved, and deleted. Using Active Directory Users and Computers (ADUC), manipulating OU’s can easy. Renaming the OU does not affect the objects inside that OU. Moving the OU moves all objects and containers inside that OU. Here’s the tough one: deleting the OU deletes all containers and objects inside that OU. So better be careful!
  • Maintaining the organizational hierarchy using OU’s has less impact on performance compared with maintaining it in domains. While the domain requires at least an addition of at least two domain controllers per additinal domain, the OU does not have that requirement. Additional OU’s also don’t have additional replication overhead, well, enough replication overhead to replicate the hierarchy of the OU in the domain, but that’s it.
  • Organizational Units are bound within the domain. All organizational units do not exceed the domain boundary. Similarly named OU’s in different domains are independent of each other. To put it in another way, all domain controllers in the domain contain the same set of OU’s for that domain, and only for that domain.
  • The OU offers a good administrative boundary. Permissions to Active Directory objects can be delegated at the OU level, and have them inherited in the containers and objects inside that OU.

Reasons to create Organizational Units

  • Delegate administrative control. Administration of Active Directory objects can be done in a per OU level, and these permissions by default are inherited by containers and objects in the said OU.
  • Implementation of Group Policies. Group Policies can be implemented, among others, on the OU level. Like administrative permissions, they are also inherited by downlevel OU’s and objects. We will take a look at group policies in the next section.
  • Object organization in Active Directory. The Active Directory domain can contain millions of objects. It may be very hard to locate for a specific object among millions if there was no mechanism to organize them.

Some OU design principles

  • Simplicity is (still) the key. Although we can create as many OU’s as we need, it would be important to make sure that they are in the simplest way possible. A domain with hundreds of OU’s may no longer be supportable. Also, the deeper the OU structure, the longer it takes for a computer to start up or a user to log on because of processing of Group Policies in the depth structure of the containers. A general rule of thumb is an OU structure that does not exceed a depth of 5 OU’s (3 is a conservative figure).
  • Have knowledge of the Customer’s political and organizational structure and boundaries. It is important that the organizational and political structure of the Customer is to be understood by the infrastructure architect from day one. As mentioned, we can move objects from one OU to another. However, doing so would change the object’s group policies applied to it, and may not be a wise move after rolling out the said GPO’s.
  • Consider separating the user from the workstation. In the next section we’ll take a look at Group Policies, and we will learn that there can be separate Group Policy Objects (GPO’s) for User and Computer objects. This makes it possible to also separate the computer objects from the user objects accessing them, since there might be a separate group of administrators managing them anyway.
  • Consider separating the service from the server. In the same way that user objects can be separated from their workstations, the services can also be can be separated from the server. This is because Group Policies can also control which services are running on a specific machine. Example, all computer objects of web servers running IIS can be placed on one OU, and apply to that OU a Group Policy Object that ensures that the World Wide Web Publising Service starts automatically on those servers, while is Disabled for the rest.

Be careful with complex OU structures

Have a principle on OU design, at least on the top levels of the OU. This way, objects won’t get “lost” in an intricate and highly complex OU design. It’s very easy to “lose” an object after creating a complex OU hierachy with matching delegated permissions to boot, by successfully finding an object in the Find function in ADUC, but not being able to access the same because delegated administrative control bars the currently logged on user from accessing either the object itself or the container (or one of the containers of the container) holding the said object. In other words, the object exists, but is not accessible, and uniqueness rules prevent us from creating a similarly-named object.

A popular OU Design

Quite a number of companies I’ve worked with follow this OU hierarchical model (see picture above): the topmost level is is the geographical locations, then the layer under that would be the administrative types (servers/workstations/user accounts). Two levels, some more than two, but more or less following that pattern. This model offers the benefits of having a geographically independent set of administrators, and sub-administrators for each geographical location managing user accounts, servers and workstations. Administrative control can be delegated off to the geographical administrators, and at the same time to central administrators if ever a centralized administration is preferred.

The same is true for Group Policy implementation. A central group policy applied at the domain level or separate group policies applied separately for OU’s in either the geographical or administrative OU levels make it centralized, or decentralized respectively.

In short, this model enjoys the possibility of having either centralized or decentralized modes of administration and group policy application. If your organization is one that has multiple geographical locations per domain, consider this model.


Written by jpaloma

January 19, 2011 at 11:31 AM

13 Responses

Subscribe to comments with RSS.

  1. […] Active Directory Organizational Unit Design Principles […]

  2. Hello, I would like to ask the following:

    Let’s say you have a company X, which is divided into 5 departments, A1, A2, A3, A4, A5 where each department has at least 5 users(pcs). Assuming you add these departments in OU’s, eg. A1 is named as OU_Finance, the A2 is OU_IT and so on. You can see in your AD that they are divided in these OU’s, but will the users (pcs) be able to see that in their “My Network Places”?

    I would like to know if this is possible, as we used to have workgroups in our office but now we are moving into AD and we cannot see our departments sorted in “My Network Places”, rather we see all users in the same place.


    April 24, 2012 at 4:54 PM

    • the OU structure is usesful for organizing AD objects for management and application of group policies. They are not used to group computers in My Network Places.


      April 24, 2012 at 8:45 PM

      • Is there any way that you can use the OU’s and somehow group the computers into specific groups?


        April 24, 2012 at 11:29 PM

    • Yes you can also use the AD groups to group your machines as well


      December 31, 2012 at 9:24 AM

  3. Good read, ty


    June 22, 2012 at 12:00 AM

  4. Hello,
    I am re-designing our AD. Currently we are looking at having 1 OU for each department with a Users OU and Computers OU in each department OU. I am relatively new to the field and only have my educational experience to go off of. From what I remember the setup should be 1 OU for each department with a group and computers OU in each department OU. Essentially, what is the difference between adding a group to an OU, assigning members through the group, then attaching Group Policies to the group and creating an OU with the users for the department and applying group policies to the Users OU?

    Zach Kuehl

    July 17, 2012 at 5:58 AM

    • Groups are created because you use them to create permissions (ACL)
      OUs are created (and users grouped into OUs) so that GPOs can be applied.


      December 31, 2012 at 9:28 AM

  5. […] TechNet: Creating an Organizational Unit Plan Group Policy Central: Best Practice: Active Directory Structure Guidelines – Part 1 Group Policy Central: Best Practice: Group Policy Design Guidelines – Part 2 Jay Paloma’s Tech and Music Blog: Active Directory Organizational Unit Design Principles […]

  6. […] Active Directory Organizational Unit Design Principles […]

  7. Why must you be careful when changing the organizational unit membership of an account?


    October 18, 2013 at 8:10 AM

    • By itself moving a computer or user account from one OU to another is a very straightforward process. However, ensure that the Group Policies that will be applied to the object in the destination OU is acceptable from a security and operability standpoint.


      October 18, 2013 at 10:40 AM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: