Planning Replication Topology

In the ideal world, gigabit cabling runs the entire length of an organization's LAN, encompassing all computers into one big network segment. For those of us who are not so fortunate, network traffic patterns are an important consideration, and a firm understanding of the "pipes" that exist in an organization's network is warranted. If all remote sites are connected by T1 lines, for example, there will be fewer replication concerns than if network traffic passes through a slow link.

With this point in mind, mapping out network topology is one of the first steps in creating a functional and reliable replication topology.

Mapping Site Design into Network Design

Site structure in Windows Server 2003 is completely independent from the domain, tree, and forest structure of the directory. This type of flexibility allows domain designers to structure domain environments without needing to consider replication constrictions. Consequently, domain designers can focus solely on the replication topology when designing their site structure, enabling them to create the most efficient replication environment.

Essentially, a site diagram in Windows Server 2003 should look similar to a WAN diagram of your environment. In fact, site topology in Active Directory was specifically designed to be flexible and adhere to normal WAN traffic and layout. This concept helps to define where to create sites, site links, and preferred site link bridgeheads.

Figure 7.13 illustrates how a sample site structure in AD overlays easily onto a WAN diagram from the same organization. Consequently, it is a very good idea to involve the WAN personnel in a site design discussion. Because WAN environments change in structure as well, WAN personnel will subsequently be more inclined to inform the operating system group of changes that could affect the efficiency of your site design as well.

Figure 7.13. Site and WAN structure.

Establishing Sites

Each "island" of high connectivity should normally be broken into separate sites. This will not only assist in domain controller replication, but will also ensure that clients receive the closest domain controller and global catalog server to themselves.

Note

Windows 2000/XP clients or older versions of Windows using the AD Client utilize DNS to perform site lookups. This means that if your DNS records are inaccurate for a site, clients could be potentially redirected to a domain controller or global catalog server other than the one that is closest to them. Consequently, it is important to ensure that all your sites listed in DNS contain the appropriate server host records. This concept is explained more thoroughly in Chapter 9, "The Domain Name System."

Choosing Between One Site or Many Sites

In some cases, multiple LAN segments may be consolidated into a single site, given that the appropriate bandwidth exists between the two segments. This may be the case for a corporate campus, with various buildings that are associated with LAN "islands" but that are all joined by high-speed backbones. However, there may also be reasons to break these segments into sites themselves. Before the decision is made to consolidate sites or separate into individual sites, all factors must be taken into account.

Single-site design is simpler to configure and administer, but also introduces an increase in inter-segment traffic, as all computers in all buildings must traverse the network for domain authentication, lookups, and the like.

A multiple-site design addresses the problems of the inter-segment traffic because all local client requests are handled by domain controllers or global catalog servers locally. However, the complexity of the environment is more significant and the resources required increase.

Note

It is no longer a firm recommendation that all sites contain at least one global catalog domain controller server. The introduction of the universal group caching capability in Windows Server 2003 can reduce the number of global catalog servers in your environment and significantly reduce the amount of replication activity that occurs. This recommendation still stands, however, for sites with a local Exchange server, because global catalog servers are still critical for this environment.

The requirements of an organization with the resources available should be mapped to determine the best-case scenario for site design. Proper site layout will help to logically organize traffic, increase network responsiveness, and introduce redundancy into an environment.

Associating Subnets with Sites

It is critical to establish the physical boundaries of your AD sites because this information utilizes the most efficient login and directory requests from clients and helps to determine where new domain controllers should be located. Multiple subnets can be associated with a single site, and all potential subnets within an organization should be associated with their respective sites to realize the greatest benefit.

Determining Site Links and Site Link Costs

As previously mentioned, site links should normally be designed to overlay the WAN link structure of an organization. If multiple WAN routes exist throughout an organization, it is wise to establish multiple site links to correspond with those routes.

