Designing Ou Structures

By Author: fiona
Total Articles: 191
Comment this article

You should design OUs for simplicity. Previous chapters emphasized the use of Network+ exam minimal numbers of forests and domains. However, it is likely that your domains will require a number of OUs to meet administrative requirements. The best practice is to begin with one OU and then add only those OUs that you can justify. Although you can have many levels of nested OUs, keep the number of levels to a minimum (fewer than seven) to avoid administrative and performance problems.
You can find a wide variety of advice on how many levels down an OU structure is acceptable. Three to seven levels are probably the most common recommendations. However, some suggest that ten levels is still acceptable. The way in which you choose to configure and use the OU structure is probably of more concern than the actual number of levels. For example, a five-level nested OU structure with different group policies applied at each level would actually be more cumbersome than a seven-level OU hierarchy with fewer group policies applied. Logon and startup times increase when the system has ...
... more group policies to evaluate. Further, if you set different permissions on each OU in the hierarchy, troubleshooting could be considerably more difficult than if you had a structure with uniform (inherited) permissions applied. The point to keep in mind is to organize the OU structure to minimize the number of changes in permissions and to reduce the number of Network+ benefits processed. When designing OU structures for your organization, it's also important to keep the following in mind:
OUs are not security principals. That is, you cannot assign access permissions based on a user's membership in an OU. Access control is the respon?
sibility of global, domain local, or universal groups.
Users will not use the OU structure for navigation. Although users can see the OU structure of a domain, the most efficient way for users to find
resources in Active Directory is to query the global catalog. Therefore, you should define OUs "with administration, not users, in mind.
An OU is a container used to organize objects within one domain into logical administrative groups. OUs can be added to other OUs to form a hierarchical structure.
There are three reasons for defining an OU: to delegate administration, to admin-ister Group Policy, or to hide objects.
Design OUs with administration, not users, in mind. Users will not use the OU structure for navigation. Design OUs for simplicity. The best practice is to begin with one OU and then add only those OUs that you can justify.
OUs are not security principals—you cannot assign access permissions based on a user's membership in an
MCITP certification. Access control is the responsibility of global, domain local, or universal groups.