Generator and Bridgehead Servers

While the KCC is responsible for intra-site connection objects, all inter-site connection objects are established by the Inter Site Topology Generator (ISTG).The first DC in each site (regardless of domain membership) will assume the role of the ISTG.This role cannot be viewed or changed using standard Microsoft tools, and precisely one ISTG role per site exists for sites that house one or more DCs.

The ISTG is responsible for assessing the replication needs of the site in which it resides in relation to other sites and the site links established by the administrator. The ISTG will ensure that DCs in the site receive a copy of the Schema, Configuration, and Local Domain partitions, while GCs receive the same and also partial copies of all other domain partitions.

This is done by assigning the role of bridgehead server (BS) to one or more DCs in the site.These BSs are then responsible for replicating changes with other BSs in other sites. Multiple BSs per site might be required to ensure that all partitions required are replicated across site links. Only BSs replicate with DCs in other domains.Therefore, when a change is made to an object on a DC, it first replicates (intra-site) with its partners (established by the KCC), and ultimately, the change arrives at the BS for that partition in the site.That BS then replicates (inter-site) with each of its BS partners. For further information, refer to the sidebar Bridgehead Server Load Balancing.

The ISTG and BS roles might or might not exist on the same DC. Either way, the ISTG calculates which inter-site connection objects are required, and the BS "hosts" these connections and performs the actual replication of data across site links. This relationship is illustrated in Figure 2.20.

Figure 2.20 The Bridgehead and ISTG Roles

Figure 2.20 The Bridgehead and ISTG Roles

Bridgehead Server

The ISTG writes to the interSiteTopologyGenerator attribute on the NTDS Settings object within its DC object, in the config NC every 30 minutes, by default, so as to inform other DCs in the site that it is still actively performing the ISTG role.

The NTDS Settings can be found as follows:

1. Open the ADSIedit snap-in.

2. Add the Configuration partition to the view, if not already visible.

3. Expand the Sites container.

4. Expand the site container in question.

5. Expand the Servers container.

6. Expand the DC container in question.

7. Right-click the NTDS Settings object and choose Properties.

8. Inspect the interSiteTopologyGenerator attribute.

In the event that the ISTG role holder is unavailable, and the role holder fails to update the attribute, then all DCs in the site order the GUIDs of each DC in that site and elect the DC at the top of the list as the new ISTG role holder. That DC then writes to the interSiteTopologyGenerator attribute on the NTDS Settings object, within the DC object, in the Configuration partition.The role holder can be viewed by following the preceding steps.

For more detailed information regarding advanced replication techniques, refer to Chapter 4.


Previously, using Windows 2000 DCs, within each site each partition that needed to be replicated to that site was "hosted" by only one BS in the site. For example, if a forest had three domains, then in siteA we might find that domainsl and 2 are replicated by DCn, while domain3 and the Schema and Config partitions are replicated by DCm.

Using Windows Server 2003 DCs, however, the BS role is load balanced across multiple DCs in the site, such that the task of replicating data is spread across those same DCs. This offers the advantage that the replication overhead is spread over multiple servers, thus not burdening any one DC, while also offering increased availability of Active Directory, since if one BS fails, the other(s) will continue to replicate changes, regardless.

Was this article helpful?

+1 0


  • demsas osman
    How to determine bridgehead in a dc?
    1 year ago
  • Bell
    What is ISTG in active directory?
    10 months ago

Post a comment