Organizations with a meshed WAN topology need not establish site links for every connection, however. Logically consolidating the potential traffic routes into a series of pathways is a more effective approach and will help to make your environment easier to understand and troubleshoot.

Site costs should be established by keeping in mind where replication traffic is desired and whether redundant links should be set up. For example, two site links can easily be designated to have equivalent costs so that replication traffic is load-balanced between them, as shown in Figure 7.14.

Figure 7.14. Equivalent site costs on multiple site links.

Choosing Replication Scheduling

Replication traffic can potentially consume all available bandwidth on small or saturated WAN links. By changing the site link replication schedule for off-hours, you can easily force this type of traffic to occur during times when the link is not utilized as heavily. Of course, the drawback to this approach is that changes made on one side of the site link would not be replicated until the replication schedule dictates. Weighing the needs of the WAN with the consistency needs of your directory is therefore important. Throttling the replication schedule is just another tool that can help to achieve these goals.

Choosing SMTP or IP Replication

By default, most connections between sites in Active Directory will utilize IP for replication because the default protocol used, RPC, is more efficient and faster. However, in some cases, it may be wiser to utilize SMTP-based replication. For example, if the physical links on which the replication traffic passes are not always on (or intermittent), SMTP traffic may be more ideal because RPC has a much lower retry threshold. SMTP traffic was designed for environments such as the Internet, where constant retries and resends are necessary to get the message to the destination.

A second common use for SMTP connections is in cases where replication needs to be encrypted so as to cross unsecured physical links, such as the Internet. SMTP can be encrypted through the use of a Certificate Authority (CA) so that an organization that requires replication across an unsecured connection can implement certificate-based encryption.

Encrypting SMTP Site Links

Often, specific portions of an organization may exist across an insecure "no man's land," such as the Internet itself. If your sensitive domain replication information traverses this type of environment, you will either need a highly secure virtual private network (VPN) solution, or you'll need to utilize encrypted SMTP connectors, which allow for replication traffic to be sent across uncontrolled connections, such as those used on the Internet. Obviously, it would be prudent to encrypt this type of traffic through the use of certificates or other SMTP encryption technologies.

To encrypt SMTP intrasite replication, a certificate should first be created and installed to allow the individual SMTP packets to be encrypted. This will help to prevent malicious users from stealing replication information if they happen to intercept the SMTP traffic.

Windows Server 2003 Replication Enhancements

The introduction of Windows 2000 provided a strong replication topology that was adaptive to multiple environments and allowed for efficient, site-based dissemination of directory information. Real-world experience with the product has uncovered several areas in replication that required improvement. Windows Server 2003 addressed these areas by including replication enhancements in Active Directory that can help to increase the value of an organization's investment in AD.

Note

Windows Server 2003 R2 did not introduce significant changes to the AD replication engine, but it does add additional schema objects to Active Directory. Before domain controllers can be updated to R2, the AD schema must first be extended by running the ADPREP /Forestprep command from the R2 CD.

Domain Controller Promotion from Media

An ingenious mechanism is now available in Windows Server 2003 that allows for the creation of a domain controller directly from media such as a burned CD or tape. The upshot of this technique is that it is now possible to remotely build a domain controller or global catalog server across a slow WAN link by shipping the CD to the remote site ahead of time, effectively eliminating the common practice in Windows 2000 of building a domain controller in the central site and then shipping it to a remote site after the fact. This effectively eliminates the need to perform tricks such as building remote GC servers locally and then shipping them to a remote location.

The concept behind the media-based GC/DC replication is straightforward. A current, running domain controller backs up the directory through a normal backup process. The backup files are then copied to a backup media such as a CD or tape and shipped off to the remote GC destination. Upon their arrival, the dcpromo command can be run with the /adv switch (dcpromo /adv), which will activate the option to install from media, as shown in Figure 7.15.

Figure 7.15. DCPromo from media.

