Organizational Units (OU’s) are containers within domains. They are the elements of hierarchical structure within domains. The OU hierarchy does not need to reflect the departmental hierarchy of the organization or group. OUs are created for a specific purpose, such as the delegation of administration, the application of Group Policy, or to limit the visibility of objects.
Sample methods of how can you create your company OU levels.
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 additional 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 they 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 down-level 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 Group policy there are separate sections for computers and users. 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 Publishing 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 hierarchy 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. Apart from that this will simply nightmare to mange by the administrator J
A popular OU Design
With the number of companies I have work on designing OU structure one simple rule is to keep OU structure simple and not to let it go too deep level. Try to have maximum of 3-4 sub OU level. This can be categorized in Geographical level or Department level or unit level.
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.