Active Directory 2008 : Overview of Active Directory Replication and Sites

Regardless of the issues related to network design and technological constraints, network users have many different requirements and needs that must be addressed. First and foremost, network resources such as files, printers, and shared directories must be made available. Similarly, the resources stored within Active Directory—and, especially, its security information—are required for many operations that occur within domains.

With these issues in mind, take a look at how you can configure Active Directory to reach connectivity goals using replication.

Active Directory was designed as a scalable, distributed database that contains information about an organization's network resources.

Even in the simplest of network environments, you generally need more than one domain controller. The major reasons for this include fault tolerance (if one domain controller fails, others can still provide services as needed) and performance (the workload can be balanced between multiple domain controllers). Windows Server 2008 domain controllers have been designed to contain read-write copies of the Active Directory database as well as read-only copies of the Active Directory database. However, the domain controllers must also remain current when objects are created or modified on other domain controllers.

To keep information consistent between domain controllers, you use Active Directory replication. Replication is the process by which changes to the Active Directory database are transferred between domain controllers. The end result is that all of the domain controllers within an Active Directory domain contain up-to-date information and achieved convergence. Keep in mind that domain controllers may be located very near to each other (for example, within the same server rack) or they may be located across the world from each other. Although the goals of replication are quite simple, the real-world constraints of network connections between servers cause many limitations that you must accommodate. If you had a domain controller on your local LAN, you may find that between your server connections you have Gigabit Ethernet, which runs at 1000Mbps, whereas you may have a domain controller on the other side or a WAN where the network link runs at a fraction of a T1, 56Kbps. Replication traffic must traverse each link to ensure convergence no matter what the speed or what bandwidth is available.

2. Understanding Active Directory Site Concepts

One of the most important aspects of designing and implementing Active Directory is understanding how Active Directory allows you to separate the logical components of the directory service from the physical components.

The logical components—Active Directory domains, OUs, users, groups, and computers—map to the organizational and business requirements of a company.

The physical components, on the other hand, are designed based on technical issues involved in keeping the network synchronized (that is, making sure all parts of the network have the same up-to-date information). Active Directory uses the concept of sites to map to an organization's physical network. Stated simply, a site is a collection of well-connected subnets.

It is important to understand that no specified relationship exists between Active Directory domains and Active Directory sites. An Active Directory site can contain many domains. Alternatively, a single Active Directory domain can span multiple sites. Figure 1 illustrates this very important characteristic of domains and sites.

Figure 1. Potential relationships between domains and sites

There are two main reasons to use Active Directory sites: service requests and replication.

2.1. Service Requests

Clients often require the network services of a domain controller. One of the most common reasons for this is that they need the domain controller to perform network authentication. If your Active Directory network is set up with sites, clients can easily connect to the domain controller that is located closest to them. By doing this, they avoid many of the inefficiencies associated with connecting to distant domain controllers or to those that are located on the other side of a slow network connection. For example, by connecting to a local domain controller, you can avoid the problems associated with a saturated network link, which might cause two domain controllers to be out of synch with each other.

Other network services that clients might access include the Licensing service (for tracking licenses associated with Microsoft and other compatible products) and the services used by messaging applications (such as Exchange Server). All of these functions depend on the availability of network services.

2.2. Replication

As we mentioned earlier, the purpose of Active Directory replication is to ensure that the information stored on all domain controllers within a domain remains synchronized. In environments with many domains and domain controllers, usually multiple communication paths connect them, which makes the synchronization process more complicated. A simple method of transferring updates and other changes to Active Directory involves all of the servers communicating directly with each other as soon as a change occurs; they can all update with the change and reach convergence again. This is not ideal, however, since it places high requirements on network bandwidth and is inefficient for many network environments that use slower and more costly WAN links, especially if all environments update at the same time. Such simultaneous updating could cause the network connection at the core of your network to become saturated and decrease performance of the entire WAN.

