OUConcepts

OUConcepts

---

An organizational unit (OU) is a type of container object in Active Directory that can contain other objects such as users, computers, groups, printers, or even other OUs. OUs are the smallest units in Active Directory to which:

• Permissions and tasks can be delegated (see Delegation earlier in this chapter)

• Group Policies may be applied (see Group Policy earlier in this chapter)

Using OUs

The general strategy for using OUs within a domain is to create a hierarchy of OUs that mirror the administrative functions and security needs of your company. When you're designing this structure, the top-level OUs should be carefully chosen so that they don't need to be changed afterward unless a major company restructuring occurs. Top-level OUs should reflect some relatively static aspect of your enterprise, such as the different departments, divisions, cities, states, or countries , or the different kinds of objects you administer in Active Directory, such as users, groups, computers, and printers. If your enterprise is multidomain in scope (such as those with a national or international presence), then consider standardizing top-level OU names for all domains in your forest.

Once you've standardized and created your top-level OUs in each domain, you can create child OUs beneath them, which represent more granular levels of administrative authority. You can then delegate authority to different branches of OUs or individual OUs and apply Group Policies to manage them. If you create a child OU within a parent OU, the child OU inherits the settings of the parent OU by default.

Here are a few examples that illustrate how you might structure OU hierarchies within a domain or across domains:

• A company that does business both locally and in other countries and that administers these two business functions with relative independence could have two top-level OUs called National and Foreign within its domain. Users, groups, computers, and printers could be placed in the appropriate OU, and authority could be delegated by administrators to trusted users in each business area.

• A similar arrangement could be set up for a company that deals locally with both the private sector (wholesale or retail) and the public sector (government): create two top-level OUs called Private and Public. Within Public you could create two second-level OUs called Wholesale and Retail. Place objects in different OUs; delegate authority and apply Group Policies as desired.

• A company that has several large stores in different locations could have a separate top-level OU representing each store. Within each store OU, you could create second-level OUs for Sales and Support. Within each second-level OU, you could create third-level OUs for Users, Groups, Computers, and Printers. Within the Printers OU, you could have two fourth-level OUs called Standard and Color. You could then delegate administrative authority over the Color OU to a trusted user who knows how to work with color laser printers.

A different way of hierarchically structuring Active Directory is to create a hierarchy of domains instead of OUs. You should:

• Use a domain hierarchy when different portions of your enterprise need complete administrative control over their local users and resources, as in a decentralized-administration model.

• Use an OU hierarchy within a domain when different portions of your enterprise need only limited administrative control over users and resources, as in a centralized-administration model.

You can, of course, use both methods and create OU hierarchies within domains that are part of a domain hierarchy. See Active Directory for more information on planning the structure of Active Directory.