Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are looking to add some logical structure to our (Win 2003) AD hierarchy. We have a single domain and around 500 users. All users and computers are currently organized into one OU. All security and distribution groups are in a second OU. Group membership is essentially on an individual user basis with no nesting of groups.

My questions:

  1. For an organization of this size is it worth desgining a hierarchy of OUs based on department, geography and/or object class (ie computers, users, groups) and moving the users, computers and groups into the relevant OUs?
  2. If so, how would you structure the hierarchy e.g. department->location->object class?
  3. Should we nest groups, where appropriate, for better mapping to enterprise application roles and Exchange address entries?
share|improve this question

6 Answers 6

up vote 9 down vote accepted

Here are the core tenets of Microsoft's recommendation for AD logical design:

  • Design first for delegation of control, because that's based on AD permissions and is the most inflexible axis to modify. If you aren't doing delegation of control then don't worry about this (but I'd plan for it anyway-- even in an organization that small you may have need for designated users in branch offices to be able to reset passwords, etc).

  • Design second for application of group policy. Filtering group policy application by security group membership allows a GPO to apply to only a subset of the user or computer objects below the point it is linked in the directory, so this axis has some more flexibility than the AD permissions.

  • Design lastly for organization and ease of use. Make it easy to find things for yourself and other admins.

Think about each of these considerations as you design, prioritizing them as recommended. It's easy to change things later (comparatively), and you'll never "get it right" on the first try. Before I even DCPROMO my first domain controller I typically draw out the proposed structure on paper or a whiteboard and walk through potential usage scenarios to see if my design "holds up". It's a great way to shake out problems in a design.

(Don't forget about group policy application on the site objects, either. You have to be careful about cross-domain GPO application when you link GPOs at sites, but if you're a single domain environment you can get a lot of great functionality out of linking GPOs to sites. Work through some sample scenarios with it-- I find that it's great for loading software that has "site-specific" settings in it or providing specific logon scripts to users when logging-on to computers in certain physical locations, by way of loopback group policy processing.)

share|improve this answer
    
Can you give an example of a simple structure that you would implement with these best practices? –  TechGuyTJ Aug 20 '09 at 20:56
2  
Not w/o a lot of typing. Maybe I can post one of the quizzes from when I taught Active Directory design classes along with an attempt at an answer. As it sits now, though, work is beating the hell out of me and I don't have a lot of Server Fault time. I'll flag this and see if I can get back to it. –  Evan Anderson Aug 21 '09 at 2:54

I'd always split users, computers and groups into separate OUs, for the simple reason that it makes it easier to manage.

If you have no compelling reason for a specific AD structure, then design your AD from an administrative point of view. Think about where you are going to be applying policies.

If you are applying most of your policies at department level, use Department\Location\Object

If you are applying most of your policies at location level, use Location\Department\Object

If you did it the other way, it would mean you would have to link your policies at multiple OUs, which involves unnecessary work.

Nesting groups is perfectly fine, and again, make management of AD much easier.

I tend to design AD structures with 'making it easy to manage' in mind, rather than reflect physical company structure, however both are often the same.

share|improve this answer
    
Remember though, it doesn't matter how well you design you AD structure, they'll always be an exception :-) –  Tubs Jul 23 '09 at 7:39

I think, if I had to redesign my AD again there are a few things that I would do differently, but I have found that :

Users - Split theses into departments, but also with an area/s for temp or agency staff. Location for these won't be as important as no doubt people will move about.

Computers - Split these into location and sub locations. Ie OfficeComputers/LondonOffice/Room103 (Finance). This means that you can apply settings to one location or office - for example a different proxy server, or different anti virus settings (of course only if the AV management program uses AD)- without reorganising, and hopefully won't have to open the can of worms that is loopback processing.

I've also found it useful not to use the built in users or computers groups, not any technical issues, but just so that you can easily see where things shouldn't be.

Finally, split your servers up as well, I've gone for location/role which seems to have worked quite well.

share|improve this answer

As it's already answered, here's my take for a small example, mind you there's no right or wrong it all depends on the needs - ie organisation or location first? I prefer organisational role first even for computers / server roles. I also like the ability to point out a single OU to get all employees and no garbage to populate intranet employee listings from. Feel free to edit!

  • People (users/type=person)
    • Internal
      • Department A
        • Location X
        • Location Y
      • Department B
      • Department C
    • External
      • Company 1
      • Company 2
  • Machine (users/type=any including computers)
    • Client
      • Laptops
      • Desktops
    • Server
      • Application
        • Location T
        • Location V
      • Infrastructure
      • Database
    • Service
    • Administrative accounts (if used)
  • Lists (groups&contacts)
    • Contact
    • Distribution
    • Security
share|improve this answer
    
@Oskar - thanks for the example. I think you meant Machine (computer accounts) not Machine (user accounts). –  eft Jul 23 '09 at 15:27
    
Well, not really but a good catch.. I think I meant "user accounts" in general (for computer accounts, service accounts and so forth), as opposed to groups or contacts... fixed –  Oskar Duveborn Jul 23 '09 at 15:29
    
I see what you meant now - thanks for clarification –  eft Jul 23 '09 at 16:51

I'd just split them by location in this case. The resulting OU structure would look something like this:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

etc.

I don't really see any need for further divisions here, e.g. by Department, as it would generate extra admin overhead without really giving much in return. Splitting by location however would enable you to implement delegation at each site.

share|improve this answer

A guide line I use is: Users; organize according to HR chartflow Groups; organize according to workflow Computers; organize according to geographic location

The other answers in this thread are very good too though.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.