It never ceases to amaze me just how widely the advice given on OU structures within Active Directory design various. Although OUs were one of the Active Directory components that were originally introduced with Windows 2000 almost a decade ago, there still does not seem to be any clear guidance on how they should be used. If you search the web for information about OU design, you will find lots of contradictory information even among Microsoft’s own publications.
In a way I can understand why all this contradictory information exists. The Active Directory is designed to be extremely flexible in structure. Being that OUs are one of the top level Active Directory components, they too are very flexible in nature. When you combine this flexibility with the fact that each administrator has their own way of doing things, it seems only natural that a lot of contradictory advice would be given.
Before I Begin
Before I get started talking about OU design, I just want to say that the advice I am about to give you is just that; advice. Like I said, there is loads of contradictory information out there about the way that OUs should be designed. Therefore, the advice I am about to give you may or may not adhere to industry best practices, because to be quite frank, I’m not even sure that there are any documented industry best practices for OU design that are set in stone. Having said that, the advice is based on my own personal experience of working with the Active Directory since it was first introduced with Windows 2000.
My OU Design Philosophy
When it comes to Active Directory design, I like to take a less is more approach. While there are certainly situations that call for creating lots of OUs, I tend to like to keep things as simple as I can, and limit an Active Directory design to using a single OU whenever possible. Of course not everybody uses this approach.
I remember attending a session at TechEd a few years ago in which the speaker was trying to demonstrate the versatility of the Active Directory. In that design, OUs were used almost as a substitute for domains. The Active Directory had been configured so that there were various groups of users, and each resided in its own OU. Similarly, rather than creating resource domains, the speaker had created OUs for various groups of computers as well. In fact, practically everything existed in its own OU. Since that time, I have also seen this type of design used in the real world on several occasions.
My personal take on this type of design is that everybody has a different way of keeping themselves organized. If this type of design works for you, and helps you to more efficiently manage your network, then there is nothing wrong with using it. Having said that, I have only seen a few networks over the years on which there was any technical advantage to using this type of design.
Most of the time when I have seen this technique used in the real world, it has appeared as though the design was implemented for the sake of additional complexity. I cannot help but wonder if perhaps those companies hired high priced consultants to come in and set up their Active Directories, and the consultants created a design that was overly complicated just for the sake of making it look like the design was worth the money that the company was spending.
As I said before, there are situations that do warrant using multiple OUs. This is particularly true in situations in which there are multiple administrators, and each administrator needs to be delegated control over a different portion of the network.
I have read various articles that suggest that the need for multiple group policies is another good reason for creating multiple OUs, and in some situations this is true. Keep in mind that the OU is the highest level at which a group policy can be applied, but it is not the only place where you can apply a group policy. Group policies can also be applied at the site, domain, and local computer levels of the Active Directory hierarchy.
One of the reasons why I think that OUs tend to be overused is because a lot of administrators seem to be under the assumption that when a group policy is applied to a site or to a domain, that the policy applies to all of the objects in that site or domain. This is normally true, but you do have the option of creating a group policy that only applies to a subset of a site, domain or even an OU.
If you take a look at Figure A, you can see that I have opened Active Directory Users and Computers, right clicked on a domain, and chosen the Properties command from the resulting shortcut menu to reveal the domain’s Properties sheet. If you look at this properties sheet’s Group Policy tab, you can see that you have the option of assigning multiple group policies to the domain. Normally, when you do this, the policies are cumulative in nature. The policies combine together to form the resultant policy. Notice in the figure that there is a Properties button that you can click after you select an individual group policy. When you click this button, Windows reveals the group policy’s properties sheet. This properties sheet contains a Security tab that you can use to assign rights to the policy. It is possible to prevent the policy from applying to certain groups of users by setting an explicit denial. By using this technique, you can have separate group policies to apply to various groups of users and computers without having to create additional OUs.
Figure A: You can use an explicit denial to prevent a group policy from applying to certain groups of users or computers
Right about now, you might be wondering what I really have against creating multiple OUs. There are a couple of reasons why I do not like using multiple OUs unless I have to. Maybe it’s just laziness on my part, but the first reason why I like to try to stick to using a single OU in an Active Directory design is because having multiple OUs tends to complicate LDAP queries. This is especially true if you to create a nested OU structure. Granted, a complex structure like this has little to no effect on the end users. After all, how many of your users even know what an LDAP query is? The point is that creating an excessively complex OU structure can make your job more difficult.
Another reason why I like to stick to a single OU model is because once you have multiple OUs in place, you will eventually find yourself having to move objects between OUs. Active Directory makes it easy to move objects between OUs, but the group policy settings that apply after doing so can sometimes be surprising unless you have carefully planned the move in advance. As an administrator, I don’t like surprises, so I try to stick with a simple model that will be less likely to produce unexpected group policy combinations when I move objects around.
Conclusion
As I said before, there is no right or wrong way to create an Active Directory design. The nice thing about the Active Directory is its flexibility. Windows makes it easy for you to start out by creating an Active Directory that consists of a single OU. If over time you realize that this model no longer works for you, it is easy to create additional OUs.
