Came across this blog post when researching for something. Long time since I read anything AD related (since I am more focused on VMware and HP servers) at work nowadays. Was a good read.
Summary of the post:
- When you have a domain spread over multiple sites, there is a designated Bridgehead server in each site that replicates changes with/ to the Bridgehead server in other sites.
- Bridgehead servers talk to each other via IP or SMTP.
- Bridgehead servers are per partition of the domain. A single Bridgehead server can replicate for multiple partitions and transports.
- Since Server 2003 there can be multiple Bridgehead servers per partition in the domain and connections can be load-balanced amongst these. The connections will be load-balanced to Server 2000 DCs as well.
- Bridgehead servers are automatically selected (by default). The selection is made by a DC that holds the Inter-Site Topology Generator (ISTG) role.
- The DC holding the ISTG role is usually the first DC in the site (the role will failover to another DC if this one fails; also, the role can be manually moved to another DC).
- It is possible designate certain DCs are preferred Bridgehead servers. In this case the ISTG will choose a Bridgehead server from this list.
- It is also possible to manually create connections from one DC to another for each site and partition, avoiding ISTG altogether.
- On each DC there is a process called the Knowledge Consistency Checker (KCC). This process is what actually creates the replication topology for the domain.
- The KCC process running on the DC holding the ISTG role is what selects the Bridgehead servers.
The above was just background. Now on to the improvements in Server 2008 R2:
- As mentioned above, in Server 2000 you had one Bridgehead server per partition per site.
- In Server 2003 you could have multiple Bridgehead servers per partition per site. There was no automatic load-balancing though – you had to use a tool such as
Adlb.exe
to manually load-balance among the multiple Bridgehead servers. - In Server 2008 you had automatic load-balancing. But only for Read-Only Domain Controllers (RODCs).
- So if Site A had 5 DCs, the RODCs in other sites would load-balance their incoming connections (remember RODCs only have incoming connections) across these 5 DCs. If a 6th DC was added to Site A, the RODCs would automatically load-balance with that new DC.
- Regular DCs (Read-Write DCs) too would load-balance their incoming connections across these 5 DCs. But if a 6th DC was added they wouldn’t automatically load-balance with that new DC. You would still need to run a tool like
Aldb.exe
to load-balance (or delete the inbound connection objects on these regular DCs and run KCC again?). - Regular DCs would sort of load-balance their outbound connections to Site A. The majority of incoming connections to Site A would still hit a single DC.
- In Server 2008 R2 you have complete automatic load-balancing. Even for regular DCs.
- In the above example: not only would the regular DCs automatically load-balance their incoming connections with the new 6th DC, but they would also load-balance their outbound connections with the DCs in Site A (and when the new DC is added automatically load-balance with that too).
To view Bridgeheads connected to a DC run the following command:
1 |
repadmin /bridgeheads /homeserver:<DNS name of DC> |
The KCC runs every 15 minutes (can be changed via registry). The following command runs it manually:
1 |
repadmin /kcc /homeserver:<DNS name of DC> |
Also, the KCC prefers DCs that are more stable / readily available than DCs that are intermittently available. Thus DCs that are offline for an extended period do not get rebalanced automatically when they become online (at least not immediately.