I have been doing Active Directory and Group Policy work for a while now and I have developed my own set of rules that I try to use where ever possible. So below I have written down all my rules in no particular order for you to go over and use for yourself. You may only chose to use only some of these rules or you might want to use them all depending on your circumstance. This is a two part series where I will first talk about designing you Active Directory Organisation Unit structure and then in part 2 (Best Practice: Group Policy Design Guidelines – Part 2) I will discuss some more ideas for applying Group Policy to the OU structure.
I want to be clear that these are only guidelines and not rules that need to be strictly adhered to. In almost all case there are exceptions to these guidelines and you might even find your self implementing them in a hybrid approach. I intend for this web page to be updated on a regular basis as none of these rules are set in stone and thing obviously change all the time.
Active Directory Organisation Unit Design Guidelines
Before you begin
Before you begin the process of designing your Group Policy (and AD) structure you should first try to fully understand the requirements of the environment. Below are some points that I recommend that you find out before you begin:
- How is the company structured
- Where are the physical sites
- Who support the organisation
- What are the support boundaries (e.g. Location and/or Workstations and/or Servers )
- What are the computer types
- Highly Secured
- Standard SOE
- Process Control/Automation
- Server Roles (e.g. Exchange, SQL or File Server)
- Network Topology
- Bandwidth / Latency
- Who will be responsible for Group Policy changes
- What are the security requirements (password policy, auditing etc.)
- What is the change management process
- What are the auditing requirements for Group Policy
Keep it short
When naming your Organisational Unit make sure the name you are using are short and to the point. There is technically nothing wrong with having long OU names but it is a pain to document and just leave you open to more chance of references then name wrong as their are more characters to type.
Bad Example |
Good Example |
Be intuitive
Naming OU to something that is intuitive is good for new starters in the organisation. If you name a OU “OOG†a new starter in your organisation might not realise that this is the three letter international designation for Coolangatta AirPort which is the same suburb where your office is located. I know this is in conflict with rule 1 however it is also a balancing act your will have to carefully tread.
Bad Example | Good Example |
Most to least significant from left to right
OU structures in AD are hierarchical therefore you need make your design fit to this structure. When deciding how your want to organise your OU structure you are probably going decide to make it either organisational or geographical. This is most important when you are going to a Geographical design as it is a physical impossibility to have one location located in two difference cities,states,countries or regions.
Bad Example | Good Example |
Go wide not deep
As a general rule you should only start creating another OU level if you are actually going to do something to that OU (e.g. delegate security or apply a group policy). Don’t be tempted to create an elaborate structure to organise you AD object if there is not reason to do so. Having a deep OU structure also makes it very difficult to delegate security in the same delegating security on multiple folders deep to folder on a file share.
Bad Example | Good Example |
Be consistent
Don’t mix your terms when naming our OU Structure as this leads to confusion if for IT admins that leads them to believe that something might be different about the two OU’s where they actually contain the same type of objects. The example below shows how two different sites calls the OU for the computer in the organisation Workstations and Desktops.
Bad Example | Good Example |
Blog Post: Best Practice: Active Directory Structure Guidelines – Part 1 http://bit.ly/bVkygi
Blog Post: Best Practice: Active Directory Structure Guidelines – Part 1 http://bit.ly/bVkygi
Best Practice: Active Directory Structure Guidelines –Part 1 http://bit.ly/cICPDp
RT @xenappblog: Best Practice: Active Directory Structure Guidelines –Part 1 http://bit.ly/cICPDp
RT @xenappblog: Best Practice: Active Directory Structure Guidelines –Part 1 http://bit.ly/cICPDp
OdliÄno Å¡tivo za sve koji su odgovorni za strukturu AD-a! http://fb.me/zUZU5U5w
@Froosh u mean? https://www.grouppolicy.biz/2010/07/best-practice-active-directory-structure-guidelines-part-1/
. @Mixailovich Err, doh, yes that one too 😉 http://bit.ly/cJApsO
Best Practice: Active Directory Structure Guidelines – Part 1 http://bit.ly/9oDQJq
Hi Alan, great article – nice clean overview of this difficult subject.
One question about the different graphic files you created, for example this one: https://www.grouppolicy.biz/wp-content/uploads/2010/07/image_thumb78.png
How did you create it – Visio?
And how did you get the graphic elements used..
Need it to document our network-layout at work.
-Jonas, Denmark
Its 100% Visio 2010…
@thommck There are some great ideas about Active Directory structure (OUs) in this series from @alanburchill. http://bit.ly/ebQlLS
Best Practice: Active Directory Structure Guidelines – Part 1 http://t.co/5A6ak0V via @alanburchill
Good Article
I wanted to include some informtaion about the naming of OUs where it says :”When naming your Organisational Unit make sure the name you are using are short and to the point…” There may be technical limitations that may affect long names.
During binds to the directory, simple LDAP bind operations limit the distinguished name (also known as DN) of the user to 255 total characters. If you attempt a simple LDAP bind with more than 255 characters, you might experience authentication errors
Active Directory Maximum Limits – Scalability
http://technet.microsoft.com/en-us/library/active-directory-maximum-limits-scalability(WS.10).aspx
Best Practice: Active Directory Structure Guidelines – Part 1 http://t.co/3OBagYfF via @alanburchill
Best Practice: Active Directory Structure Guidelines – Part 1 http://t.co/LDCB4xuI via @alanburchill . useful as I am restructuring our AD.
Best Practice: Active Directory Structure Guidelines
http://t.co/BNi4AcIO
Best Practices al diseñar o reorganizar AD http://t.co/MuCB4uLB
Best Practice: Active Directory Structure Guidelines – Part 1: http://t.co/wVwTezBr
Best Practice: Active Directory Structure Guidelines – Part 1: http://t.co/nTIzr8gs
Thank you this is very much appreciated. I am working on a deployment for a organization with 4 distinct locations that includes a marriage to Apple OpenDirectory as well as FreeBSD OpenLDAP. Having a well thought out explanation like this is fantastic. It has helped me explain the complexities of designing the right solution to all members of the team. I still have not drafted the final plan but it is giving some great ideas so hopefully I can achieve this shortly.
Cheers,
Mikel King
Apple Open Directory?? Don’t go there, it’s a trap! 😉 Recommend to use AD + extend schema to support OS X
I’m new to Active Directory and this is very usefull.
I have a question about the Resource Structure Example image sample above .
I know that it is only an example but :
the Groups OU contains Roles and Resources groups.
What they means?
Does Roles contains groups like Officers, Employees, etc?
Thank you very much.
Hi,
i have configured one domain. i want configure some
group policy by organzation units. i have created ou.and i move some user in that ou. but i dont know how to
link this ou with group policy i did try many times but i did not sucess any one help me…
“you probably have a delegated cretin duties to specific teams”
WTF?
Best Practice: Active Directory Structure Guidelines; Part 1: http://t.co/Lzspv4Kt
Best Practice: Active Directory Structure Guidelines – Part 1: http://t.co/dp4nSVFdUw
Very Nice tanQ grouppolicy http://chatflash.ir/
Very nicely explained. Thank you good sir.