John Policelli's Blog

Windows Server 2008 and Windows Server 2008 R2 include improvements to bridgehead server selection, which are not very well known. In fact, Microsoft only recently published an article on TechNet to explain the improvements to bridgehead server selection in Windows Server 2008 R2. What follows is an in-depth look at these improvements.

Bridgehead Server Overview

When domain controllers for the same domain are located in different sites, at least one bridgehead server per directory partition and per transport (IP or SMTP) replicates changes from one site to a bridgehead server in another site. A single bridgehead server can serve multiple partitions per transport and multiple transports. Replication within the site allows updates to flow between the bridgehead servers and the other domain controllers in the site. Bridgehead servers help to ensure that the data replicated across WAN links is not stale or redundant.

KCC selection of bridgehead servers guarantees bridgehead servers that are capable of replicating all directory partitions that are needed in the site, including partial global catalog partitions. By default, bridgehead servers are selected automatically by the KCC on the domain controller that holds the ISTG role in each site. If you want to identify the domain controllers that can act as bridgehead servers, you can designate preferred bridgehead servers, from which the ISTG selects all bridgehead servers. Alternatively, if the ISTG is not used to generate the intersite topology, you can create manual intersite connection objects on domain controllers to designate bridgehead servers. In sites that have at least one domain controller that is running Windows Server 2003, the ISTG can select bridgehead servers from all eligible domain controllers for each directory partition that is represented in the site

Bridgehead Server Selection

Bridgehead servers can be selected in the following ways:

• Automatically by the ISTG from all domain controllers in the site.
• Automatically by the ISTG from all domain controllers that are identified as preferred bridgehead servers, if any preferred bridgehead servers are assigned. Preferred bridgehead servers must be assigned manually.
• Manually by creating a connection object on a domain controller in one site from a domain controller in a different site.

By default, when at least one domain controller in a site is running Windows Server 2003 (regardless of forest functional level), any domain controller that hosts a domain in the site is a candidate to be an ISTG-selected bridgehead server. If preferred bridgehead servers are selected, candidates are limited to this list. The connections from remote servers are distributed among the available candidate bridgehead servers in each site. The selection of multiple bridgehead servers per domain and transport was introduced in Windows Server 2003. The ISTG uses an algorithm to evaluate the list of domain controllers in the site that can replicate each directory partition. This algorithm was improved in Windows Server 2003 to randomly select multiple bridgehead servers per directory partition and transport. In sites containing only domain controllers that are running Windows 2000 Server, the ISTG selects only one bridgehead server per directory partition and transport.

When bridgehead servers are selected by the ISTG, the ISTG ensures that each directory partition in the site that has a replica in any other site can be replicated to and from that site or sites. Therefore, if a single domain controller hosts the only replica of a domain in a specific site and the domain has domain controllers in another site or sites, that domain controller must be a bridgehead server in its site. In addition, that domain controller must be able to connect to a bridgehead server in the other site that also hosts the same domain directory partition.

Preferred Bridgehead Servers

Because bridgehead servers must be able to accommodate more replication traffic than non-bridgehead servers, you might want to control which servers have this responsibility. To specify servers that the ISTG can designate as bridgeheads, you can select domain controllers in the site that you want the ISTG to always consider as preferred bridgehead servers for the specified transport. These servers are used exclusively to replicate changes collected from the site to any other site over that transport. Designating preferred bridgehead servers also serves to exclude those domain controllers that, for reasons of capability, you do not want to be used as bridgehead servers.

Depending on the available transports, the directory partitions that must be replicated, and the availability of global catalog servers, multiple bridgehead servers might be required to replicate full and partial copies of directory data from one site to another.

The ISTG recognizes preferred bridgehead servers by reading the bridgeheadTransportList attribute of the server object. When this attribute has a value that is the distinguished name of the transport container that the server uses for intersite replication (IP or SMTP), the KCC treats the server as a preferred bridgehead server.

The bridgeheadServerListBl attribute of the transport container object is a backlink attribute of the bridgeheadTransportList attribute of the server object. If the bridgeheadServerListBl attribute contains the distinguished name of at least one server in a site, then the KCC uses only preferred bridgehead servers to replicate changes for that site, according to the following rules:

• If at least one server is designated as a preferred bridgehead server, updates to the domain directory partition hosted by that server can be replicated only from a preferred bridgehead server. If at the time of replication no preferred bridgehead server is available for that directory partition, replication of that directory partition does not occur.
• If any bridgehead servers are designated but no domain controller is designated as a preferred bridgehead server for a specific directory partition that has replicas in another site or sites, the KCC selects a domain controller to act as the bridgehead server, if one is available that can replicate the directory partition to the other site or sites.

Therefore, to use preferred bridgehead servers effectively, be sure to:

• Assign at least two or more bridgehead servers for each of the following:
  • Any domain directory partition that has a replica in any other site.
  • Any application directory partition that has a replica in another site.
  • The schema and configuration directory partitions (one bridgehead server replicates both) if no domains in the site have replicas in other sites.
