Operational Unit Design
The next hierarchical level is the operational unit (OU)—useful for group policy and rights delegation. Because the business model may change frequently, or be complex enough so that an OU model based on it would require several OUs with interlocking rights, most recommendations are not to have OU design follow business structure. You certainly don’t want to have to change directory structure for every business redesign. In all OU models, the idea is to minimize administration headaches, so that all objects inside an OU are managed by the same group or administrator. Then that group can be granted the necessary rights for everyone in that OU.

Three models of OU design are geographical, functional and object type. The geographical and functional models are as the designation implies: based on physical business location or function. The object type structure splits the OUs so that similar objects are placed closely. All DCs, all servers, all printers, all users, etc., are in their own OUs. Hybrid models of any or all of these three types are also possible, depending on how network user administration is easiest.

Other considerations for designing OU structure include structuring them so that the same security policy-requiring objects are grouped together. An extension of this thought is the recommendation to group admins away from the hoi polloi so that admin objects, such as restricted servers, may only be seen by those OU members—the admins. Be aware that objects within an OU are accessible by forest and domain admins, though should be assigned an owner, who is responsible for child objects, GP assignments and rights delegation. This non-exclusive access is an example of autonomy, versus isolation, which would be exclusive access.