Using sites, Active Directory can automatically determine the best methods for performing replication operations. Sites take into account an organization's network infrastructure, and Active Directory uses these sites to determine the most efficient method for synchronizing information between domain controllers. Systems administrators can make their physical network design map to Active Directory objects. Based on the creation and configuration of these objects, the Active Directory service can then manage replication traffic in an efficient way.

Whenever a change is made to the Active Directory database on a domain controller, the change is given an update sequence number. The domain controller can then propagate these changes to other domain controllers based on replication settings. In the event that the same setting (such as a user's last name) has been changed on two different domain controllers (before replication can take place), these sequence numbers are used to resolve the conflict.

Windows Server 2008 uses a feature called linked value replication that is only active when the domain is in Windows Server 2003 or 2008 domain functional level. In Windows 2000, if a change was made to a member of a group, the entire group was replicated. With linked value replication, only the group member is replicated. This greatly enhances replication efficiency and cuts down on network traffic utilization. Linked value replication is automatically enabled in Windows Server 2003 or 2008 domain functional level domains.

2.3. Planning Your Sites

Much of the challenge of designing Active Directory is related to mapping a company's business processes to the structure of a hierarchical data store. So far, you've seen many of these requirements. But what about the existing network infrastructure? Clearly, when you plan for and design the structure of Active Directory, you must take into account your LAN and WAN characteristics. Let's see some of the ways you can use Active Directory sites to manage replication traffic.

Synchronizing Active Directory is extremely important. In order to keep security permissions and objects within the directory consistent throughout the organization, you must use replication. Active Directory data store supports multimaster replication; that is, data can be modified at any domain controller within the domain because replication ensures that information remains consistent throughout the organization.

Ideally, every site within an organization has reliable, high-speed connections with the other sites. A much more realistic scenario, however, is one in which bandwidth is limited and connections are sometimes either sporadically available or completely unavailable.

Using sites, network and systems administrators can define which domain controllers are located on which areas of the network. These settings can be based on the bandwidth available between the areas of the network. Additionally, these administrators can define subnets—logically partitioned areas of the network—between areas of the network. Subnets are designed by subdividing IP addresses into usable blocks for assignment, and they are also objects found within the Sites and Services Microsoft Management Console (MMC) in the Administrative Tools folder. The Windows Server 2008 Active Directory services use this information to decide how and when to replicate data between domain controllers.

Directly replicating information between all domain controllers might be a viable solution for some companies. For others, however, this might result in a lot of traffic traveling over slow or undersized network links. One way to efficiently synchronize data between sites that have slow connections is to use a bridgehead server. Bridgehead servers are designed to accept traffic between two remote sites and to then forward this information to the appropriate servers. Figure 2 provides an example of how a bridgehead server can reduce network bandwidth requirements and improve performance. Reduced network bandwidth requirements and improved performance can also be achieved by configuring replication to occur according to a predefined schedule if bandwidth usage statistics are available.

Figure 2. Using a bridgehead server

Bridgehead servers do not fit a normal hub-and-spoke WAN topology. Such a topology usually involves a core site (for example, company headquarters) with remote sites as links one off from the core. However, you can use a bridgehead server design to fit a distributed star, where you have a hub-and-spoke topology design, with additional spokes coming out of the first set of spokes. Doing so would make some of your spoke sites into smaller core sites; it is at these sites that you would place your bridgehead servers. In Figure 2, you can see that your Asia headquarters site is also where you can connect up to India, China, and Hong Kong—thus making Asia headquarters the ideal site for the bridgehead server.

In addition to managing replication traffic, sites also offer the advantage of allowing clients to access the nearest domain controller. This prevents problems with user authentication across slow network connections and it can help find the shortest and fastest path to resources such as files and printers. Therefore, Microsoft recommends that you place at least one domain controller at each site that contains a slow link. Preferably, this domain controller also contains a copy of the Global Catalog so that logon attempts and resource search queries do not occur across slow links. The drawback, however, is that deploying more copies of the Global Catalog to servers increases replication traffic.

Through proper planning and deployment of sites, organizations can best use the capabilities of the network infrastructure while keeping Active Directory synchronized.