As noted earlier, the basic difference between a built-in container and an OU is that OUs can have group policy settings applied to them. Another benefit is the fact that OUs can be nested, which provides benefits in terms of the inheritance of group policy. Note that an OU can be moved within a domain, just like any other domain object. Simple right-click the OU and choose to move it. Be careful about deleting an OU, however, since you will also be deleting all of the objects it contains (at least you get a warning!)
OUs exist primarily for the purpose of organization of resources according to administrative needs. For example, I can delegate control over an OU called Servers to the server support team, and not grant them administrative access to anything else. By the same token, I can apply policies to an OU (such as one containing all bank teller user accounts), which would allow me to lock down the desktop environments of these users specifically. As mentioned in a previous article, group policy can be applied at 4 levels, in the following order:
- OU followed by sub-OUs, if any
The order of application is very important. All group policy settings that apply merge together, unless there is a conflict. In the case of conflicting settings, the settings at the lower level apply. For example, if a setting at the domain level said that users were to have the Run command disabled, and a policy at the OU level specifically enabled it, the user would have access to the Run command. The order followed is the one described above. By the same token, it is possible that conflicting settings would exist in different policies applied to the same OU.
In this case, it is important to note that policies are applied from bottom to top. That is, first Policy A is applied, followed by Policy B, and then Policy C. As such, if there were a conflict between Policy C and Policy A, the settings from Policy C would apply. You can change the order of policies at a given level by using the up and down arrows on this screen.