After the dcpromo command restores the directory information from the backup, an incremental update of the changes made since the media was created will be performed. Because of this, there still needs to be network connectivity throughout the DCPromo process, although the amount of replication required is significantly less. Because some DCPromo operations across slow WAN links have been known to take days and even weeks, this concept can dramatically help to deploy remote domain controllers.

Note

If the copy of the global catalog that has been backed up is older than the tombstone date for objects in the Active Directory (by default, 60 days from when an object was last validated as being active), this type of DCPromo will fail. This built-in safety mechanism prevents the introduction of lingering objects and also ensures that the information is relatively up to date and no significant incremental replication is required.

Identifying Linked-Value Replication/Universal Group Membership Caching

Previously, all groups in Active Directory had their membership listed as a multivalued attribute. This meant that any time the group membership was changed, the entire group membership needed to be re-replicated across the entire forest. Windows Server 2003 now includes an incremental replication approach to these objects, known as linked-value replication. This approach significantly reduces replication traffic associated with Active Directory.

Directly associated with this concept, Windows Server 2003 allows for the creation of domain controllers that cache universal group membership. This means that it no longer is necessary to place a global catalog server in each site. Any time a user utilizes a universal group, the membership of that group is cached on the local domain controller and is utilized when the next request comes for that group's membership. This also lessens the replication traffic that would occur if a global catalog was placed in remote sites.

One of the main sources of replication traffic was discovered to be group membership querieshence, the focus on fixing this problem. In Windows 2000 Active Directory, every time a client logged in, the client's universal group membership was queried, requiring a global catalog to be contacted. This significantly increased login and query time for clients who did not have local global catalog servers. Consequently, many organizations stipulated that every site, no matter the size, must have a local global catalog server to ensure quick authentication and directory lookups. The downside of this was that replication across the directory was increased because every site received a copy of every item in the entire AD, even though only a small portion of those items was referenced by an average site.

Universal group caching solved this problem because only those groups that are commonly referenced by a site are stored locally, and requests for group replication are limited to the items in the cache. This helps to limit replication and keep domain logins speedy.

Universal group caching capability is established on a per-site basis through the following technique:

1.	Open Active Directory Sites and Services.
2.	Navigate to Sites\<Site Name>.
3.	Right-click NTDS Site Settings and choose Properties.
4.	Check the Enable Universal Group Membership Caching box, as shown in Figure 7.16. Figure 7.16. Universal group caching.
5.	Click OK to save the changes.

Removing Lingering Objects

Lingering objects, more affectionately known as zombies, are created when a domain controller is down for a period of time that is longer than the tombstone date for the deletion of items. When the domain controller is brought back online, it never receives the tombstone request and those objects always exist on the downed server. These objects could then be re-replicated to other domain controllers, arising from the dead as "zombies." Windows Server 2003 has a mechanism for detecting lingering objects, isolating them and marking them for cleanup.

Disabling Replication Compression

By default, intersite AD replication is compressed so as to reduce the bandwidth consumption required. The drawback to this technique is that extra CPU cycles are required on the domain controllers to properly compress and decompress this data. Windows Server 2003 allows designers the flexibility to turn off this compression, if an organization is short on processor time and long on bandwidth, so to speak.

No Full Synchronization of Global Catalog with Schema Changes

Previously, in Windows 2000, any schema modifications would force a complete resynchronization of the global catalog with all domain controllers across an enterprise. This made it extremely ominous to institute any type of schema modifications because replication modifications would increase significantly following schema modifications. Windows Server 2003 environments do not have this limitation, however, and schema modifications are incrementally updated in the global catalog.

Intersite Topology Generator Algorithm Improvements

The Intersite Topology Generator (ISTG) portion of the KCC has been updated to allow AD environments to scale to site structures of up to 5,000 sites. Previous limitations to the Windows 2000 ISTG essentially kept AD implementations effectively limited to 1,000 sites. This improvement, however, is available only when all servers in your Active Directory environment are Windows Server 2003 systems and the forest functionality levels have been raised to Windows Server 2003 levels.