Practical App
Simplicity Is Key when Deploying Active Directory
The way you set up your Active Directory topography will have a direct impact on how well you're able to organize your users and resources.
Since the release of Windows 2000 Server edition more than a decade ago -- and with it the release of Active Directory -- the time-tested Microsoft directory service has helped organizations maintain order amid the chaos. One strategy most organizations take (although there are certainly exceptions) is to stick with the simplest Active Directory deployment that they can realistically get away with.
This should come as no surprise. The principle of keeping things as simple as possible definitely applies to the world of IT. Any seasoned IT professional knows that keeping things simple reduces the chances of problems and makes troubleshooting a lot easier. There's absolutely nothing wrong with using a standard Active Directory topology. There's a reason Microsoft set the standard topology as the default.
But while there's something to be said for simplicity, when it comes to Active Directory, some organizations might be better served by a more creative structure. There are some alternate designs that are likely more appropriate for larger organizations that need to segregate the management responsibilities.
Domain Structure
Most often, real-world Active Directory deployments use a domain structure that mimics the organization's geographic structure. For example, if an organization has three offices, it's likely to have three domains. Not every organization uses this type of design, but it's the most-common type of Active Directory structure. Here are a few alternate domain structures you might want to consider for your organization.
User Domains
Active Directory is really nothing more than a database. The database is filled with various types of objects. Each object is assigned one or more attributes. Organizations sometimes base their domain structure on specific types of Active Directory objects. One example of this is the use of user domains.
A user domain is an Active Directory domain set up for the sole purpose of managing user accounts. To give you an idea of why this is useful, consider this example of an organization with a few thousand users and a high rate of employee turnover. This organization employs two people whose job it is to create, provision and remove user accounts.
In this type of situation a user domain could prove useful, because this type of domain structure would help the users tasked with account maintenance to have full administrative control over the user accounts. They could be limited, however, from having access to any other Active Directory objects or functions.
You don't need to implement this type of domain structure specifically to isolate administrative responsibilities. There are other ways to accomplish this type of isolation. Nevertheless, a user domain structure can help an organization stay better organized by making the individual domains less cluttered. It also provides a sense of physical administrative isolation, which some organizations might prefer instead of the logical administrative isolation that can exist when all various object types reside in a common domain.
Resource Domains
Resource domains are similar to user domains in that they're single-purpose in nature. These are used to enhance security or make the Active Directory structure more logical or manageable. There are real-world Active Directory deployments in which all of the desktop computers are grouped into a dedicated resource domain. Other organizations have placed all their servers running primary line-of-business applications into a dedicated resource domain. You can use resource domains for any other class of resource as well.
Resource domains are probably most useful when you treat them as management domains. For example, you might want to create a dedicated Active Directory forest designed to act purely as a management domain for Hyper-V servers. There are a couple of reasons why you might choose to do this.
The first reason has to do with management. System Center Operations Manager 2012 (and a number of other management products) can only manage servers that are members of an Active Directory domain. You wouldn't want to join your Hyper-V servers to your primary domain because all of the domain controllers for your primary domain are virtualized. You wouldn't want to risk putting your organization in a situation in which you were unable to log on to a Hyper-V server because the virtual DCs were offline. Adding the Hyper-V servers to a dedicated Active Directory management forest solves this problem quite well.
Another reason you might choose to create a dedicated resource domain for your Hyper-V servers has to do with some of the new features that are coming in Hyper-V version 3.0. Hyper-V 3.0 will have the ability to replicate a VM from one host server to another. This type of replication is not a failover clustering solution, but rather a disaster recovery solution that lets you maintain an up-to-date copy of your VMs on an alternate host server. That way, if something happened to your disk array or your primary Hyper-V host, you'd have another copy of your VMs you could fall back on.
In order to use this feature, however, both the host server and the replica server have to be authenticated. The easiest way to provide this authentication is to join both servers to a common domain and use Kerberos. As such, creating a dedicated resource domain for Hyper-V servers makes perfect sense. This is especially true when you consider there are other Hyper-V features that also require domain membership.
Incidentally, resource domains and user domains are not mutually exclusive. Some organizations use a combination of user domains and resource domains within a common Active Directory forest.
Geographic Topology
While these alternate structures are indeed effective, the vast majority of Active Directory deployments in the real world are based on geographical structure. Technically, there's nothing wrong with using this type of Active Directory topology -- but there are a few things you should consider.
First, don't confuse domain structure with site structure. The Active Directory site structure should always mimic an organization's geographic topology. For every wide area network (WAN) link between offices, there should be a corresponding site link within Active Directory. Furthermore, the computers that reside within a physical office should be placed within a common Active Directory site. Ideally, each location should make use of a dedicated subnet because a single subnet can't span multiple Active Directory sites.
Active Directory site structure is important because the site structure has a direct impact on the volume of Active Directory replication traffic that will flow across the WAN links. For example, imagine an organization with multiple branch offices. This organization chose to configure its Active Directory as a single domain, which isn't wrong. In a situation like this, you could potentially make updates to Active Directory on any writable DC within the entire organization. When an update does occur, it's the DC's responsibility to make the update available to the other DCs.
If this organization didn't make use of an appropriate site structure, a common update could pass over a WAN link multiple times. For example, if there were five DCs in a branch office, an Active Directory update could potentially be sent across the WAN link five separate times, once for each DC.
When you use Active Directory sites, one DC in each site acts as a bridgehead server. The bridgehead server's job is to receive Active Directory updates from across the WAN and distribute those updates to the other DCs within the site. This means any Active Directory updates would only need to be sent to each branch office once, regardless of how many DCs there are within that branch office.
What about organizations that use a separate domain for each branch office? If each branch office has a dedicated Active Directory forest, you don't have to worry about defining Active Directory sites. On the other hand, if each domain is a member of a common forest, you should definitely implement an appropriate Active Directory site structure as a way to keep forest-level Active Directory replication traffic in check.
As you can see, there are lots of different ways to set up your Active Directory domain topology. Ultimately, you should choose the topology that makes the most sense for your own organization. This could be a single domain model, or a multi-domain model based on geographic proximity, users or even resources.
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.