Active Directory OU design for <500 users, 4 locations

Solution 1:

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.)

Solution 2:

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.

Solution 3:

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.

Solution 4:

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