{"id":1206,"date":"2008-09-17T08:00:23","date_gmt":"2008-09-17T08:00:23","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/2008\/09\/active-directory-design-considerations-part-3-organizational-units.htm"},"modified":"2008-09-17T08:00:26","modified_gmt":"2008-09-17T08:00:26","slug":"active-directory-design-considerations-part-3-organizational-units","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2008\/09\/active-directory-design-considerations-part-3-organizational-units.htm","title":{"rendered":"Active Directory design considerations: part 3 (organizational units)"},"content":{"rendered":"

In the previous post in this series of posts about design considerations for Microsoft Active Directory (AD)<\/a>, based around the MCS Talks: Enterprise Architecture<\/a> series of webcasts, I looked at forest and domain design<\/a>. This post continues with a look at organizational unit (OU) structure.<\/p>\n

The OU structure is not exposed to users but can make a big difference to the management of Active Directory objects. It is very flexible and therefore easy to change but change costs money and has a potential to impact on production applications (so should be avoided where possible.<\/p>\n

Consequently, there are a couple of guiding principles to be followed:<\/p>\n

    \n
  1. Design the OU structure for the delegation of administrative responsibility.<\/li>\n
  2. Design the OU structure for group policy object (GPO) application.<\/li>\n<\/ol>\n

    Delegation of administration should be given priority, because GPO application can also be filtered using security groups, but Microsoft does also recommend the following:<\/p>\n