Designing an OU Structure
Designing the Organizational Unit (OU) structure for your environment is not a task to take lightly. Some administrators will simply group all users in one OU and forget about them, while others may take the OU design to an extreme, often ending up with unnecessary OUs. For an administrator, the first tendency when creating the OU hierarchy may be to mimic the company's organization chart, but this often isn't the ideal setup. OUs are generally created with a specific purpose - to group a collection of objects together for administration.
One might look at the company's organizational chart to start designing the OU structure. Many times this is inefficient because the organization chart has no regard for where employees may be physically located. You may have offices across the globe and need to be able to manage the groups accordingly, applying policy or delegating administration to a particular site. If you chose to follow the organizational chart, this could prove quite difficult. If you are centralized and care to deploy policy or administration by group or business unit, then this model could prove quite helpful. Consider all of the options and plan before deploying an OU structure.
As you begin the design, you should begin with the top-level OUs first. Top level OUs should be based on something that is relatively static in the organization, such as the geographic locations or business units. Once you have established the top-level OUs, it is best to not change them later unless absolutely necessary.
Why create an organized OU structure? The answer to this can be many, but we will specifically look at two: Design based on delegation of administration, and design based on Group Policy application.
The first design is based on delegation of administration. This is a common task, and one that is relatively easy to setup. Think of your OU structure like a folder structure, where you are setting specific permissions for users on those folders, and the ones below. This is great for allowing a user, or group of users, the ability to administer all or specific settings for an OU.
How would this work? Say you have three offices, one being your corporate office where the majority of your staff works, and two satellite offices with a small number of users. You decide that your junior members of the IT staff should be able to change passwords for the satellite offices, but you aren't ready to allow them to be members of the Domain Admins group. If you have designed your OU structure to reflect the geographical location of your offices, you can simply delegate the administration of those OUs to the junior members of the IT staff, either specifically by name, or creating a group and delegating those OUs to the group. You can pick specific administrative items to delegate, so you don't have to delegate full control of the OU.
The second design is based on application of group policy. This can also be thought of as a file structure, where you inherit settings from the parent. You will create and link group policy objects (GPOs) that you want to apply to everyone at the top of the domain, and this will be inherited by child objects. There is a caveat to this - you can always block inheritance on an OU. This will keep inherited GPOs from applying to the user and computer objects in the OU.
Much more information is warranted to be able to truly grasp the ins and outs of planning and implementing your OU structure. A good article was written in the May 2008 issue of TechNet Magazine, which can be read here - Designing OU Structures that Work - https://technet.microsoft.com/en-us/magazine/cc462797.aspx
There's also a great deal in information readily available on the Microsoft TechNet site:
https://technet.microsoft.com/en-us/library/cc770806.aspx
+sgoad