When to add new domains to your Windows environment

Is one domain enough? How many domains are too many? Learn the factors to consider when designing your network's domain structure.

Creating the appropriate domain structure for a Windows network can be tricky business. I've seen large networks...

made up of a single domain and relatively small networks that are broken up into lots of them.

So how many domains should you have? Well, the answer is going to be different for each organization. Even so, I want to explore this issue and give you some things to think about when figuring out whether or not to create additional domains.

Is it ever OK to have a single domain?

Most of the time, having a single domain is perfectly acceptable. I realize that almost all of Microsoft's technical presentations depict multi-domain networks. It's important to remember, however, that this is usually done to demonstrate scalability rather than suggest that additional domains are actually required.

When do you need additional domains?

Although having a single domain network is fine in most situations, it can sometimes be advantageous to create additional domains. Let's take a look at some of these situations.

Delegation of control
In large organizations, there is rarely a single administrator who is in charge of everything. Often times, administrative tasks are delegated to other admins. In these situations, the creation of additional domains provides an easy way of delegating control over a portion of the network. An administrator can be given full control over a specific domain, without being granted administrative permissions for an entire forest.

Varying Group Policy needs
Sometimes you may find that you need to apply different Group Policy settings to different groups of users for compliance reasons. Group Policy settings can be applied to the local computer, domain, site, and organizational unit (OU) levels of Active Directory.

In many cases, it's more practical to group users into separate domains and then apply Group Policy settings to the domain level than it is to apply the Group Policy settings at other levels of the Active Directory hierarchy.

Isolation of resources
Some organizations like to isolate user accounts from other types of Active Directory resources. To achieve this goal, they create both user and resource domains. Resource domains typically contain a collection of various security groups which are used to control access to network resources such as applications, folders, or even printers. These groups are then populated with user accounts from the user domain.

I have to admit that I have never seen any real advantage to structuring a network this way. Even so, this approach seems to work well for some organizations, so I wanted to at least mention it.

Branch Offices
Some organizations create a separate Active Directory domain for each branch office. Doing so has advantages and disadvantages. The primary benefit to having a separate domain for each branch office is that the branch office is self-contained. In other words, all of the Active Directory resources for the branch office are contained within the branch office's domain.

Planning your
AD environment?

Check out our Active Directory Planning and Design Guide

The downside to using this approach, however, is cost. Creating a separate domain for each branch office requires domain controllers (and typically a DNS server) dedicated to servicing the branch office. Not only does this lead to hardware and software costs, but there are also costs associated with branch office maintenance.

Depending on your budget and the size of the branch offices, dedicated domains may or may not be warranted. Organizations with small branch offices often find it more cost effective to place branch offices into a dedicated Active Directory site (which still requires at least one dedicated domain controller) rather than creating an entirely separate domain.

In the days of Windows NT, a domain was limited to hosting about 40,000 users. Even though that was more than adequate for most organizations, Microsoft upped the ante when it created Active Directory. For example, a Windows Server 2008 Active Directory database can scale to contain millions of objects.

At the same time, as the number of users in a domain increases, so does the difficulty of managing that domain. Just imagine what it would be like to try to locate a single user account within the Active Directory Users and Computers console if there were a million users in the domain.

Performance can also suffer as the number of user accounts within a domain increases. The point at which the domain's performance starts to degrade will vary depending on the server's hardware capabilities, the number of domain controllers in the domain, and the network throughput.

If you find that a domain is becoming difficult to manage, or that performance has begun to decline, then it may be time to create another domain.

As you can see, there aren't really any firm rules as to when you should or should not create a new Windows domain. Every network is different, and one network's ideal domain topology may not work so well for another. That being the case, my recommendation is to create domains as your needs dictate, using the factors described above.

Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.

This was last published in August 2009

Dig Deeper on Microsoft Active Directory Design and Administration



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.