What should an OU structure be designed around, and what rules of thumb keep it healthy?
Design OUs around administration and delegation (who manages what, which policies apply), not around the org chart for its own sake.
* An administration-driven OU tree: site first, then object type, at most three levels. *
OUs exist to link Group Policies and to delegate rights. So the question when drawing one is "which objects are managed the same way, and by whom?" Common designs split first by location (Switzerland, Poland, …) and then by object type (Users, Computers, Groups, Admins), because different sites often have different admins and computers need different policies than users.
Rules of thumb:
- Keep it simple: no more than about three levels. Deep trees make policy inheritance hard to follow.
- Consistent naming scheme for OUs and groups, so nobody has to guess what
GG_CH_ITis. - Plan it: in practice OU trees grow organically with every reorganisation, and that sprawl is where misapplied policies and forgotten rights come from.
An org-chart-only design breaks as soon as a department moves or is renamed, while an administration-driven design stays stable.
Go deeper:
Microsoft Learn: Reviewing OU design concepts — OUs exist for delegation, Group Policy and visibility, not to mirror departments (Microsoft's hard ceiling is 10 levels; three is the practical rule).- TechNet Magazine: Design considerations for OUs — the classic OU design patterns many companies still copy.