When designing an OU structure, the upper layers of the hierarchy should be based on the model for administration. For example, if the team responsible for the logical design of A.D. determines that a model for administration based on geographical location is needed, the upper layers of the OU hierarchy will reflect this model.

Be sure to base the structure of the upper layer OUs on something that will remain relatively static (geographic location as opposed to department or business unit). This will help to avoid a reorganization of the OU hierarchy in the near future.

The lower levels within the OU hierarchy should be created with specific administrative tasks in mind; in other words, what types of objects will users and groups be responsible for administering? How can these objects be grouped to allow for this administration? For example, if a group is to be responsible for printer administration within its location, an OU could be created for printer objects and delegation of authority assigned to the group. By nesting OUs within one another, you can create an OU structure that will meet the specific administrative requirements of the business.

You often read about nesting OUs and the warning that an OU hierarchy that is too deep can cause degradation in performance. So exactly how many levels of OUs can you nest before performance begins to suffer? The magic number hovers around 15. If you begin to create more than 15 levels, you can expect to see poor performance. This applies to both Windows 2000 and Windows Server 2003.