In-Depth
AD Design Best Practices: Know Your Domains
When setting up directory services on a Windows network, it's truly all about the infrastructure.
In the first part, I talked about OU design as it relates to group policy-based security. In this article, I want to continue the discussion by talking about planning your Active Directory’s domain structure.
One of the first design decisions that you will have to make when creating a new Active Directory environment is how many domains you want to have, and where those domains should be placed. In some organizations it is perfectly acceptable to use a single domain, while other organizations require multiple domains. So how do you know which domain design is right for you?
There are many different reasons for using multiple domains, but I like to think of domains primarily as administrative boundaries. Therefore, if you need to give someone administrative control over a subset of the network, then you might consider making that part of the network a separate domain.
Single Domain Forests
Single domain forest tend to work out best in small- to medium-sized organizations. The primary benefit to a single forest domain is ease of management. Anyone belonging to the Domain Admins group will have the authority to manage the entire forest.
Multiple Domain Forests
As I mentioned earlier, creating separate domains is usually a way of establishing administrative boundaries. If you do plan on creating multiple domains, then Microsoft recommends that you reserve the forest root domain (the first domain created in an Active Directory forest) solely for administering the forest infrastructure. All other functionality should be performed by child domains beneath the forest root domain.
Geographical Domains
Probably the most commonly used model for multi-domain forests involves creating a separate domain for each geographic location. For example, if an organization had its headquarters in Miami, and had satellite offices in Las Vegas and New Orleans then the Miami office would host the forest root domain as well as a child domain dedicated to serving the needs of the Miami office. The New Orleans and Las Vegas offices would each have their own domains.
The nice thing about this design is that it allows each office to be semi-autonomous. The down side is that it requires each office to have their own IT staff to manage the on-premise domain.
I have heard some IT professionals state that you should always create a separate domain for each office because doing so allows you to control Active Directory replication traffic. While creating separate domains does control replication traffic, you can also control replication traffic by placing each office into a separate Active Directory site. The method that you should use really just depends on your administrative needs.
Departmental Domains
Some organizations like to create a separate domain for individual departments. This is a great way of keeping the departments isolated from one another. Once again though, the down side to this technique is that as the number of domains increases so does the management burden.
There is nothing wrong with creating a separate domain for each department, but you do have to consider who will manage those domains.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.