Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am planning to create a Windows Server 2008-based domain for 70 computers and 50+ users, which will be distributed across two different buildings, which are connected by a dedicated 100 Mbps line. I am planning to use a single domain with a domain controller on each of the two buildings. We expect to grow to over 150 computers and 100 users within 3 years. Most of our work involves large file sharing (a few TBs of file servers at the moment) and some specialised research hardware and software.

I am not sure what's the best way to organise the users in the domain. Should I arrange them in organisational units? Should I use groups instead? A combination of both? Multiple domains even? Can you suggest some guidelines for this size and complexity, please?

Many thanks in advance.

share|improve this question
are the buildings geographically dispersed? what is you experience with the uptime of the 100mbps line? is this a leased line? – johnh Dec 10 '09 at 20:28
Uptime is great. Yes, the line is leased, and bandwidth is quite nice. The buildings are about 6 km apart, but belong to the same campus, so to speak. – CesarGon Dec 10 '09 at 20:30
up vote 8 down vote accepted

You don't want a multi-domain environment. You only use a multi-domain environment when you have to (differing password policies for different users in a Windows 2003 environment, using the domain as a boundary of replication for two or more very large environments). A single domain environment is the way to go.

You're right to put at least one DC at each physical location. Be sure you setup AD's "Site" and "Subnet" configuration so that AD can make intelligent replication decisions and (more importantly) client computers can make intelligent decisions about which DC they talk to during logon. Both DCs should be ticked as "Global Catalog" servers, and should provide DNS services for PCs in their location. (You should specify the far-end DC as a secondary DNS server for PCs, but you'd like them to talk to the DC in their location first.)

The organization of users, computers, groups, and other objects into OUs within your Active Directory (AD) is based on two criteria:

  • Delegation of control of administrative tasks within AD
  • Application of Group Policy

As a tertiary concern, you might organize objects in AD to be visually easy to locate, but that is strictly an aesthetic concern.

Delegation of control relates to the modification of the default permissions in AD to allow other users the ability to perform adminsitrative tasks. Imagine a scenario where you have an off-site branch office, and an "IT power user" in that office who wants to perform password resets for users who forget their password in her office.

By delegating control to her (via placing her in a group and delegating control to the group) to reset passwords only on the OU where the user account objects representing users in her office are located (possibly in sub-OUs-- the delegation inherits to sub-OUs by default) you grant her the ability to reset passwords only for those users.

In a small organization there might not be a large amount of delegation of control, but it's something you should at least think about when "whiteboarding" your potential configuration.

Group policy is typically applied to users or computers by linking the group policy objects to OUs. (It's possible to use group policy without any OUs at all but it's a big pain and not a realistic deployment strategy.) If you needed to install an application via "Software Installation Policy" onto all PCs in the Accounting department, for example, having the PCs organized into OUs representing departments would give you an easy way to target a GPO at all those PCs.

The application of group policy can be controlled via other means (group membership of the user or computer, WMI filtering, IP subnet by way of group policy objects linked at "Site" objects), whereas delegation of control can only work on an OU basis. As such, delegation of control is your first overriding design concern (i.e. make sure the proposed OU layout works for your desired delegation of control strategy), and group policy application (which is more fluid) is a secondary concern.

You might do well to have someone familiar with Active Directory sit down with you for a couple of hours and ask you some questions about how you want to use your AD to come up with a proposed design. It sounds like a pretty simple environmnet and OU hierarchies are easy to re-engineer down the road, but a good AD consultant might give you some excellent ideas that, as you grow, allow you to minimize administrsative expense and streamline delivery of functionality to users.


I would take some issue with the statement in your comment re: "the OU hierarchy should replicate the structure of my organisation." The OU hierarchy should support your desired delegation of control and group policy application strategies. If it happens to appear similiar to your "org chart" or some other organizational diagram, so be it. AD isn't an "org chart", though, and you should't assume that the OU hierarchy is going to end up looking anything like any existing organizational diagram.

Security groups are used to grant permissions to resources like shared folders. (You can name individual users in permissions too, but you shouldn't except for edge cases like home directories.) OUs are not "security principals"-- i.e. they don't have a security identifier (SID) associated with them, and therefore cannot be named in permissions.

The AD OU hierarchy is used for controlling group policy application.

The permissions set on the OU hierarchy (and, the structure of the hierarchy underneath those permissions) control the delegation of administrative duties in Active Directory.

Sometimes it feels like duplication to have to create, say, an "Accounting" OU and an "Accounting" security group. Unfortunately, that's the way the product was designed. I can't say that I've experienced that type of situation, though, in many cases.

What gets a bit mind-bending is the idea that a security group is an AD object, and therefore can have its permissions changed to allow an arbitrary set of users control the membership of the group. That group could, in turn, be used to control other types of access (say, permissions to shared folders, or permissions to perform additional administrative tasks in AD). The most easy to grasp group of this nature is "Domain Admins". Delegating someone rights to control the membership of the "Domain Admins" group could (either purposefully or inadvertantly) grant that delegated administrator the right to elevate someone (possibly themselves) to being a "Domain Admin".

Basically, delegation of control over the membership of security groups needs to be well thought-out at design-time. You can do some really powerful and interesting stuff with it, but you need to think it through.

share|improve this answer
Great explanation and great advise. Get off to a good start and it will be much easier as time goes on. Often harder to undo a mistake. – Dave M Dec 10 '09 at 21:27
Many thanks for the detailed explanation, Evan. Most appreciated. – CesarGon Dec 10 '09 at 22:45
I just skimmed read that, but I would also recommended getting a third server and having it as like a "master" for the other two. for example: MasterController then have BuildingA and BuildingB servers replicating the correct data and information off the master just to make it cleaner. – p858snake Dec 11 '09 at 14:02
@p858snake: What would the advantage be? Just checking... – CesarGon Dec 11 '09 at 14:20
@p858snake: Active Directory is a multimaster replicated database with loose convergence. It'll handle keeping all its replicas in sync very well on its own and doesn't need "help". I think you may've thought that my answer had something to do with file server data replication or some such, which it does not. – Evan Anderson Dec 11 '09 at 14:22

Your Answer


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.