Active Directory 2008 : Installing and Managing Trees and Forests - Reasons for Creating Multiple Domains

Before you look at the steps you must take to create multiple domains, become familiar with the reasons why an organization might want to create them.

In general, you should always try to reflect your organization's structure within a single domain. By using organizational units (OUs) and other objects, you can usually create an accurate and efficient structure within one domain. Creating and managing a single domain is usually much simpler than managing a more complex environment consisting of multiple domains.

That said, you should familiarize yourself with some real benefits and reasons for creating multiple domains as well as some drawbacks of using them.

1. Reasons for Using Multiple Domains

You might need to implement multiple domains for several reasons. These reasons include the following considerations:

Scalability

Although Microsoft has designed Active Directory to accommodate millions of objects, this may not be practical for your current environment. Supporting thousands of users within a single domain requires more disk space, greater CPU (central processing unit) usage, and additional network burdens on your domain controllers (computers containing Active Directory security information). To determine the size of Active Directory domain your network can support, you need to plan, design, test, and analyze within your own environment.

Reducing replication traffic

All the domain controllers in a domain must keep an up-to-date copy of the entire Active Directory database. For small- to medium-sized domains, this is not generally a problem. Windows Server 2008 and Active Directory manage all the details of transferring the database behind the scenes. Other business and technical limitations might, however, affect Active Directory's ability to perform adequate replication. For example, if you have two sites that are connected by a very slow network link (or a sporadic link, or no link at all), replication is not practical. In this case, you would probably want to create separate domains to isolate replication traffic. Sporadic coverage across the wide area network (WAN) link would come from circuit switching technologies such as Integrated Services Digital Network (ISDN) technologies. If you didn't have a link at all, then you would have a service provider outage or some other type of disruption. Separate domains mean separate replication traffic, but the amount of administrative overhead is increased significantly.

Because it's common to have WAN links in your business environment, you will always need to consider how your users authenticate to a domain controller (DC). DCs at a remote site are commonly seen to authenticate users locally to their local area network (LAN). The most common design involves putting a DC at each remote site to keep authentication traffic from traversing the WAN. If it is the other way around, the authentication traffic may cause users problems if WAN utilization is high or if the link is broken and no other way to the central site is available. The design you are apt to see most often is one in which each server replicates its database of information to each other server so that the network and its systems converge.

However, is important to realize that the presence of slow WAN links alone is not a good reason to break an organization into multiple domains. The most common solution is to set up site links with the Site and Services Microsoft Management Console (MMC). When you use this MMC, you can manage replication traffic and fine-tune independently of the domain architecture.

The following are the reasons why you would want to use a multidomain architecture, such as when two companies merge through an acquisition.

Meeting business needs

Several business needs might justify the creation of multiple domains. Business needs can be broken down even further into organizational and political needs.

One of the organizational reasons for using multiple domains is to avoid potential problems associated with the Domain Administrator account. At least one user needs to have permissions at this level. If your organization is unable or unwilling to trust a single person to have this level of control over all business units, then multiple domains may be the best answer. Since each domain maintains its own security database, you can keep permissions and resources isolated. Through the use of trusts, however, you can still share resources.

A political need for separate domains might arise if you had two companies that merged with two separate but equal management staffs and two sets of officers. In such a situation, you might need to have Active Directory split into two separate databases to keep the security of the two groups separate. Some such organizations may need to keep the internal groups separate by law. A multidomain architecture provides exactly this type of pristinely separate environment.

Many levels of hierarchy

Larger organizations tend to have very complex internal and external business structures that dictate the need for many different levels of organization. For example, two companies might merge and need to keep two sets of officers who are managed under two different logical groupings. You can use OUs to help group different branches of the company so that you can assign permissions, or delegations, or whatever else you can think of without affecting anyone else. Managing data becomes much easier when you're using OUs, and if you design them correctly, OUs will help you control your network right from one console. You may only need one level of management—your company may be small enough to warrant the use of the default OU structure you see when Active Directory is first installed. If, however, you find that you need many levels of OUs to manage resources (or if large numbers of objects exist within each OU), it might make sense to create additional domains. Each domain would contain its own OU hierarchy and serve as the root of a new set of objects.

Decentralized administration

Two main models of administration are commonly used: a centralized administration model and a decentralized administration model. In the centralized administration model, a single IT organization is responsible for managing all of the users, computers, and security permissions for the entire organization. In the decentralized administration model, each department or business unit might have its own IT department. In both cases, the needs of the administration model can play a significant role in whether you decide to use multiple domains.

Consider, for example, a multinational company that has a separate IT department for offices in each country. Each IT department is responsible for supporting only the users and computers within its own region. Since the administration model is largely decentralized, creating a separate domain for each of these major business units might make sense from a security and maintenance standpoint.

Multiple DNS or domain names

Another reason you may need to use a multidomain architecture is if you want or plan to use multiple DNS names within your organization. If you use multiple DNS names or domain names, you must create multiple Active Directory domains. Each AD domain can have only one fully qualified domain name (FQDN). An FQDN is the full name of a system that consists of a local host, a second-level domain name, and a top-level domain (TLD). For example, www.wiley.com.com is the TLD, www is the host, and wiley is the second-level domain name. is an FQDN,

Legality

One final reason you may need to use a multidomain architecture is legality within your organization. Some corporations have to follow state or federal regulations and laws. For this reason, they may have to have multiple domains.

4.1.2. Drawbacks of Multiple Domains

Although there are many reasons why it makes sense to have multiple domains, there are also reasons why you should not break an organizational structure into multiple domains, many of which are related to maintenance and administration. Here are some of the drawbacks to using multiple domains:

Administrative inconsistency

One of the fundamental responsibilities of most systems administrators is implementing and managing security. When you are implementing Group Policy and security settings in multiple domains, you want to be careful to ensure that the settings are consistent. In Windows Server 2008, security policies can be different between and within the same domains. If this is what the organization intended, then it is not a problem. If, however, an organization wishes to make the same settings apply to all users, then each domain requires similar security settings.

Increased management challenges

Managing servers, users, and computers can become a considerable challenge when you are also managing multiple domains, because many more administrative units are required. In general, you need to manage all user, group, and computer settings separately for the objects within each domain. The hierarchical structure provided by OUs, on the other hand, provides a much simpler and easier way to manage permissions.

Decreased flexibility

Creating a domain involves the promotion of a DC to the new domain. Although the process is quite simple, it is much more difficult to rearrange the domain topology within an Active Directory environment than it is to simply reorganize OUs. When planning domains, you should ensure that the domain structure will not change often, if at all.