• If the site has a global catalog server, select the global catalog server as one of the preferred bridgehead servers.

Bridgehead Server Load-Balancing Improvements with Windows Server 2008 RODCs

One of the benefits of deploying read-only domain controllers (RODCs) in branch offices is unidirectional replication. Bridgehead servers in a hub site do not replicate Active Directory data from the RODCs in each branch office, which reduces the inbound replication load on the bridgehead servers and also reduces administration and network usage. For outbound replication from the hub site to the branch office sites, RODCs provide load-balancing improvements that help distribute outbound replication connections evenly across a set of bridgehead servers.

With previous versions of Windows Server, after you add a new bridgehead domain controller in a hub site, there is no automatic mechanism to redistribute the replication connections between the branch domain controllers and the hub domain controllers to take advantage of the new hub domain controller for replication. For Windows Server 2003 domain controllers, you can rebalance the workload by using a tool such as Adlb.exe, which is included in the download package for the Windows Server 2003 Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?LinkID=28523).

For Windows Server 2008 RODCs, normal operation of the Knowledge Consistency Checker (KCC) provides load-balancing, which eliminates the need to use an additional tool such Adlb.exe. The automatic load-balancing is enabled by default.

In Windows Server 2008, the new automatic load-balancing applies only to RODCs. If you have writeable domain controllers in branch sites and you add a new bridgehead server in the hub site, you must continue to use a tool such as Adlb.exe to redistribute the workload across all the hub site bridgehead servers.

Windows Server 2008 R2 Bridgehead Server Selection Improvements

In Windows Server 2008 R2, load-balancing was introduced to distribute the workload evenly among bridgehead servers. In pre–Windows Server 2008 R2 environments, inbound connections from sites typically flooded one domain controller in the hub site with requests. This was the case even if the connections to the hub site were in a load–balanced state.

Consider the following example:

The scenario illustrated in the proceeding diagram includes the following:

• 5 read/write domain controllers (RWDCs) in a Hub Site, all of which are available bridgeheads.
• 5 read-only domain controllers (RODCs), each in its own branch site.
• 5 read/write domain controllers (RWDCs), each in its own branch site.
• Site links exist from the Hub site to each branch site, but no cross-branch site links exist.

For domain controllers running Windows Server 2008 and earlier, the default configuration resembles the following:

• All the branch domain controllers, RWDCs, and RODCs probabilistically load-balance their inbound connections across the 5 hub domain controllers.
• The 5 domain controllers in the Hub site do not have much load-balancing. The majority (50 percent or more) of the Hub site’s inbound connections from the 5 RWDCs in the branches come to the same hub domain controller.

In Windows Server 2008 R2, the default configuration resembles the following:

• All the branch domain controllers (RWDCs and RODCs) probabilistically load-balance their inbound connections across the 5 domain controllers in the Hub site.
• The 5 domain controllers in the Hub site have 100-percent load-balanced, inbound connections to the branches. Each domain controller has 1 connections from the branch RWDCs.

Now consider that an additional domain controller is added to the hub site, for a total of 6 domain controllers. This domain controller is also an available bridgehead server.

In Windows Server 2008 and earlier server operating systems, the following behaviour occurs after the additional bridgehead server is added to the site:

• The RODCs probabilistically load-balance their inbound connections across the 6 domain controllers in the Hub site. Approximately one-sixth of the RODCs that were using one of the other domain controllers in the Hub site switch to the new domain controller.
• The RWDCs ignore the new hub domain controller. To get the RWDCs to load-balance using the new domain controller in the Hub site, you have to delete all the inbound connection objects on the RWDCs and run the knowledge consistency checker (KCC) on all of them again.
• There is no load-balancing of inbound connections to the hub. Even if you deleted all the inbound connections, it still loads one domain controller with more inbound connections than the other domain controllers.

In Windows Server 2008 R2, the following behaviour occurs after you add the additional bridgehead server to the site:

• The RODCs and RWDCs probabilistically load-balance their inbound connections across the 6 domain controllers in the Hub site. Approximately one-sixth of the RODCs and RWDCs that were using one of the other domain controllers in the Hub site switch to the new domain controller.
• The 6 domain controllers in the Hub site load-balance the inbound connections to the branches.

Notes

• The new bridgehead server selection process does not load-balance within one site. That algorithm does not change from previous operating system releases.
• The new bridgehead server selection process does not load-balance the spanning tree.
• The system clock seeds the probabilistic choices. During testing, if you run the KCC simultaneously at all the branch sites, the inbound connection does not load-balance. The inbound connections all choose the same hub domain controller. If you run the KCC at least one second apart, the probabilistic load-balancing works.
• Adding more than one naming context (NC) confuses the scenario, because an already existing connection (even if it is for a different NC) is always used instead a new one. Therefore, in a multidomain scenario, the “pure” load-balancing is mixed with load-balancing from other NCs. This scenario does not always appear to be balanced, but it is within the described parameters of the new load balancing feature.

Additional Reading

• Bridgehead Server Selection
• Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008 RODCs
• How Active Directory Replication Topology Works