Active Directory Organizational Structures

Thanks for looking at this question! Without going in to too much detail, we are interested in redesigning our AD structure to serve our support and management needs better.

Currently we have ~30some physical locations and 1 domain. We have two separate 'business units' which require different things - backgrounds/login screens, software, mapped drives, et al.

The structure of this essentially starts with a top level then the 2 branches then 20some sub-OU's (for each location, some exist on in both organizatiosn). This structure essentially appears twice with minor differences, once for user objects, once for computer objects.

Now for the most part each site has nothing specific about them (except on the user side we have subgroups for 'job roles' to grant permissions).

My question is this: Is there a standard design approach for an organization like this -which is expecting to grow steadily with new locations? What are the best resources available for determining how to design AD structures (i.e. would a domain and subdomain be ideal? 2 separate domains?) And, lastly, any tips or considerations that are worth looking in to which could help simplify management, design, or deployment of this.

Thanks again for any help!!
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

Will SzymkowskiConnect With a Mentor Senior Solution ArchitectCommented:
When you are designing your AD structure there are some best practices but ultimately it depends on how you want to distribute policies among different business units in your company.

Some of the design high level best practices I would follow would be keeo your OU design Verticel not Horizontal. Meaning it do not create Sub OU's if they are not necessary. Doing so creates a lot more complexity and longer policy wait times when users are down 8 or 9 sub OU level's (i have seen this scary).

Separate your Service Accounts in a separate OU where only the default domain policy applies. Also when using/creating service accounts it is a good idea to have a prefix "svc_name" so that you can easily identify an account, as it could get moved to another OU or mistakenly used.

Specifically for OU structure I like to use the below
Location (miami)
--Department (HR)
Only going down 2/3 sub OU's. If you have to go further than that you definitly can I would just keep the depth of the OU structure to a minimum and do not create unnessassary OU's.

The Rule of thumb i have for Sub OU's is that if you are not applying specific policies for the additional Sub OU's then don't create one.

There is lots more I could go over but really would be pointless as your company might have different needs but thoughs are some of the things i take into consideration when designing new structures for OU's. It is also a good idea to being a business person into a meeting for OU design as they know the LOB (line of business) best.

Take a look at the below links which also provide some great information on OU design and structure.

Design OU Structures

OU Design with GPO's to consider

Mike KlineCommented:
Try to stick with one domain if you can.  Seems like there are only minor things that are different so splitting them out in OUs like you are doing is fine.  

You can apply separate GPOs to the OUs, Permissions, etc.  Separate domains are needed in special cases these days (replication for example...europe domain, North American Domain, Asia Domain).  Password Policies used to be a reason but fine grained passwords have helped with that.

Do the same admins administer both business units or does each business unit have its own "admins"


PDGPAAuthor Commented:
Thanks Mike! We have the same administrators for both business units. The problem is our current structure is really adhoc and not ideal, for instance our Organization might be something like Organization-> business unit->20some locations->job type A | job  type (all others)

So in that section alone we have most of our locations having their own OU (even though there's not really much purpose to it apart from having it force user information (Location field in user objects) so that signatures, etc are consistent. Yet we can go back to the business unit section, go to the 2nd one, and have the same thing.

Meanwhile, under our computers we have some scheme like: desktop/laptop/other->Windows7 or XP->'Role' of computer OR business unit (so special types of computers like autologins, etc)-> and then for each of the business units we have a list of practices or roles, etc.)

I've never done a complete rebuilding of AD but it's pretty clearly not a good current setup, especially since many of the groups don't have a functional purpose apart from basic information (identifying location). After looking in to multiple domain solutions I do agree that that's not the best option. Are there any particularly useful resources to help with designing a project like this or ideas you think would be worth investigating?

All Courses

From novice to tech pro — start learning today.