Bridgehead Server Selection

  • Article

Updated: July 2, 2010

Applies To: Windows Server 2008 R2

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 targeted 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 scenario:

  • 5 read/write domain controllers (RWDCs) in a hub site, all of which are available bridgeheads

  • 50 read-only domain controllers (RODCs), each in its own branch site

  • 50 RWDCs, each in its own branch site (101 sites total)

  • Site links exist from the hub to each branch site, but no cross-branch site links exist.

For Windows Server 2008 and earlier server operating systems, the initial 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 hub domain controllers do not have much load-balancing. The majority—50 percent or more—of the site’s inbound connections from the 50 RWDCs in the branches come to the same hub domain controller.

In Windows Server 2008 R2, the initial 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 hub domain controllers have 100-percent load-balanced, inbound connections to the branches. Each domain controller has 10 connections from the branch RWDCs.

Now, 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 behavior occurs after the additional bridgehead server is added to the site:

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

  • The RWDCs ignore the new hub domain controller. To get the RWDCs to load-balance using the new hub domain controller, 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 behavior occurs after you add the additional bridgehead server to the site:

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

  • The 6 hub domain controllers load-balance the inbound connections to the branches. Four of the hub domain controllers have 8 connections from the branch RWDCs and 2 of the hub domain controllers have 9 connections from the branch RWDCs.

Notes

  • The Windows Server 2008 R2 forest or domain functional level is not required for the load balancing feature –only Windows Server 2008 R2 domain controllers. Therefore, the more Windows Server 2008 R2 domain controllers you have in your environment, the more optimal your environment will be in terms of load balancing connections.

  • In a branch office scenario, it is recommended to upgrade the hub domain controllers first to Windows Server 2008 R2. By doing this, the hub site Windows Server 2008 R2 domain controllers will start sharing the load balancing replication from the branch read/write domain controllers.

  • The new bridgehead server selection process does not load-balance within one site. That algorithm does not change from previous operating system releases.

  • ADLB.exe can still be used to load-balance connections on writable domain controllers in Windows Server 2008 R2. The tool is AS-IS with no warranty. For more information about ADLB.exe see, Windows Server 2003 Active Directory Branch Office Guide (https://go.microsoft.com/fwlink/?LinkId=28523).

  • You can manually force the load-balancing algorithm by deleting the inbound inter-site connections for a DC or site and running the repadmin.exe /kcc command or deleting the connections and wait for the KCC to run automatically within 15 minutes.

  • The KCC can still leave unbalanced connections if DCs go offline for extended periods. The KCC does not rebalance offline DCs automatically when they come back online - the design considers keeping a stable well-connected topology as higher priority than re-balancing against DCs which are only available on an intermittent basis.

  • The new bridgehead server selection process does not load-balance the spanning tree. Therefore, if you have 100 domain controllers—all in their own sites—with a totally connected site link set (meaning a link from every site to every site) and all site links have equal cost, there is no load-balancing. The load-balancing previously described is only between two sites.

  • 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.